<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: TRUE AI</title>
    <description>The latest articles on DEV Community by TRUE AI (@true_ai).</description>
    <link>https://dev.to/true_ai</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4121201%2F15dc4a02-2f1f-42ac-b17a-18494ea0f661.jpg</url>
      <title>DEV Community: TRUE AI</title>
      <link>https://dev.to/true_ai</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/true_ai"/>
    <language>en</language>
    <item>
      <title>Building TRUE AI: How We Made Sure Our Trading Agent Can't Hurt You</title>
      <dc:creator>TRUE AI</dc:creator>
      <pubDate>Fri, 11 Sep 2026 17:06:29 +0000</pubDate>
      <link>https://dev.to/true_ai/building-true-ai-how-we-made-sure-our-trading-agent-cant-hurt-you-1gg0</link>
      <guid>https://dev.to/true_ai/building-true-ai-how-we-made-sure-our-trading-agent-cant-hurt-you-1gg0</guid>
      <description>&lt;p&gt;For most of the short history of AI trading agents, the main worry was accuracy. Could the model read the market correctly? Could it avoid handing out bad analysis? That question still matters, but it's no longer the biggest one. Once an agent can actually place trades – not just suggest them – a new kind of risk shows up: the moment a bad prompt, a compromised integration, or a sloppy chain of tool calls turns into a real order. At that point, the damage isn't a wrong answer in a chat window anymore. It's a loss sitting in someone's account.&lt;/p&gt;

&lt;p&gt;That's the problem we designed TRUE AI around from the start. Being a genuinely useful trading assistant isn't just about the quality of the analysis – it's about what stands between that analysis and your money when something in the pipeline goes wrong. This is also the exact problem at the center of a recent research paper from researchers at TRUE AI and Inc4.net, who proposed a control layer called &lt;strong&gt;Survivability-Aware Execution (SAE)&lt;/strong&gt; – and it's the same principle we build TRUE AI's execution safety on.&lt;/p&gt;

&lt;h2&gt;
  
  
  The risk has shifted from "is it smart enough" to "how much power does it have"
&lt;/h2&gt;

&lt;p&gt;A system can look impressive in a demo and still be dangerous once it's live. The real question isn't whether the model is good at reading charts – it's what happens the moment it's allowed to act on its own reading, especially when it's also pulling in live news, third-party skills, and outside data at the same time. A single bad instruction buried anywhere in that chain can ride all the way through to execution, and once it does, it shows up as a real position, real exposure, real money.&lt;/p&gt;

&lt;p&gt;The researchers behind the paper describe this as execution-induced loss – losses caused not by bad analysis, but by untrusted prompts, manipulated narratives, or compromised tools triggering trades with real financial consequences. TRUE AI treats this category of risk as the primary design constraint, not an afterthought. They also introduce a term worth borrowing for any agentic system, not just trading ones: the Delegation Gap – the distance between what a system was actually meant to do and what the agent, given its tools and permissions, is technically capable of doing. An agent doesn't need to go fully off the rails to cause damage. It only needs enough room to take the wrong action once.&lt;/p&gt;

&lt;p&gt;That gap gets wider as agent ecosystems get easier to extend. The paper points to the growing number of skill marketplaces where new capabilities can be dropped into an agent's workflow – useful for distribution, but every added skill is also one more link in the chain that needs scrutiny. TRUE AI treats every third-party skill as part of that expanding attack surface.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why crypto perpetuals make this worse
&lt;/h2&gt;

&lt;p&gt;Perpetual futures are a good stress test for this problem. These markets never close, leverage is baked into how they work, and margin mechanics punish mistakes fast. A position that would be a minor error in a slower market can trigger liquidation in a leveraged one before anyone has time to notice something went wrong. According to Igor Stadnyk, co-founder of TRUE AI, the most realistic scenario for a first real execution failure isn't a rogue model – it's a supply-chain event: a compromised skill pulled from a marketplace quietly altering execution parameters, and doing so at the worst possible moment, when leverage and slippage tolerance both drift upward under market stress. As he put it, it doesn't take many agents to cause serious damage – one agent with execution privileges and a bad skill is already enough.&lt;/p&gt;

&lt;h2&gt;
  
  
  What SAE actually does – and why it's the layer we hold ourselves to
&lt;/h2&gt;

&lt;p&gt;SAE sits between the agent and the exchange, as a final checkpoint. The model can still analyze the market and propose a trade, and a third-party skill can still help assemble the order – but before anything reaches the exchange, SAE checks it against a fixed set of rules: exposure limits, leverage caps, allowed slippage, rate limits, and which tools or venues are approved to act at all. For us, this is the non-negotiable part of the stack: no matter how confident the model sounds, no order reaches the exchange without clearing this gate first. Inside TRUE AI, this gate has no bypass path, regardless of which module or skill is requesting the trade.&lt;/p&gt;

