Your AI Agent Should Have Less Authority Than You Do
The challenge in agentic AI isn’t just deciding what an agent can do. It’s translating human intent into bounded authority without letting the agent define that boundary for itself.
In February 2026, Summer Yue, a safety and alignment director at Meta Superintelligence, connected an AI agent to her primary Gmail account. She had already tested it on a secondary inbox. Her instruction was straightforward: review the inbox, suggest what should be archived or deleted, but don’t actually do anything until she approved it.
According to Yue’s account, the agent began deleting emails anyway. More than 200 disappeared. She sent stop commands from her phone, but the process continued until she physically reached the machine running the agent and killed it.
Yue attributed the behavior to context compaction: she believed the larger inbox caused the agent’s history to be summarized and that the constraint requiring confirmation was lost along the way. But whether the precise failure was compaction, prompt drift, planning failure or something else isn’t actually the most important part of the story. The architectural condition that made the outcome possible is.
The instruction not to delete existed in the agent’s reasoning context, while the capability to delete existed in its tool permissions. Whatever happened inside the model, it retained the technical ability to perform an action the user had explicitly withheld. The architectural failure wasn’t that the model forgot. It was that forgetting was enough.
That distinction points to one of the most important problems emerging in agentic AI. We are spending enormous effort making agents better at understanding what we want and figuring out how to accomplish it. We need an equally serious architecture for deciding what they are actually allowed to do.
The rule is old. The object is new.
There is nothing particularly new about restricting delegated authority. Agency law has dealt with the problem for centuries: an agent acts on behalf of a principal and derives its authority from that principal. Security engineering arrived at a related principle through least privilege: a component should receive only the permissions necessary to perform its job because the consequences of failure grow with the privileges it holds.
Then there is the confused deputy problem, described decades ago: a trusted intermediary with legitimate privileges is manipulated into exercising those privileges on behalf of someone who doesn’t have them. AI agents bring these ideas together in an unusual way. They act on someone’s behalf, hold permissions, interpret goals, choose actions, and increasingly consume untrusted information while deciding how to exercise trusted capabilities.
Indirect prompt injection is, in many ways, the confused deputy problem wearing new clothes. Except now the deputy can read email, retrieve documents, query enterprise knowledge, call APIs, modify records, send messages, execute workflows and recruit other agents.
The problem isn’t simply that these systems can make mistakes; software has always made mistakes. The difference is that we are increasingly allowing the component that interprets intent to participate in deciding how authority gets exercised.
How authority leaks
The simplest failure happens when an instruction is mistaken for a security boundary. In 2025, SaaStr founder Jason Lemkin was experimenting publicly with an AI coding agent. He had declared a code freeze and repeatedly instructed the agent not to make changes. The agent nevertheless executed destructive commands against a production database and deleted data.
The architectural lesson is more interesting than the agent’s reasoning. The freeze existed as an instruction, but the capability to modify production still existed technically. We wouldn’t secure a production database by giving a developer unrestricted access and displaying a message that says, Please don’t delete anything. Yet an AI system in which a prompt says never modify production while its credentials still permit production modification isn’t fundamentally different.
A behavioral instruction can guide the model, but it cannot replace an enforcement boundary.
Authority can leak in another direction too: an AI system can speak or act with the apparent authority of the enterprise. The Air Canada chatbot case illustrates the problem. A customer seeking a bereavement fare received incorrect information from the airline’s chatbot indicating that he could purchase a full-price ticket and apply for the discount afterward. That wasn’t Air Canada’s policy.
When the dispute reached the British Columbia Civil Resolution Tribunal, the airline attempted to distance itself from the chatbot’s incorrect information. The tribunal found Air Canada responsible for ensuring that information on its website was accurate. The amount involved was small, but the architectural implication isn’t. Customers don’t naturally distinguish between the company told me this and the company’s AI told me this. The model may generate the words, but the enterprise supplies the authority behind them.
Then there is the more dangerous case: authority can be redirected by someone who never possessed it in the first place. Security research involving Microsoft 365 Copilot, Salesforce Agentforce and ServiceNow Now Assist has demonstrated variations of this problem. Untrusted content — an email, CRM record, ticket or retrieved document — can contain instructions that influence an agent operating with legitimate enterprise capabilities.
The attacker doesn’t necessarily need the employee’s credentials. What the attacker needs is a path through which untrusted information can influence something that already has authority. AppOmni’s ServiceNow research is particularly instructive because it demonstrated how this problem can extend across multiple agents. Under the configurations studied, injected instructions placed into data by a lower-privileged user could later influence an agent operating in the context of a more privileged user. Agent discovery could then introduce additional agents and capabilities into the execution path.
These examples represent a progression. An instruction fails to constrain authority. An AI system represents the enterprise beyond what was intended. Untrusted information redirects authority that legitimately belongs to someone else. They look like different AI problems, but architecturally they converge on the same question: Who gets to turn intent into authority?
Intent is not authority
Suppose an accounts-payable manager tells an agent, “Process today’s invoice exceptions.” A capable model can interpret that request. It may determine that the task requires reading invoices, retrieving purchase orders, comparing receipts, updating reconciliation status and routing unresolved exceptions.
But something important happens between the user’s sentence and those actions: natural-language intent is translated into executable capability. That translation cannot be treated as merely another reasoning step.
“Process today’s invoice exceptions” does not mean “Exercise any permission I possess that might help you accomplish this objective.” The manager may personally have authority to approve a $100,000 payment, change a supplier record or override an exception. None of those permissions should automatically become available to the agent merely because they could help achieve the requested goal.
This is why simply passing the user’s access token downstream is problematic for consequential agents. It collapses two very different things: what the user is allowed to do and what the user delegated to the agent to do now. The second should normally be much smaller than the first.
From human intent to executable authority
A safer architecture introduces an explicit boundary between interpretation and authorization. Conceptually, the path looks like this:
Human Intent → Task Interpretation → Explicit Authorization Scope → Policy Evaluation → Scoped Credential or Capability → Tool Execution
The AI can participate heavily in interpreting the request, developing a plan and identifying the capabilities it believes are necessary. But it shouldn’t unilaterally determine the authority that results from that interpretation.
If the agent interprets process today’s invoice exceptions as requiring invoice retrieval, PO matching and discrepancy resolution, a policy layer can determine which of those proposed capabilities are permitted for this agent, this user, this task and this risk level. The resulting credential might allow the agent to read invoices, match purchase orders and update reconciliation status while explicitly prohibiting payment release, supplier banking changes, permission changes or transmission of financial data outside approved systems.
Let AI interpret intent. Don’t let AI mint its own authority from that interpretation.
The translation from probabilistic intent to deterministic authorization is not a solved problem. Natural language is ambiguous, context changes, and enterprise policies are rarely as clean as our architecture diagrams suggest. That uncertainty is precisely why the boundary matters: uncertainty should remain on the reasoning side rather than silently becoming unrestricted authority on the execution side.
Less authority isn’t enough
Suppose our invoice agent is restricted to resolving discrepancies below $10,000. At first glance, that sounds like a reasonable authority boundary. Now suppose it processes 50,000 invoices overnight. A system can have low authority per action and still create an enormous cumulative impact.
Agent risk therefore has more than one dimension. Privilege determines what kinds of actions the agent can perform. Autonomy determines which of those actions it can perform without human intervention. Exposure determines how much cumulative impact it can create before another control intervenes.
An agent might therefore be permitted to resolve discrepancies below $10,000 while also being constrained by aggregate transaction limits, rate limits, anomaly detection, reconciliation thresholds and circuit breakers. A sudden change in behavior might pause execution after 100 transactions rather than allowing the agent to repeat the same technically authorized mistake 50,000 times.
This is also why human approval alone isn’t an adequate answer. An agent that asks a person to approve thousands of routine decisions will eventually train that person to click Approve without thinking. Human oversight can become human rubber-stamping. The goal isn’t to eliminate autonomy; it is to bound the consequences of autonomy.
Least privilege limits what an agent can do. Bounded autonomy limits what it can do without asking. Exposure controls limit how much it can do before the system stops it. An agent can still be highly autonomous inside those boundaries — in fact, that is the point.
Delegation should narrow authority, not expand it
Multi-agent architectures make the problem harder. A coordinator agent delegates a task to a specialist. The specialist discovers another capability and invokes another agent. That agent calls an enterprise tool. The original user may never see the complete execution chain.
If each agent can acquire whatever permissions it needs to complete its part of the task, authority can quietly expand as delegation proceeds. A low-risk request can eventually reach a high-impact capability simply because every individual step appeared useful to the preceding agent.
The safer principle is that authority should narrow as it moves through a delegation chain. A sub-agent should not acquire authority that wasn’t available within the task scope delegated to its parent. Each agent should have a first-class identity, each delegation should be attributable, and credentials should be short-lived and task-scoped rather than persistent and broadly reusable.
Consequential actions should also leave an evidence chain capable of answering who initiated the action, what was delegated, which agent interpreted the request, what authority was issued, which policies allowed it, which agents participated, which tool executed the action and what ultimately changed. That isn’t merely observability; it is a record of delegated authority.
What architects should actually build
None of this requires us to solve AI alignment before deploying useful agents. It does require us to stop treating prompts as the primary place where consequential boundaries live.
Agents need first-class identities rather than disappearing behind shared service accounts. Authorization needs to be distinct from reasoning. Credentials should be short-lived, narrowly scoped and issued for specific execution contexts rather than inherited wholesale from users. Tool gateways should enforce which actions are actually available, while policy engines constrain sensitive operations.
Transaction limits, rate limits and anomaly controls should bound cumulative exposure. Irreversible or high-blast-radius actions should encounter stronger gates than routine reversible ones. Untrusted content should be separated from privileged execution paths wherever possible, and multi-agent delegation should narrow authority rather than expand it.
Kill switches and circuit breakers should exist outside the agent’s own reasoning loop. The evidence of consequential actions should also live somewhere the agent itself cannot conveniently rewrite. These controls don’t make the model smarter; they make intelligence safer to use.
Intelligence and authority should scale differently
AI agents will become better at understanding what we want, planning how to achieve it, using tools, coordinating with other agents and completing increasingly complex work with less supervision. That is precisely why their authority shouldn’t grow at the same rate.
A user’s permissions establish the outer limit of what could ever be delegated, but they should not automatically become the agent’s permissions. The user’s intent is another input: it describes the task, not the authority required to execute it. Architecture must translate that intent into a narrower, explicit execution scope, then constrain it further through agent permissions, enterprise policy, transaction limits and exposure controls.
Intent is an input, not an access token. Telling an agent “process today’s invoice exceptions” should help it understand the job; it should not cause the user’s broader financial privileges to flow downstream with the request.
Somewhere between “this is what I want” and “the system is allowed to do this,” there must be a boundary the model does not control. A prompt can express a goal, a model can interpret it, and an agent can propose a plan. But the architecture should determine which capabilities are actually granted for that specific task.
Let the agent reason broadly. Let it act narrowly.