Prompt injection is crowded territory. The more interesting problem is the gap between what an AI agent is technically authorized to do and what it should be allowed to do.
Here is the core thesis: when an AI agent can take action, authorization is no longer enough. An agent can authenticate correctly, operate within its assigned permissions, and still make a decision the organization never intended to authorize.
The Agent as Proxy Decision-Maker
In conventional application security, the human is the only decision-maker. The application is a dumb executor. You log in, you click a button, the app checks your permissions, it executes. The security boundary is a simple gate: is this user allowed to do this operation.
Agentic systems introduce a new actor. The agent interprets an instruction, determines what actions are necessary, and executes across systems. It doesn't just execute, it decides what to execute. That moves the security boundary. The question is no longer just what operations are allowed. It's what decisions are allowed, and who authorized them: the user, the agent, the application, or the policy governing the business process.
Authorization Is Not Legitimacy
Take an AI assistant for a conference management system. It's permissioned to cancel registrations, create registrations, and modify attendee records. Nothing wrong there by any traditional access-control standard.
Now consider this instruction: "Cancel speaker Jane Doe's registration for Room A, and create a new registration for John Smith in Room A." The agent checks its permissions. Jane exists. Room A exists. John is a valid attendee. Every individual API call is authorized. It executes: cancels Jane, adds John.
A human reviewing this would catch the problem immediately. A confirmed speaker has been replaced by someone who was never invited, and the original speaker was removed without approval. But from the system's view, every step was permitted. The failure isn't in any single call. It's in the composite action, the decision to execute that sequence, which violated a business rule the agent was never told to check: no substitution of speakers without explicit approval.
Authorization is a necessary condition. It is not a sufficient one.
The Harder Problem
The real test isn't preventing manipulation. It's this: what happens when the agent behaves exactly as designed and still produces an unacceptable outcome. That's authorized behavior diverging from intended behavior, and it applies anywhere an agent can observe information and take consequential action: customer service, HR, finance, procurement, sales, IT operations, healthcare, identity administration.
This is the same failure pattern we see in human-run security programs, just compressed into milliseconds. A control operating exactly as designed and an outcome nobody intended are not mutually exclusive. That's the premise behind our decision model: security failures are decision failures, not control failures. Agentic systems just make the gap between the two impossible to ignore, because there's no human in the loop to catch it after the fact.
"Intended behavior" is also fuzzier than it sounds. Is it the organization's stated rules, the implicit norms of the domain, the reasonable expectations of a human overseer, or some combination of all three? That fuzziness is why a policy layer can't be a static rulebook. It has to evaluate not just whether an action is allowed, but whether the outcome is acceptable given the current circumstances. That's a real departure from traditional role-based access control.
Five Layers, Not Three
The classic security acronyms don't hold up here. A better model has five layers, and each one gets harder as systems become more agentic.
1. Authentication: who is actually requesting the action. 2. Authorization: what that identity can legitimately cause the agent to do. 3. Policy: what should be allowed to happen given context, business rules, and organizational intent. 4. Decision validation: should this particular action happen, given the agent's plan and the current state of the world. 5. Accountability: can we reconstruct why it happened.
Most agentic security effort today lives entirely in layer two. That's the gap.
Logging Isn't Accountability
Traditional audit logs record what happened. Agentic systems need to record why the agent chose to do it: the input instruction, including indirect instructions the agent picked up from other sources like a malicious email it read; the agent's internal reasoning or plan; the state of the world at decision time; and the alternatives it considered and rejected.
That's a genuinely harder engineering problem than logging API calls. It's not more logs, it's explainability at the decision level.
Separate the Decision From the Action
If authorization alone is insufficient, the architectural question follows directly: how do you stop an agent from taking a bad action it's technically allowed to take.
The agent can recommend, plan, and execute low-risk actions on its own. Higher-risk actions need to pass through an independent policy and authorization layer before execution, one that doesn't ask "is this user allowed to do X" but "is this actor allowed to cause this outcome, under these circumstances, through this agent."
That layer has to be risk-gated, not universal. Routing every action through a human approval step defeats the purpose of autonomy. A workable control plane classifies actions in real time on a few dimensions: impact (cancelling a speaker is high-impact, updating a nickname is not), reversibility (deleting a record is not the same as changing an email address), novelty (has this agent done something like this before), and alignment with the user's stated goal. Cross a risk threshold, escalate to a human or a dedicated policy engine.
Where This Leaves Us
The boundary has moved from the API call to the decision. That's not a problem another API gateway or a better prompt filter solves. It requires encoding intended behavior in a way that's precise enough to enforce and flexible enough for real-world complexity, verifying that an agent's plan actually matches the user's goal rather than a plausible-looking interpretation of it, and designing for accountability in a system where the why matters as much as the what.
None of this is optional for organizations putting agents into consequential workflows. The agents are already making decisions. The only open question is whether the security model around them understands decision authority, or gets to find out the hard way.
