Here is a small scene that happens millions of times a day now. A person asks an assistant to do something. The assistant hands part of the job to a specialised agent. That agent calls a tool, and the tool reaches into a system that holds real data — orders, tickets, salaries, whatever your company actually runs on.
The system at the end of that chain has to answer one question before it does anything: who is asking? And the honest answer is uncomfortable, because there are at least two truthful replies. The agent is asking. But it's asking on behalf of the person who started the whole thing, and those are different identities with different permissions.
Most incidents I've seen in this space come down to one of those two answers being silently dropped somewhere along the chain.
The actor and the subject
Auth people have had words for this for a long time — the actor (the thing making the call) and the subject (the party it acts for). OAuth's token exchange spec is basically this idea with a lot of ceremony around it. Agents didn't invent the problem; they industrialised it. A chain that used to be two hops long, human to service, is now four or five, and every extra hop is another place for the subject to fall off.
Because falling off is the convenient failure. The lazy way to wire an agent to a tool is a shared credential: one service account, generous permissions, job done, demo works. Now every request arrives at the data layer as the same flat identity, and your authorisation model has collapsed to "the agent may do anything any of its users may do." Nobody decided that. It just shipped.
The alternative is unglamorous plumbing: both identities travel with the request, every hop re-asserts rather than launders them, and the systems at the end authorise against the pair. The agent may be allowed to use the tool; the person may be allowed to see the record; the interesting policy lives in the intersection.
Checks belong before the expensive part
A related thing that sounds obvious written down and still gets built wrong: revocation has to sit at the front of the request path, before anything that costs money or leaks anything.
If an employee leaves, or a token is compromised, the question is not "will we eventually stop serving them" — it's how many more model calls, at real per-token prices, get made on their behalf while caches expire. A revocation check that runs after routing, or worse after inference, is a receipt, not a control. Denied identities should be the cheapest requests in the whole system: rejected early, before a single token is spent.
Protocols like MCP and the agent-to-agent efforts are slowly giving this space standard shapes, which I'm glad about — the worst period for any security problem is the one where every team hand-rolls its own answer. But a protocol only carries identity; it doesn't make anyone honour it. That part is still built one unglamorous decision at a time, usually by whoever is willing to be the person in the design review asking "okay, but who is the subject on hop three?"
Be that person. It's a boring question. Boring questions are load-bearing.