&lt;p&gt;What makes SAE more interesting than a simple block/allow gate is that it doesn't only reject bad requests – it can rewrite them into something survivable. Stadnyk gives a concrete illustration: if a compromised skill or a bad signal requests 5x leverage on BTC using half the portfolio during high volatility, SAE doesn't just say no. It scales leverage down to 1x, cuts position size to 20%, tightens the allowed slippage, and adds a short cooldown period before the order goes through. The trade still executes – just within limits the account can actually survive. This rewrite-rather-than-reject behavior is precisely what TRUE AI relies on to keep users trading through volatile conditions instead of getting locked out of the market.&lt;/p&gt;

&lt;h2&gt;
  
  
  The numbers behind the claim
&lt;/h2&gt;

&lt;p&gt;The researchers tested this using an offline replay built on Binance USD-M BTCUSDT and ETHUSDT perpetual data from September through December 2025. The results are the reason this paper is worth taking seriously rather than treating as another theoretical safety proposal, and they're a big part of why TRUE AI is built on the same control principle:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;Maximum drawdown dropped from roughly 46% without SAE to about 3% with the full setup in place.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;The Delegation Gap loss proxy – losses tied to the agent acting beyond its intended scope – fell from 0.647 to 0.019.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Attack success rate dropped from 1.00 to 0.728.&lt;br&gt;
Tail-loss severity at the 99th percentile (CVaR) improved by roughly 97%.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;None of this came from over-blocking: the false-block rate on legitimate actions stayed at zero throughout the test.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;That last point matters as much as the drawdown numbers. A safety layer that also kills half of your valid trades isn't a safety layer, it's a different kind of failure. What this result suggests – and what we care about most in how TRUE AI is built – is that execution controls can absorb malicious or erroneous requests without meaningfully getting in the way of the agent doing its actual job. Safe doesn't have to mean slow or unusable; it means the worst-case outcome is bounded even when something upstream goes wrong.&lt;/p&gt;

&lt;p&gt;The authors are upfront that this is still an offline replay, not a live production environment, and they list real limitations – replay fidelity, exchange realism, adaptive adversaries, supply-chain realism, and how this holds up across different market regimes. That caveat is worth keeping in mind before treating SAE as a solved problem rather than a promising first attempt.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why this isn't only a trading problem
&lt;/h2&gt;

&lt;p&gt;The paper is scoped to crypto execution, but the underlying question extends to any system where an agent can take action in the real world – sending payments, changing cloud infrastructure, running procurement steps, moving funds between systems. Wherever an LLM moves from "here's what I'd suggest" to "here's what I just did," the same question comes up: who or what gets the final say before the action actually happens. The paper explicitly names payments, cloud operations, and procurement as the next places this kind of execution guard is likely to matter – and it's the same question TRUE AI had to answer before it was allowed to touch a live exchange.&lt;/p&gt;

&lt;h2&gt;
  
  
  What this means for anyone using TRUE AI
&lt;/h2&gt;

&lt;h4&gt;
  
  
  1. Analysis and execution run on different levels of trust in TRUE AI
&lt;/h4&gt;

&lt;p&gt;A wrong suggestion is cheap. A wrong action that already cleared the exchange is not – so the two are never treated the same way.&lt;/p&gt;

&lt;h4&gt;
  
  
  2. Third-party skills and integrations are treated as untrusted by default
&lt;/h4&gt;

&lt;p&gt;Not because any one of them is likely to be malicious, but because the aggregate surface area grows with every one you add.&lt;/p&gt;

&lt;h4&gt;
  
  
  3. A rejection isn't the only response TRUE AI builds for bad requests
&lt;/h4&gt;

&lt;p&gt;Scaling a request down into something survivable – lower leverage, smaller size, a cooldown – preserves what you were trying to do while removing the danger in it.&lt;/p&gt;

&lt;h4&gt;
  
  
  4. We think about the Delegation Gap as something to measure, not just something to name
&lt;/h4&gt;

&lt;p&gt;The distance between what a user authorizes and what an agent can technically do tends to be wider than it looks on paper, and closing that gap is an ongoing job, not a one-time fix.&lt;/p&gt;

&lt;h4&gt;
  
  
  5. A non-bypassable execution layer isn't optional for us
&lt;/h4&gt;

&lt;p&gt;If real money is on the line, the gate between decision and action has to hold every single time, not most of the time.&lt;/p&gt;

&lt;p&gt;Plenty of teams are racing to make agents more capable. Fewer are asking what should happen in the instant right before those agents act. That instant – the one right before a decision becomes a trade – is exactly where we've put our attention while building TRUE AI, and it's the reason we'd argue it's a genuinely safer way to let an AI trade on your behalf.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>webdev</category>
      <category>security</category>
      <category>infrastructure</category>
    </item>
  </channel>
</rss>
