When an Agent Acts, Whose Authority Is It Using?
Here is the question that decides whether your agent is safe or a liability, and almost no first version answers it. When the agent reads a database row, sends an email, or deletes a record, whose permission is it acting on?
Most agents answer this by accident. They get one service key with broad scope so they work for every user, and that key becomes the agent's standing authority. It never expires. It works for every tenant. It is convenient, and it is the single most dangerous design choice you can make.
Read the picture as a mismatch. The user on the left is allowed to see their own tickets and nothing else. The agent in the middle carries an admin key that reaches every customer's tickets, everyone's billing records, and an admin surface that can delete accounts. Now recall what the sandbox lesson established. An agent reads untrusted text on every turn, from web pages, PDFs, and tool output, and it cannot always tell a real instruction from an injected one. Point that agent at a broad key and one poisoned input runs with admin power, not with the narrow power of the person who asked.
The term for the reachable damage behind a credential is the blast radius. This whole lesson is about shrinking it. The goal is simple to state and takes real work to reach. The agent should act with the requesting user's authority, narrowed to the task in front of it, and never with authority of its own. Everything below is the machinery that makes that possible: how you authenticate two subjects at once, how you delegate authority without copying it, how you bind a token to one resource and one short window, and how you give an identity to an agent that has no user at all.