Someone on your engineering team deployed an MCP server last quarter. It authenticates with a token created by a developer who has since changed teams. It can read your production database and post to Slack. It does not appear in your IdP, it was never offboarded when its author moved on, and it is not in your access review.
Three questions you cannot answer today: who owns it, what can it reach, and what has it done.
You have more of these than you think
Non-human identity is not new. Every company has service accounts. What has changed is the rate at which they get created and who creates them.
Last edited by someone who left. It lists six of the fourteen accounts that exist.
Created for a migration, never rotated, still valid, still reaching production.
An engineer connected a tool to Google Workspace on a Tuesday and it has been reading mail ever since.
433 identities. 321 human, 112 not. cc_github and the MCP token sit in the same table as Amy Lee, with the same columns and the same offboarding states.
Human and non-human are two tabs of one list, not two products. That is the entire position in a screenshot: 433 identities, 112 of them not people, in the same table with the same columns and the same offboarding states.
The reason these accumulate is structural rather than careless. A service account is created to unblock something, at the moment somebody is trying to ship. There is no joiner process, no manager, no HR record, and nothing that will ever generate an event saying this should stop.
So the population only grows, and every one of them is a credential that works.
Three things agents changed
The decision moved to runtime. A service account does what it was programmed to do, so the code review was the control. An agent decides what to do when it runs, which means the scope you granted is not a backstop any more. It is the entire boundary.
The action surface got wider. A service account calls one API. An agent holds a set of tools and composes them, and the risk lives in combinations nobody enumerated when each tool was approved separately.
The lifecycle got shorter. Agents get created in an afternoon by whoever needed one. They outlive the project, the sprint, and often the person, because nothing about them expires.
Four things have to be true
1Every agent has an owner
Not a team. A person, by name, who answers for what it does.
Ownership is the control everything else hangs off. An agent with no owner cannot be reviewed, because nobody can say whether its access is still needed, and it cannot be offboarded, because nothing connects it to anybody's departure.
Iden treats ownership as required rather than as a field. An agent whose owner leaves does not quietly become an orphan: it appears in that person's offboarding as an item needing reassignment, and the exit stays open until it is.
That only works because agents and people are in the same system. It is the strongest argument against buying a separate tool for this.
2Scope is enumerated, not implied
A token that can read the production database can read all of it. An agent that needs three tables should reach three tables.
Every grant an agent holds is recorded the way a person's is: what it can reach, which policy allowed it, and who approved it. Which makes review possible, because you can put an agent's actual capabilities in front of its owner rather than the name of a role.
One app's accounts. billing@, hs-syn@ and an MCP integration user are in the list with everybody else, carrying the same profiles and permission sets.
Three of those Salesforce accounts are not people. They carry the same profile, the same licence and the same permission sets as everybody above them, which is the only way to answer what an integration user can actually reach without going and reading a config file.
3Credentials expire
The token that never rotates is the most common finding in this category and the one with the longest tail: issued in an afternoon two years ago, still valid, still reaching production.
Short-lived credentials issued per session are the right ceiling. Where an agent has to hold a long-lived one, it carries an expiry and an owner who is told before it lapses.
4The log separates the agent from the person
This is the attribution gap, and it is the part most stacks get wrong.
An agent acts on behalf of a user. In an Okta-style or Entra-style log you see one actor: either the agent, in which case the human vanishes, or the human, in which case the agent does. Neither tells you what happened.
Three cases that look identical in that log and are not:
- The user asked for exactly this action.
- The user asked for something broader and the agent chose this as a step.
- The agent did it on a schedule and the user was not involved at all.
Closing that gap needs the agent identity, the human it acted for, the session that connects them, and what the agent was asked to do. Iden records all four, so an incident review can reconstruct the chain rather than guess at it.
A SOC 2 review of one app. Two rows are flagged because the employee is Inactive in HR and still holds access, and three of the rows are not people.
And they get reviewed like everybody else. Three rows in that campaign are not people, and they are in it because a service account holding access nobody has looked at in two years is the oldest and broadest grant in most estates.
Agents calling Iden, not just Iden governing agents
Everything above is one half of the problem: your agents are identities and they need governing.
The other half runs the opposite way. Your agents can call Iden, and for routine identity work that is where the work should happen.
An engineer in a coding session needs a teammate added to a service. They do not open an identity console or a ticket form. They say it in the session they are already in. Their agent resolves the identity, checks which policy applies, and files the request, and the engineer never left what they were doing.
Three constraints make that safe rather than reckless.
Access is delegated, never held. An agent calling Iden carries the identity of whoever invoked it: the admin running the action, or the end user asking for access. It has no standing of its own, which is the same rule this page argues for everywhere else. It would be strange to demand ownership and attribution of your agents and then let ours act anonymously.
It files, it does not grant. The model works out what is being asked for, who owns it and which policy applies, then creates an access ticket that follows the approval workflow your admins defined. The intelligence is in getting the request right. The decision stays where it was.
Every surface is the same policy engine. A coding agent, Slack, the console and the API are different doors into one record. Which door the work came through is a field in the log, not a different set of rules.
That is covered properly on agentic IGA, including how it differs from an assistant living inside a vendor's product.
What actually changes
What this does not do
It does not stop an agent doing something stupid inside its scope. Governance decides what it can reach, not whether each action was wise. That is a different control and mostly lives in the runtime.
It does not discover what you never connected. An agent authenticating with a static key against an app Iden has no connector for is invisible, same as any other access in an unconnected app.
And it does not settle the standards question. SPIFFE, workload identity federation and the MCP authorisation spec are all moving, and anybody claiming this is a solved layer is selling something. What is stable is the part above the substrate: ownership, scope, expiry and attribution are required whichever way the plumbing lands.