There is a moment in the deployment of an AI agent that is easy to overlook. The permissions have been reviewed, access boundaries are defined, runtime controls are in place, and human approval is required for certain actions. The agent is finally allowed to act.
Then it makes a decision that turns out to be wrong.
It closes a security alert that should have been investigated. It approves an exception that creates unexpected exposure. It changes a configuration based on information that looked reliable at the time.
The first question will probably be, “Why did the agent do that?”
But there is a harder question:
Who owns the outcome?
Permission Gets You to The Door. Decision Ownership Starts After
That question becomes increasingly important as agents move beyond retrieving information or executing predefined commands and start making decisions inside security workflows.
We have spent a lot of time thinking about what an agent can access and what it can do. Those questions matter. But once an agent has legitimate authority to act, permission alone does not tell us who owns the decision.
An agent can have permission to close an alert without being the owner of the risk created by closing it.
Those are different things.
Consider a simple security workflow.
An agent monitors incoming alerts and classifies them. Based on a defined policy, it can automatically close low-risk alerts that match certain conditions.
The workflow looks sensible.
Now imagine an alert meets almost all of the conditions for automatic closure. The remaining signal is unusual, but the agent interprets it as noise and closes the alert. Hours later, the organization discovers that the unusual signal was actually evidence of a compromised account.
The agent had permission to close the alert. The tool accepted the action. No access boundary was violated.
So, who made the decision?
Saying “the agent made the decision” does not really answer the question. The agent does not own the security program. It did not approve the policy, and it did not decide how much authority it should receive.
The security team may own the workflow. A policy owner may own the rule. The person who approved the automation may own the decision boundary. The organization ultimately owns the consequences.
The agent may simply be the mechanism through which the decision was executed.
That distinction matters because authorization and accountability are often treated as if they were the same thing.
They are not.
Authorization answers:
Can the agent do this?
Accountability needs to answer:
Who accepted responsibility for allowing the agent to make this kind of decision under these conditions?
The Dangerous Delegation Is the Decision
This is where agentic systems differ from traditional automation.
A conventional automation might follow a fixed rule: if condition A occurs, perform action B.
An agent can interpret context, weigh information, choose between actions, determine whether something appears suspicious, decide whether an exception is justified, and sometimes determine whether a human needs to become involved.
The important control point is therefore not only the action.
It is the decision that precedes the action.
Consider a security exception. A policy might say that a particular type of exception can be approved automatically when certain conditions are met.
But what happens when the conditions are ambiguous? What happens when two policies conflict, or when the agent finds evidence that the original workflow never anticipated? What happens when the safest action is unclear?
This is where “human in the loop” can become an overly simple answer.
If every uncertain decision goes to a human, the organization may create an exception queue that nobody has the capacity to meaningfully review.
If nothing gets escalated, the agent becomes the de facto decisionmaker, even if the organization never explicitly intended that.
The real design problem is deciding which decisions an agent can make independently, which require escalation, and who owns the exceptions.
Four Layers of Agent Authority
A useful way to think about agent authority is to separate four things that are often treated as one:
Permission
What can the agent technically access or execute?
This is the traditional security question.
Decision Authority
What decisions is the agent actually allowed to make without escalation?
An agent may technically be capable of executing an action without having the authority to decide when that action is appropriate.
Escalation
What conditions require the decision to move to a human or another authority?
This is where organizations establish the boundary between autonomous operation and human judgment.
Accountability
Who owns the consequences of decisions made within that authority?
This is the layer that can disappear when teams focus too heavily on access controls.
These four layers are connected, but they are not interchangeable.
An agent can have permission without having broad decision authority. A human can retain accountability while delegating specific operational decisions. An exception can have a different owner from the person who designed the original workflow.
Figure 1. Permission, decision authority, escalation, and accountability answer different questions.
Making those distinctions explicit changes how agentic systems should be designed.
Instead of asking only, “What access does this agent need?” teams also need to ask:
What decisions are we actually delegating?
Make the Decision Boundary Enforceable
That question has to survive contact with the actual tool. Suppose the alert agent can close a low-risk alert. “Only close routine alerts” sounds reasonable in a prompt, but the model is also the thing deciding what counts as routine. That is a lot of trust to put in one sentence.
“A well-trained model can still be exploited through a poorly configured harness, an overly permissive tool, or an exposed environment.”
Anthropic, Trustworthy agents in practice
The alert service can enforce the narrow part: which alert types are eligible, how old the evidence may be, whether the account is privileged, and whether a recent related alert exists. The agent can recommend closure and explain its evidence. The service checks the hard conditions before it accepts the action. If a signal is ambiguous, the agent routes it for review instead of stretching the rule until it fits.
That separation also limits the blast radius of a bad input. A suspicious email or retrieved document can try to persuade the agent that an alert is harmless. It should not be able to rewrite the downstream rule that decides whether closure is allowed. OWASP’s excessive agency guidance makes the same practical point: narrow the available tools and permissions, require approval for high-impact actions, and enforce authorization in the systems receiving the calls.
Give the deployment a named owner and its own scoped identity. If several teams share a powerful agent credential, the log may show which token closed the alert while hiding whose workflow it belonged to. Preserve the requesting user’s context when the agent acts on someone’s behalf. Expire temporary grants. The authority you meant to delegate should match the authority the tools can actually exercise.
The Exception Queue Is Where the Model Gets Tested
The normal path of a workflow is rarely the hardest part.
The interesting cases are the exceptions.
An agent may operate perfectly when everything matches the expected pattern. The difficult question is what happens when reality falls outside that pattern.
Suppose an agent has authority to approve a security exception under certain conditions. An unusual request arrives, and the agent determines that it is close enough to the policy to approve.
Later, someone asks why the exception was granted.
“We gave the agent permission to approve it” is not a sufficient answer.
Someone still needs to own the fact that the organization chose to let the agent interpret that policy in that situation.
This is why exception handling should be treated as a first-class part of agent design.
For every meaningful exception, organizations should be able to determine:
What decision was made?
What authority did the agent have at the time?
Which policy or policy version applied?
What information did the agent have?
What information was missing?
Why was the decision allowed to proceed without escalation?
If a human was involved, who approved the exception?
Who owned the decision boundary?
These questions are not only for an audit after something goes wrong.
They determine whether the organization can actually learn from the failure.
Make Escalation a Real Decision
An escalation rule should say what happens when the case is close to the boundary, not just announce that a human is somewhere “in the loop.” An alert involving a privileged account, contradictory evidence, an unfamiliar exception, or a proposed change that is difficult to reverse should have a defined destination and an owner who can make the call.
Then show that person the decision, not a mystery button. “Approve agent request?” tells the reviewer almost nothing. Show the proposed closure or exception, the evidence for and against it, the applicable policy, what the agent could not verify, and what will happen if the reviewer approves. Let the reviewer reject, modify, or request more evidence. Bind approval to the exact action. A one-time exception should not become a standing pass for the next ten alerts.
What this looks like (illustrative): An analyst approves isolating only host demo-17, with the approval valid for 15 minutes. A later request to isolate the entire subnet needs fresh approval, even if it comes from the same agent in the same run.
And give the team a way to stop the run. If an agent keeps retrying after a denial, or starts working from a poisoned source, someone should be able to pause it and revoke its access before the queue becomes a very efficient mistake machine. Human review works when the reviewer has useful context and real control. A hundred vague approval popups are just a slower form of autopilot.
Figure 2. Routine, uncertain, and high-impact decisions take different routes.
Accountability Has to Be Reconstructable
After an incident, a log that simply says “agent approved exception” is not enough.
A useful audit trail needs context. It should capture the relevant inputs, the applicable policy or policy version, the authority available to the agent, the action taken, the escalation decision, and any human intervention.
If a human overrides the agent, that override should have a reason. If the agent operates under changing policies, the organization should be able to identify which version was active when the decision occurred.
The goal is not to create an enormous record of every token an agent generated.
The goal is to preserve the information needed to reconstruct the decision.
What did the agent know? What was it allowed to decide? What rule applied? What did it do? Why did the workflow allow it to proceed? Who owned that boundary?
Without those answers, an organization may have logs without having accountability.
Trace the Decision, Not Just the Click
This is the gap between an activity log and a decision trace. “Agent closed alert 8124 at 2:14 p.m.” establishes that a tool call happened. It does not tell you why the agent thought closure was safe or why the system let it proceed.
Keep the request, the evidence the agent used and where it came from, the policy version, the proposed action, the authority check, the escalation result, the tool response, and the identities of any human or second agent involved under one run ID. Record the agent’s short stated rationale as a clue, while treating the underlying evidence and enforced checks as the stronger record. A tidy explanation from a model is not proof that it faithfully describes what drove the choice.
For the compromised-account example, a useful trace might show that the agent proposed closure because three signals matched the routine pattern, while a fourth signal came from an unfamiliar login. The policy required review for that combination. The closure service rejected the call, and the case went to an analyst. If it was closed anyway, the same trace points investigators toward the rule, the missing signal, the approval, or the bypass that failed.
NIST’s AI risk guidance asks organizations to define oversight roles and make AI systems auditable. Decision tracing makes that concrete. It helps a team see what happened, why the boundary held or failed, and who can change it.
Figure 3. Decision trace: the evidence, policy, authority, action, and owner tied to one run.
Authority Should Not Automatically Transfer Through a Handoff
The problem becomes even more interesting when multiple agents are involved.
Imagine one agent detects a suspicious event and hands it to another agent responsible for remediation. The second agent receives the context and takes an action.
Did it inherit the first agent’s authority?
It should not automatically.
The fact that one agent had permission to perform a particular workflow does not mean another agent should have the same authority.
A handoff should transfer the context necessary to perform the task, but the receiving agent should still operate within its own defined decision boundary.
Otherwise, authority can expand through the workflow without anyone explicitly granting it.
The individual agents may each appear correctly configured while the overall workflow has accumulated more decision authority than anyone intended.
In multi-agent systems, permission boundaries therefore need to survive handoffs.
So does accountability.
The receiving agent also needs its own identity, scope, owner, and expiry. A remediation worker may need the alert summary and permission to isolate one host. It does not need the first agent’s entire credential set or a general license to alter the network. Record the handoff and the authority check on both sides so an investigator can follow the chain without guessing which agent borrowed whose access.
Not Every Decision Needs a Human
None of this means putting a person in front of every agent action. That would remove much of the value of automation.
The more useful approach is to classify decisions by consequence.
An agent might independently make low-impact, reversible decisions such as classifying an alert, collecting additional evidence, or routing an event for review.
A different class of decisions might require stronger evidence or specific conditions before the agent can proceed.
High-impact or difficult-to-reverse actions may require escalation.
The exact boundaries will differ between organizations.
What matters is that those boundaries are designed before an incident rather than reconstructed afterward.
Otherwise, organizations end up deciding only after something goes wrong whether the agent should have been allowed to make the decision in the first place.
That is not a reliable control model.
Try it yourself: Give a colleague who did not build the workflow one completed test-run trace. Ask them to find the evidence, policy version, any required approval, and owner that allowed the action. Any answer they have to guess is a gap to investigate.
The Uncomfortable Part of Delegation
Organizations are comfortable delegating tasks to software.
They are less accustomed to delegating judgment.
That distinction becomes important as agents become capable of interpreting context and choosing actions rather than simply executing predefined commands.
When an agent makes a bad security decision, the failure may exist at several levels.
Maybe the agent misunderstood the evidence. Maybe the policy was incomplete. Maybe the decision boundary was too broad. Maybe the escalation rule was poorly designed. Maybe the organization approved an authority level without considering the edge cases.
So “the AI made a mistake” may describe what happened without explaining why the system allowed that mistake to matter.
The deeper failure can be that an organization delegated a decision without clearly defining what ownership looked like afterward.
That is simultaneously a security problem, a workflow problem, and a governance problem.
The Next Question for Agentic Security
The early conversation around AI agents focused heavily on access.
What systems can the agent reach? What credentials does it have? What actions can it execute?
Those questions remain necessary.
But as agents become more capable, another question deserves equal attention:
What decisions are we actually willing to delegate?
And once we delegate them:
Who owns the outcome?
The answer does not have to be “a human must approve everything.”
It should be more precise.
An organization should know which decisions an agent can make independently, where escalation begins, how exceptions are handled, and who owns the decision boundary.
After an incident, it should also be possible to reconstruct the chain: the authority the agent had, the policy that applied, the relevant inputs, the decision that was made, the exception if there was one, the escalation path, and the person or team that owned the boundary allowing the agent to act.
That is a much stronger model than simply giving an agent permission and hoping the logs explain everything later.
The agent may make the call.
But someone still needs to own the outcome.
A Practical Checklist
Before giving an AI agent authority to make a security decision, ask four separate questions:
Permission: What can it technically do?
Decision authority: What can it decide without escalation?
Escalation: What conditions force the decision to move elsewhere?
Accountability: Who owns the outcome?
If those four answers are not clear, the agent may be operationally autonomous without the organization being organizationally accountable.
That is the gap worth closing before agents become responsible for more consequential decisions.
About the Authors
Zohre Shirazi is the founder of AI Wide Open, a publication focused on the real-world impact of AI on businesses, work, and how organizations build with AI. Her work focuses on practical AI adoption, workflow redesign, AI agents, and the gap between AI capability and operational reality.
ToxSec explores the intersection of technology, cybersecurity, and emerging security challenges, with a focus on practical thinking around how security systems and practices are evolving.
Keep Exploring AI in the Real World
If you’re interested in what happens when AI moves beyond demos and into real workflows, follow AI Wide Open for practical analysis of AI agents, adoption, workflow redesign, and the decisions organizations are making as AI becomes more operational.
If this piece made you rethink where accountability sits in an agentic workflow, share it with someone building or governing AI systems.
Really enjoyed working on this with you. The distinction between giving an agent permission to act and defining who owns the decision is becoming increasingly important as agents take on more consequential work. I especially like how we brought the discussion down to practical controls around escalation, exceptions, and reconstructing decisions after something goes wrong. Thanks for making this collaboration happen!