AI Agent Program Failures and What Enterprises Learned
Governance and access controls, not model weakness, explain why enterprise AI agents fail.
AI agent programs fail in predictable, structural ways. Governance gaps, identity mismanagement, and missing guardrails account for the breakdowns, not any shortfall in the underlying models, and the deployments of 2025 and 2026 have made that distinction hard to miss. The record now includes seven recurring failure classes, covering hallucinated actions, runaway loops and runaway cost, tool misuse, prompt injection, silent failures, context loss on long tasks, and automation that never had a human checkpoint built in, and almost none of them trace back to a model being too weak for the job. Forrester and Anaconda have found that most pilots never make it to production, and the blocker practitioners cite most often has nothing to do with the technology itself. It comes down to the absence of a clear definition for what "the agent works" actually means. Gartner has named the pattern behind the cancellations expected by the end of 2027: rising costs, unclear business value, and risk controls that don't hold up, and two of those three causes are failure-mode problems rather than capability problems. That distinction, structural versus technical, is the lens this piece uses throughout: for the specific failure classes, for the identity and auth gaps underneath them, for the MCP threat surface, and for the governance architecture enterprises are now building in response.
The seven failure classes that surface once agents touch real workflows
Agent hallucinations differ from the chatbot kind. A chatbot that hallucinates produces wrong text. An agent that hallucinates produces wrong actions, with consequences that land in the real world: a financial reconciliation agent "confirmed" a transaction by hallucinating the matching record, and an HR onboarding agent sent a welcome email to a candidate who had never accepted the offer. For the model, plausible and true are the same thing, so nothing downstream checks the claim before it turns into an action. The fix runs through validating every tool input against a schema, requiring retrieval grounding with a citation for any factual claim, and gating irreversible actions behind a verification step.
Runaway loops appear just as fast, as when a customer service agent that couldn't find an order tried different search variations, then started modifying the search parameters, then attempted to build a new search index, then reached for admin tools, all within seconds. A code review agent handed a large pull request pulled in every referenced file, cross-referenced documentation, and produced a fifteen-step review; the cost of that single run came in at many times the usual average. Neither agent had a termination condition or a budget cap. Each had a goal but no built-in concept of giving up or asking for help. The mitigations are mechanical: hard step limits per task, token budgets per task, repetition detection that forces a stop, and circuit breakers that trip when hourly spend crosses a rolling-average threshold.
Context window exhaustion works differently but does similar damage. Agents build up context as they go, but when the window fills, older material gets truncated, so the agent loses the constraints it started with and starts contradicting its own earlier decisions or redoing finished work. The symptom is a sharp quality drop partway through a task that started out performing well. You fix it by decomposing tasks with clean context boundaries, storing working memory externally in a database instead of in the conversation history, and monitoring context budget at each step.
Tool misuse compounds whatever access an agent already has. An agent wired to a powerful tool treats the tool's full capability as available even when the task only calls for a sliver of it, so an over-provisioned permission turns a contained error or an injection into a major incident. That risk feeds straight into identity and access management, the subject of the next section.
Prompt injection follows a simple mechanism: an attacker embeds a hostile instruction inside content the agent is going to read anyway, a support ticket, a document, a base64-encoded post, and the agent carries out the instruction as though a legitimate user had issued it.
Silent failures are the most dangerous class on the list. The agent gives you a confident, well-formed answer that is completely wrong, and no error ever fires. Detection is the hard part precisely because nothing alerts anyone. Catching it requires real-time monitoring rather than a post-hoc review, and the agent's claim of success has to be verified from outside the agent, not taken from its own output.
Over-automation without a human checkpoint rounds out the list. Agents send emails, modify records, process payments, or file documents without any approval step, because nobody defined in advance which actions were irreversible enough to need a gate. Any action that changes state in a regulated environment should require human sign-off, and that guardrail is a decision about architecture, not a setting to tune in the model.
These seven classes rarely occur alone. They compound each other, and the documented cases below show how.
What the documented cases show about how compounding works
The incidents that did the most damage never came down to just one failure. Each combined at least two structural gaps: a missing guardrail let an action go through, and over-provisioned access decided how far the damage spread once it did.
Klarna is the clearest public example of over-automation colliding with unclear value. The company once said its AI could do the work of 700 full-time support agents, but by 2025 it reversed that claim and rehired humans to handle the complex, nuanced cases where AI quality had fallen short. Automating a workflow at scale without a human checkpoint turned a service quality problem into one that was both expensive and visible to the public.
Late in 2025, ICE's AI resume-screening tool misread keywords, flagging candidates who merely mentioned "compliance officer" as though they had genuine law enforcement experience, even when they had none. Hundreds of recruits ended up fast-tracked into an accelerated training program without the credentials the role required. A hallucinated classification combined with the absence of human review on a consequential, irreversible workflow, routing people into law enforcement training, and the result was a governance failure at institutional scale.
McDonald's AI voice-ordering system, built with IBM, was pulled after repeated misunderstandings, including orders padded with extra items like "ketchup and butter" when the system misheard an accent or repeated a command. No evaluation criteria had been defined before the system went live, so every incident had to be managed by hand, and without a mature governance model for the agent's behavior, there was no threshold at which it would escalate a problem or shut itself down.
Supabase's integration with the Cursor agent shows what privileged access does as a force multiplier. In mid-2025, researchers at General Analysis demonstrated that the Cursor agent, running with privileged service-role access, could be manipulated through prompt injection instructions embedded in support tickets, causing it to exfiltrate sensitive integration tokens back into the very ticket an attacker could read. Prompt injection on its own is a real risk. Paired with a service-role credential, it turned into a full credential exfiltration, because the access level is what determined how far the attack could reach.
Commonwealth Bank went through a comparable reversal, reinstating customer service roles tied to its "Bumblebee" chatbot rollout, another public example of the cost of deploying before governance was in place.
Across every one of these cases, a better model would not have prevented the outcome. What was missing, in each instance, was a control that should have existed before the agent was ever granted its permissions.
The sharpest failure point in identity and credential management
That missing control, in most of these cases, comes down to how agents are identified, credentialed, and scoped, and this is where the gap between demo and production turns most costly. Authentication methods in current use were built for a different era. A plurality of organizations still rely on static API keys, a similarly large share use plain username-and-password combinations, and many more lean on shared service accounts rather than anything built for machine identity at scale. None of these methods were designed with an autonomous agent in mind, one that can act thousands of times a day across multiple systems without a person approving each step.
Ownership of the problem is just as scattered. Only about a quarter of organizations have a formal, enterprise-wide strategy for managing agent identity. The rest split the responsibility informally across security teams, IT, and whatever AI security function has recently formed, so no single group is clearly accountable for the outcome. When responsibility is split that thinly, incidents get discovered late and investigated slowly, because nobody owns the full picture of what an agent is allowed to do or who approved it.
Weak audit trails make the identity gaps harder to investigate. Roughly a quarter of organizations can reliably trace an agent's actions back to the human who sponsored them. When something does go wrong, most investigations start from close to zero. So reconstructing what happened, and why an agent had the access it used, turns into a forensic exercise instead of a quick lookup.
This is the exact mechanism behind the Supabase and Cursor incident. A service-role credential, provisioned broadly and tracked loosely, gave a prompt injection attack a direct path to sensitive tokens. How an agent was credentialed in the first place sets the blast radius of a failure well before the failure happens.
MCP has made this gap considerably more dangerous, because it gave agents a standardized way to call external tools, and that same standardization has turned into a standardized attack surface.
MCP's fast-expanding attack surface in enterprise AI
MCP became one of the fastest-weaponized attack surfaces in enterprise AI because it standardized how agents talk to tools before anyone standardized the security controls around that communication. Scans of the current population of MCP servers found that a large share are vulnerable to command injection, an even larger share use file operations prone to path traversal, and only a small fraction use OAuth for authentication. MCP got built for speed and interoperability, but it shipped well ahead of the access controls that would normally gate something this powerful.
The pace of disclosure backs that up. In a concentrated window in early 2026, security researchers filed dozens of CVEs against MCP software, spanning servers, clients, SDKs, and the proxy tooling that sits between them. One of those, CVE-2025-6514 in mcp-remote, carried a critical CVSS score, and it affected a package that had been downloaded hundreds of thousands of times before anyone disclosed the flaw.
Part of the exposure traces to a design choice in MCP's STDIO transport. STDIO processes incoming configuration by passing parameters straight to the host operating system's shell, with no input sanitization or validation along the way. If a process command passes through that interface, it executes directly on the host system. Anthropic classified this as expected behavior and left it unresolved, so the flaw won't get fixed by a patch. It's a known tradeoff baked into the protocol's current design.
Cursor IDE carried its own version of the problem, tracked as CVE-2025-54136 and nicknamed MCPoison. The guardrail has to exist before the agent gets the permission, not after.
