Liz's PM notebook · Field note
AI & SecurityWhy Most Companies Get Agent-to-Agent Permissioning Wrong
Why static human access models break in agentic workflows, and what task-scoped, intent-aware permissioning needs to look like.
Every enterprise I've watched race toward "agentic" workflows in the last year has made some version of the same mistake. They've bolted agent permissioning onto systems designed for a completely different threat model. RBAC, OAuth scopes, and API keys were built to answer one question: does this human, sitting at this session, have the right to do this thing right now?
That question doesn't hold up when the actor isn't a human anymore.
The assumption that breaks
Traditional access control assumes a permission grant is a snapshot of intent. A user logs in, requests are made under their identity, and the system trusts that every action in that session reflects something the user actually meant to do. The human is the checkpoint. Even in delegated systems, such as a script running under a service account or a webhook triggered on someone's behalf, there is still a single, traceable point where a person decided this should happen.
Agents don't work that way. An agent is given a goal, not a request. It then makes a sequence of its own decisions about which tools to call, which data to touch, and which other agents to hand work off to. The original human never explicitly authorized those decisions and often couldn't have anticipated them. The permission boundary a company thinks it has, the agent's API key or its RBAC role, ends up authorizing the goal. The actual risk lives in the path the agent takes to get there.
Most companies don't notice this gap until an agent does something technically inside its scope but clearly outside its intent. It reads a dataset it was permissioned for but never should have touched for that task, or hands a sensitive tool call to a second agent that inherits access nobody meant to extend.
Three places the current model fails
- 01
Permission is granted at the identity level, not the interaction level.
A single "agent has access to Salesforce" grant collapses hundreds of distinct actions into one binary yes: read a contact, export a list, modify a deal stage, or delete a record. Humans get away with this because social and procedural friction fills the gap. A person could delete every record, but doesn't, because they understand consequence. Agents have no equivalent friction. If the scope allows it, an agent will eventually do it because nothing internal to the agent says "technically allowed" and "actually intended" are different things.
- 02
Delegation is treated as inheritance, not negotiation.
When Agent A calls Agent B, most current implementations just pass the token forward. B now effectively has A's permissions. This is the equivalent of giving your house keys to whoever your assistant happens to call on your behalf. What should happen instead is scoped, purpose-bound delegation. B gets exactly the narrow slice of access required for the specific sub-task, time-boxed, and revocable independent of A's own token. This is precisely the kind of interoperability problem protocols like A2A are trying to solve. It is also where most early implementations quietly punt because narrow delegation is genuinely hard to design and even harder to make performant.
- 03
Audit trails answer "was this allowed" instead of "was this intended."
Every enterprise I have seen can tell you, after the fact, whether an agent's action fell within its granted scope. Almost none can tell you whether that action matched what the human who kicked off the workflow actually wanted. Those are different questions, and only the second one is useful when something goes wrong.
What better looks like
The systems that will hold up aren't the ones with tighter RBAC roles. They're the ones that stop treating permission as a static grant and start treating it as a live negotiation, scoped to task, propagated with intent attached, and re-evaluated at each hop rather than inherited wholesale. Concretely, that means:
- Task-scoped tokens, not identity-scoped ones. A permission should expire with the task it was issued for, not with the session.
- Explicit, narrow delegation contracts between agents. A downstream agent's access should be a subset defined by the task, not a copy of the upstream agent's full grant.
- Intent as a first-class object in the authorization decision, not just a comment in a log. The system should be able to ask "does this action serve the stated goal" as a real check, not a retrospective one.
- Revocation that cascades. If you pull the plug on Agent A mid-workflow, every permission it delegated downstream needs to die with it immediately, not at the next token refresh.
The real advantage
None of this is exotic. It is the same principle behind least-privilege access that security teams have preached for a decade. It just has to be re-implemented for a world where the "user" making the request is a probabilistic system taking a sequence of self-directed actions rather than a person clicking a button once.
Companies that get this right won't be the ones with the most sophisticated agents. They'll be the ones whose permission model assumes the agent will eventually do something no one explicitly told it to do, and has already decided what happens next.