Non-human & AI agents

Service accounts, API keys and agents

The wiki page nobody updates and the token nobody rotates. What governs them instead.

Every service account, API key, OAuth grant and agent gets the four things a person's account already has: an owner by name, a reason to exist, an expiry, and a place in the review.

None of that is exotic. It is the joiner-mover-leaver discipline applied to the identities nobody thinks of as identities. Every company has service accounts. What has changed is how fast they get created and by whom.

A service account gets made 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 produce an event saying this should stop.

So the population only grows, and every one of them is a credential that works.

Four requirements

An owner, by name. Not a team. Ownership is the control everything else hangs off: an agent nobody owns cannot be reviewed, because nobody can say whether its access is still needed, and cannot be offboarded, because nothing connects it to anybody's departure.

Scope that is enumerated. A token that can read the production database can read all of it. Recording what an identity can actually reach, and which policy allowed it, is what makes review possible.

Credentials that expire. The token that never rotates is the most common finding here and the one with the longest tail. Short-lived per-session credentials are the ceiling; where a long-lived one is unavoidable it carries an expiry and an owner who gets told before it lapses.

Attribution that separates agent from human. An agent acting for a user shows up in most logs as 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.

Iden's policy management screen, showing the rules that decide who gets which access and under what conditions.

The rules, written once. Everything else on this page is a consequence of them.

The reason this belongs in the same system as people

An agent whose owner leaves has to appear inside that person's offboarding as an item needing reassignment.

That is the whole argument against a separate non-human identity tool. The moment agents live somewhere else, the connection between a departure and an orphaned credential has to be maintained by hand, which is exactly the failure mode you were trying to fix.

What still needs a person

Deciding whether a broad scope is correct. Plenty of agents legitimately need more access than looks comfortable, and the answer is a recorded exception with a name on it rather than a quiet reduction that breaks a pipeline.

Frequently asked questions

Start with OAuth grants nobody registered, API tokens created by people who have changed teams, and accounts with no matching HR record. Discovery surfaces the rest as connectors go in.

Yes, in the same campaign as people. They hold access like people and are usually the oldest, broadest grants in the estate, so splitting them out is how they end up never reviewed.

Those are the substrate and they are moving. What is stable is the layer above: ownership, scope, expiry and attribution are required whichever way the plumbing lands.