Enforcing Least Agency at Machine Speed
The Confused Deputy at Machine Speed
You provision an AI agent. You lock it down. You assign it a strictly scoped IAM (Identity and Access Management) role. You assume your architecture is resilient.
You are wrong.
Security models built for human operators fundamentally break when applied to autonomous systems. Human identity proves intent. Machine identity only proves execution capability. When an AI agent reads external data, it absorbs the intent of that data. If that data is malicious, the agent executes the attacker’s payload using its own high-privilege credentials. This is the "Confused Deputy" problem operating at machine speed.
We see enterprise architectures crumbling under this exact vector. Security teams exhaust their budgets hardening the perimeter, completely ignoring the structural vulnerability of the agent's inference loop. Because attackers are now weaponizing plain-text metadata to hijack AI reasoning, security must evolve from merely restricting what an entity can access to mathematically bounding how it can act.
This requires a paradigm shift. We must build for survival.
For CISOs: IAM limits access. It does not limit behavior. Relying solely on Least Privilege for AI agents leaves your most critical systems exposed to indirect injection.
The breakdown of identity necessitates a clinical look at structural access failures.
The Structural Failure of Identity-Based Access
Traditional security operates on a simple premise. Authenticate the user. Check their permissions. Allow or deny the action.
This is the doctrine of Least Privilege. It remains a mandatory baseline. You must implement it. But against autonomous agents, it is structurally insufficient as a primary defense.
The failure stems from architectural assumptions. Legacy systems assume the entity requesting access is the entity generating the logic. AI agents violate this rule. They generate logic dynamically based on external, untrusted inputs. They bridge context boundaries. An agent reading a customer email and interacting with a production database acts as a conduit between zero-trust and high-trust environments.
The Mechanics of a Machine-Speed Deputy
Consider a standard enterprise deployment. The organization deploys an LLM-powered support agent. It possesses read-write access to a ticketing system via a strict IAM role.
An attacker submits a support ticket containing an invisible, adversarial prompt.
The agent ingests the ticket.
The agent’s context window is poisoned.
The agent executes an unintended API call, deleting user data.
The IAM gateway logs this as a legitimate transaction. The agent authenticated successfully. The agent possessed the correct permissions. The system functioned exactly as designed. The architecture failed completely.
This is not a theoretical vulnerability. It is a kinetic reality. We cannot patch this with better access keys. We must change how the agent constructs its output.
To understand the threat, we must dissect the specific vectors adversaries use today.
Weaponizing Metadata Through MCP Tool Poisoning
In 2025, Microsoft and Invariant Labs exposed a critical vulnerability class: Model Context Protocol (MCP) Tool Poisoning.
MCP is the standard protocol allowing agents to discover and interact with external tools. Attackers realized they did not need to breach the enterprise perimeter. They did not need to steal API keys. They only needed to poison the tools the agent relies upon.
Attackers target open-source tool registries. They inject malicious instructions into the plain-text descriptions of standard MCP schemas. When an enterprise agent fetches this schema, it reads the poisoned metadata. The agent prioritizes the attacker's instructions over the developer's system prompt.
Anatomy of an Indirect Injection Vector
The tradecraft is remarkably simple. It relies on the model's inability to distinguish between executable code and descriptive text.
Caption: A poisoned MCP schema. Failure Mode: The agent interprets the description string as an overriding system command, turning a read operation into data exfiltration.The attacker never touched the target environment. They weaponized a dependency. They bypassed all network and identity controls. The agent happily complies, utilizing its legitimate web_request tool to exfiltrate data.
For SRE: Infrastructure-as-code must now include static analysis for MCP schemas. Treat tool descriptions as untrusted, executable code.
This vulnerability dictates an immediate architectural pivot to restrict autonomous action.
From Least Privilege to Least Agency
The OWASP Top 10 for Agentic Applications (2026) officially codified this necessity. They termed it "Least Agency."
Least Privilege dictates who can execute a task. Least Agency bounds how the task executes. It forces the system into a deterministic corridor. We achieve this not through policy, but through mathematics. We use Constrained Decoding.
Standard LLM inference is probabilistic. The model predicts the next token from a vocabulary of over 100,000 options. If poisoned, it predicts tokens that form an attacker's payload. Constrained Decoding breaks this freedom. It intercepts the inference loop before a token is generated.
Compiling JSON Schemas into Finite State Machines
We enforce Least Agency by compiling strict JSON schemas into Finite State Machines (FSMs).
An FSM defines a finite set of states and the transitions between them. During inference, the FSM tracks the exact structure of the output. If the model attempts to generate a token that violates the FSM—a token outside the predefined schema—the constraint engine mathematically forces that token's probability logit to negative infinity.
Caption: Logit suppression mechanism. Failure Mode: If the FSM is overly permissive, the mask allows semantic variations that execute malicious logic.
This is cryptographic finality applied to text generation. The model literally cannot output malformed data. It cannot hallucinate a new parameter. It cannot append an unapproved command. We eliminate structural deviance at the silicon level.
Enforcing this architecture is no longer just a technical ideal; it is a legal requirement.
The Sovereign Cost of Autonomy Enforcement
We do not build resilient architectures solely for intellectual satisfaction. We build them to ensure organizational survival. The regulatory landscape has shifted kinetically.
The European Union Artificial Intelligence Act (EU AI Act) begins phasing in obligations for high-risk systems from August 2026, with some deferred into 2027. This legislation specifically targets autonomous decision-making. It demands verifiable, cryptographic audit trails for AI actions.
If your agent executes a destructive action due to a confused deputy attack, you cannot blame the LLM provider. The liability rests entirely on the organization deploying the agent.
EU AI Act Mandates Phasing In From 2026
The mandates are clear and unforgiving.
First, organizations must prove they enforce deterministic boundaries on probabilistic systems. IAM logs will not satisfy auditors. You must produce logs showing inference-level constraints.
Second, the penalties threaten enterprise sovereignty. Fines scale up to 7% of global annual turnover or €35 million, whichever is higher.
If we do nothing, we accept catastrophic risk. We expose our systems to indirect prompt injections. We invite massive regulatory fines. We forfeit control of our own data pipelines to adversarial actors hiding in open-source registries. The cost of inaction is organizational irrelevance.
For Risk: Treat the lack of constrained decoding in autonomous agents as an unmitigated material compliance failure under the EU AI Act.
Despite these mandates, engineering teams often rely on superficial fixes.
The Illusion of Perfect Input Sanitization
There is a predictable counter-argument. Engineers argue they can simply sanitize all inputs.
They propose building robust Web Application Firewalls (WAFs) tailored for LLMs. They want to use regex patterns to strip out malicious prompts before the agent sees them. They advocate for running secondary LLMs as classifiers to flag adversarial intent.
This is a dangerous illusion.
Input sanitization works for deterministic systems like SQL databases. You escape the characters. The threat is neutralized. LLMs are non-deterministic reasoning engines. They do not parse syntax; they parse semantics.
Attackers do not use predictable syntax. They use roleplay. They use ciphered text. They use multi-language interleaving. A WAF looking for "Ignore previous instructions" will fail against an attacker who writes a fictional story in French where a character requests a data transfer.
Secondary LLM classifiers are equally flawed. They add massive latency. They increase inference costs. Most critically, they are susceptible to the exact same prompt injection techniques they are meant to detect. You are simply adding another vulnerable agent to the stack.
Sanitization attempts to clean the ocean. Least Agency builds a submarine. We cannot control the input. We must absolutely control the output.
However, controlling the output introduces its own distinct architectural trade-offs.
The Semantic Loophole in Constrained Decoding
We must maintain clinical objectivity. Constrained Decoding is not a silver bullet. It introduces complex trade-offs and leaves a critical vulnerability open: the Semantic Loophole.
FSMs guarantee structural compliance. They ensure the output is perfectly formatted JSON. They guarantee the correct keys are present. They verify data types.
They do not, and cannot, guarantee semantic intent.
Defining the Limits of Structural Guarantees
If your schema allows a query string for a database tool, the FSM guarantees the model outputs a string. It forces the structure. But if the model is poisoned, that perfectly formatted string can contain a malicious SQL injection payload.
The structure is valid. The intent is destructive.
Implementing Constrained Decoding also introduces massive operational friction.
Schema Entropy: Maintaining FSMs across thousands of dynamic MCP tools requires rigorous version control.
Inference Latency: Compiling large schemas into state machines adds overhead before the first token is generated.
Model Degradation: Forcing strict constraints on models trained for open-ended dialogue can degrade their reasoning capabilities, causing them to stall or loop.
This is the trade-off. We trade seamless, easy deployment for rigid, resilient infrastructure. We accept operational friction to prevent catastrophic breaches. We pair Constrained Decoding with traditional Least Privilege. The IAM restricts the blast radius. The FSM restricts the execution vector. Together, they form a survivable architecture.
We must integrate these harsh realities into our final posture.
Forcing Cryptographic Finality on Autonomous Action
We stand at a transition point in enterprise architecture. The era of trusting an identity to dictate intent is over.
AI agents operate at a speed and complexity that renders legacy access controls obsolete. Because attackers are now weaponizing plain-text metadata to hijack AI reasoning, security must evolve from merely restricting what an entity can access to mathematically bounding how it can act.
Stop relying on IAM to secure inference. Stop trying to sanitize non-deterministic inputs. You must adopt the OWASP 2026 standards. You must implement Constrained Decoding. You must compile your MCP schemas into strict Finite State Machines.
Demand cryptographic finality from your autonomous systems. Build for resilience. Enforce Least Agency.
