Your AI Agent Was Authorized. The Person Behind It Wasn't.
Why every action an AI agent takes must carry the authority of the person who started it.
A sales agent asks a finance agent to refund a customer $40,000. The finance agent is permitted to issue refunds, so the refund goes through. The sales representative behind the request cannot approve refunds at all. Every system records the action as authorized.
This is borrowed authority. The request uses the authority of the agent that carries it, and comes out looking legitimate.
How authority gets borrowed
In a multi-agent workflow, agents call one another through APIs, MCP servers, or agent-to-agent protocols. The finance agent authenticates the call, checks its own permissions, and acts. Nothing in the call identifies the sales representative.
The problem is old. In 1988, Norm Hardy described the confused deputy: a program that holds authority is tricked into using it for someone who lacks that authority. Security teams know the result as privilege escalation.
Why existing controls miss it
Identity and access management checks whether the finance agent may issue refunds, and it may. Service accounts and API keys identify only the agent, so the person behind the request disappears at the first hop. The audit log shows only the finance agent.
The standards already describe the right model
OAuth Token Exchange (RFC 8693, section 1.1) distinguishes delegation from impersonation. Under delegation, it says, "any actions taken are being taken by A representing B". It adds: "In a sense, A is an agent for B". The token names both the person and the agent acting for them, so the person's limits still apply.
Delegated Authority Integrity
For agents, that means four requirements:
- Original principal: Every request carries the identity of the person who started it, across every agent hop.
- Narrowing authority: Each handoff can only reduce what that person may do, never add to it.
- Trusted chain: The governance system builds the chain of handoffs from its own records. An agent cannot vouch for itself.
- Decision at the moment of action: The refund is checked against the requester's authority when it runs, as well as the agent's role.
Governing the decision
At Watchlight AI, Beacon starts each delegation chain with the person who logged in and decides every action outside the agent, before it runs. A delegate can never hold more authority than whoever granted it, and a chain an agent supplies for itself is refused. Watch delegated authority enforced in our recorded demo.
Every agent action should answer two questions: may this agent do it, and may the person it is acting for? An agent can carry a person's request. It should never carry more authority than that person has.
Request a demo and bring the multi-agent workflow that worries you most.
Subscribe to Watchlight Insights
Get new writing on Agent Runtime Governance, AI agent security, agent identity, and delegated authorization, delivered when we publish. No noise, just the new posts.
Unsubscribe anytime. We never share your email.
Put runtime governance in front of every agent action
Watchlight AI Beacon is available now, fully on-premises and air-gapped. Request a demo to see it in your environment.
Agent Workflow Fit & Readiness Assessment
Bring up to three agent workflows. Find out which one is ready for runtime governance now, and how to validate it.
2-3 days · Download one-pager (PDF)
