Trustworthy AI starts with surviving production failures

Date:
Wed, 12 Aug 2026 10:47:54 +0000

Description:
Reliable AI agents recover from failures, prove identity, and contain
breaches before damage spreads.

FULL STORY ======================================================================Copy link Facebook X Whatsapp Reddit Pinterest Flipboard Threads Email Share this article 0 Join the conversation Follow us Add us as a preferred source on Google Newsletter Subscribe to our newsletter Evaluating AI agents in production tends to focus only on positive results. Did the agent complete
the task? Was the output accurate? Did the demo go well?

The answers to those questions matter, but they miss the case that determines whether an enterprise can actually trust agents with real work: what happens in the 30% of instances where something goes wrong? Yaron Schneider Social Links Navigation

Co-founder and CTO of Diagrid. In financial services, for example, an autonomous agent that mishandles a money-movement workflow doesn't turn into an innocuous support ticket. It creates legal liability that can extend
across an entire business. Latest Videos From TechRadar Watch full video
here:

In healthcare, unchecked data access calls can compromise patient safety and lead to HIPAA violations. Highly regulated industries cant treat failure as a minor inconvenience. And when the stakes are categorically higher than in
most other sectors, it changes what "production-ready" means.

The problem? Most popular agent frameworks were built by teams focused on connecting large language models to reasoning loops and evaluation. While valuable, it's not the same discipline as distributed systems engineering.
You may like Why AI coding agents keep stalling before production and the governance controls that fix it Why autonomy alone fails and what truly
builds trustworthy AI systems AI without regret: Enabling speed, insight, and automation while maintaining control

Few of these frameworks were built by people who spend their careers thinking about recovery, consistency and fault isolation. Many give little thought to what happens when an agent fails mid-flight, and that gap can be very expensive once agents are handling real-world transactions. Replaying From Scratch Doesn't Work When a sales agent moves through a 10-step workflow and fails at step nine, the naive recovery approach is to start the entire flow over from step one. That sounds harmless until you account for what each step actually costs. Every restart means re-running every LLM call that already succeeded, burning through token spend for work that was already done correctly. At scale, that inefficiency turns a single bug into a real financial problem. Are you a pro? Subscribe to our newsletter Sign up to the TechRadar Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed! Contact me with news and offers from other Future brands Receive email from us on behalf of our trusted partners
or sponsors By submitting your information you agree to the Terms &
Conditions and Privacy Policy and are aged 16 or over.

It also produces a worse experience for the people and systems downstream. In a regulated workflow, its sloppy work that becomes a compliance and audit problem waiting to surface.

The fix is durable execution: checkpointing that captures progress at each meaningful step, so recovery means resuming from step nine, not replaying the whole sequence. This has become standard practice in distributed systems, and agent orchestration needs to follow suit.

When youre evaluating agent frameworks, heres the question you should ask: if an agent fails partway through a long-running task, does the system resume from where it left off, or does it start over? The answer will tell you the difference between frameworks built for production and those built for demos. What to read next Why security leaders are cautious about agentic AI Breaking free from pilot purgatory. The strategies needed to scale agentic AI Agentic AI in the enterprise: Why architecture matters more than marketing claims Theres an Access Problem Nobody Talks About Security in agentic systems presents its own version of this challenge, and it starts with a question
that sounds basic but that most organizations can't seem to answer: can you prove exactly who or what did what, and when?

That question is harder to answer as agents act on behalf of other agents, which act on behalf of humans. Each layer of delegation adds ambiguity about accountability. And when you add MCP servers into the mix, the exposure compounds. MCP gives language models access to company records, patient data and internal systems. The vast majority of MCP servers in production today connect to some kind of database , and the common mistake is granting broad access to that entire data store rather than narrowly scoping what each
server can see.

That distinction matters when something goes wrong. If a system with broad access suffers a breach or a supply chain compromise, the attacker gains access to the entire environment. Scoped access, where an MCP server or agent can only reach the specific data it needs for the task at hand, is one of the most overlooked design decisions in agentic architecture right now. It's also a relatively cheap problem to fix before deployment, yet one of the most expensive to fix after a breach.

Identity adds another layer. Many organizations still use traditional authentication protocols that were made for human users logging into applications, not for autonomous systems that act at machine speed and scale. Without verifiable identities for each agent and each component, malicious code can impersonate a legitimate part of the system and operate undetected.

Whats needed here is whats known as cryptographic attestation: a tamper-proof record of everything that happened in the system tied to the specific
identity that did it. That record lets you replay the system's state after
the fact and determine with certainty that a specific piece of code accessed
a specific system at a specific moment. Why? Because that identity was
managed and enforced in real time. It's the difference between a policy that says a component should be trusted and a system that can prove what it actually did. Design to Limit the Blast Radius, Not Just Patch the Damage There's also a problem with how most organizations think about vulnerabilities. The industry's attention is almost entirely on patching
known CVEs, and that's necessary. But at the same time, it misses something important: a vulnerability only becomes a known CVE after a breach has
already occurred. Patch management is inherently reactive and does nothing while a system is actively compromised, by which point malicious code is already trying to move laterally through the network.

This is why runtime enforcement deserves far more attention. The goal isn't just prevention; it's containment. If a system is compromised, can you detect that a component is behaving abnormally and immediately restrict its access, even before youve identified or patched the underlying flaw? Limiting the blast radius in real time, rather than relying solely on detection after the fact, is what separates a contained incident from a full-scale breach.

Zero trust principles should be applied specifically to AI workloads, not
just inherited from traditional cloud-native security protocols. That means strict authentication and authorization for every agent and MCP server, clear policies on what each component is allowed to access, and controls that stop compromised components from sending data outside the organization. You Need
to Prove Safety, Not Just Function This isnt pessimism toward AI agents; it's about engineering maturity. Every distributed system that has matured into something enterprises trust with critical workloads, from databases to cloud infrastructure, went through this same evolution. They go from optimizing for common cases to designing explicitly for the rare, expensive failure.

Agentic AI is now at that point. The organizations that get it right will be able to sit down with an auditor or a regulator and demonstrate, with evidence, exactly how their systems behave when something breaks:

- Durable recovery that doesn't waste a single completed step.

- Access that's scoped to the task, not the whole database.

- Identity that can be cryptographically verified, not just assumed.

- Containment that activates in real time, not after the fact.

These are the bars that enterprises serious about deploying AI agents at
scale need to meet. We list the best business cloud storage to manage your data . This article was produced as part of TechRadar Pro Perspectives , our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit



======================================================================
Link to news story: https://www.techradar.com/pro/trustworthy-ai-starts-with-surviving-production- failures


--- Mystic BBS v1.12 A49 (Linux/64)
* Origin: tqwNet Technology News (1337:1/100)