Identity for AI Agents, Explained for Product Teams
AI agents hold credentials, act for users and chain tools together. Five identity questions to answer before an agent touches customer data, from someone working on both sides of it.
Identity has always answered three questions. Who are you? What are you allowed to see? Who said so?
I have spent more than seven years in customer identity and access, most recently leading product for an identity platform used by roughly 4 million people. For most of that time the answers to those three questions were stable. A person logged in. A role or a license decided what they could reach. An administrator or a contract granted it.
AI agents break all three, and most product teams are adding agents faster than they are answering them.
What makes an agent different
An agent borrows from both users and service accounts, and fits neither.
- It holds credentials but is not a person. It can authenticate, call your API and change data, with nobody watching the screen.
- It acts for someone without being them. When an agent books, edits or deletes, it does it on behalf of a user who may not know the exact action happened.
- It needs broad access to be useful and narrow access to be safe. Those two pull against each other on every tool you expose.
- It can call other tools and other agents. Access then spreads in ways nobody explicitly granted.
Most organizations are handling this the way they handled service accounts years ago: one shared credential, too much scope, no expiry, and an audit trail that says “the integration did it.” That was survivable when the integration ran one script. It is not survivable when the thing holding the credential decides what to do next.
Five questions to answer before an agent touches customer data
I have now worked on both sides of this. My own product, MindBacklog, exposes an MCP server that AI clients like Claude and Cursor can work against, and its in-app assistant can act on product data. At work, I am designing and piloting an agent that assembles customer entitlement setups. In both, the hard design work was the same five questions.
1. Who is it acting for? Every agent action should trace to one accountable person or one approved process. An agent that acts for “the system” acts for nobody.
2. What exactly can it do? Scope by tool and by action, not by account. An agent working for a user should get less than that user has, because it brings no judgment about what it should leave alone. Every one of the 18 tools on my MCP server was a scope decision: what it exposes, what a client can change, and where a human approval gate sits before anything commits.
3. For how long? AI agent authentication answers which agent is calling. It does not answer what that agent may do, for whom, or for how long. Long-lived credentials are how service accounts became a liability. An agent’s access should be tied to a task or a session and be revocable by someone who owns it.
4. Who approves what? Reversible actions can run alone. Anything irreversible, or anything that reaches a customer, should be staged for a person to confirm. The entitlements agent I am piloting never commits on its own. It prepares the complete setup as a dry run, and a specialist executes, edits or cancels it.
5. What is the record? “The bot did it” is not an answer you can give a customer or an auditor. Every action needs a record a skeptic can follow.
The audit record I would ask for
If I had to pick one thing for a product team to build first, it would be a per-action record with five fields.
| Field | What it answers |
|---|---|
| Actor | Which agent, and which version of it |
| On behalf of | The person or process it was working for |
| Action and scope | What it did, and what it was allowed to do at the time |
| Approval | Who confirmed it, or the rule that let it run alone |
| Reversible | Whether the action can be undone, and how |
With those five fields, most agent incidents become readable. Without them, every investigation starts with guesswork.
Where product teams get stuck
The pattern I see most often is treating agent access as an integration problem for the platform team to solve later. By the time “later” arrives, the agent has a broad token in production and three features depend on it.
The second pattern is copying the user’s permissions onto the agent because it is the easy default. It feels safe because the agent “can only do what the user can do.” In practice the user would never do most of those things by accident, and the agent can.
The third is putting the approval step in the wrong place. A confirmation dialog on every read trains people to click through. One clear review at the point of commit gets real attention.
Why this is a product decision
Identity used to be plumbing. With agents, it becomes part of the experience. How much an agent may do alone, what the person sees before it commits, and how they undo it are product decisions. They decide whether customers trust the agent enough to use it.
My bet is that agent identity becomes a board-level topic within two years, for the same reason breach response did. The fastest path there will be the first serious incident traced to an over-permissioned agent.
The teams that answer the five questions before that happens will spend the next two years shipping. The rest will spend it retrofitting.
