Agent Identity: Five Questions Before an Agent Acts

Identity has always answered three questions: who are you, what can you see, and who said so. AI agents break all three.

An agent holds credentials without being a person. It acts for someone without being them. It needs broad access to be useful and narrow access to be safe. And it can call other tools and agents, so access spreads in ways nobody explicitly granted. Most organizations handle this the way they once handled service accounts: one shared credential, too much scope, no expiry, and an audit trail that says the integration did it.

1. Who is it acting for? One accountable person or one approved process.
2. What exactly can it do? Scope by tool and by action, narrower than the user it works for.
3. For how long? Access tied to a task or a session, revocable by someone who owns it.
4. Who approves what? Reversible actions run alone. Anything irreversible, or anything that reaches a customer, waits for a person.
5. What is the record? Every action traceable by a skeptic.

If a team builds one thing before shipping an agent, it should be a per-action record with five fields: the actor (which agent and version), on behalf of (the person or process), the action and the scope it had at that moment, the approval (who confirmed it, or the rule that let it run alone), and whether the action is reversible.

With those fields, most agent incidents become readable. Without them, every investigation starts with guesswork.

MindBacklog, the product I built on my own, exposes an MCP server with 18 tools that AI clients such as Claude, ChatGPT and Cursor work against, with bearer-token authentication. Every tool was a scope decision: what it exposes, what a client can change, and where a person confirms before anything commits.

At work, the agentic entitlements workflow I am designing and piloting assembles a complete setup and stages it as a dry run. A delivery specialist executes, edits or cancels it. Two unrelated systems, the same rule: agents do the reasoning and the legwork, humans keep the commit on anything irreversible.

Agent access is a product decision. Teams that leave it to the platform team to solve later find that, by the time later arrives, the agent has a broad token in production and three features depend on it.

Decide scope and approval per tool before launch, put one clear review at the point of commit instead of a prompt on every step, and build the record from day one.