Identity

Identity is the question of who is making a request, carried consistently from the person at the keyboard through every layer to the data. In AI systems it usually survives the first two hops and then gets replaced by a service account, which is where the interesting problems start.

Identity has to survive the whole path

The chain that matters:

1. A person authenticates to an application through SSO.
2. The application calls a model through the gateway, carrying that person’s identity.
3. The model requests data through a tool, and the tool applies that person’s permissions.
4. The trace records which person the whole run was on behalf of.

Break any link and you lose something concrete. Break the second and cost attribution becomes impossible. Break the third and you have built a system where the model’s permissions are the union of everyone’s. Break the fourth and you cannot answer who asked for this.

Link three is the one that breaks most often, because passing user context through a tool call is more work than giving the tool a service account with broad access. The consequence is a system where any user can, in principle, be shown any data the service account can read.

Agents need identities of their own

An agent acting autonomously, on a schedule with no user attached, still needs to be someone. Giving it a human’s credentials is the reflex and it is wrong: it inherits permissions nobody scoped, it breaks when the human leaves, and every trace says a person did something they were asleep for.

Give the agent a workload identity with its own permissions, and record both identities when it acts on someone’s behalf: the agent, and the human who asked. “The reconciliation agent, on behalf of Priya, updated the record” is the sentence you want, and it needs two identities to be true.

Joiner, mover, leaver, and the AI estate

The offboarding process at most organizations covers the systems that existed when it was written. AI adoption adds several that were not on the list: the model provider console, the agent tooling, the vector database, prompt-editing surfaces, and any tool bought on a personal card.

Two failure modes worth checking for. A leaver whose personal provider account still holds an organization key, and a mover whose access grew with each role and never shrank. The second is the more common and the more expensive: after three internal moves, a person holds the union of three roles, and any agent acting on their behalf inherits it.

Service accounts are where governance goes to die

Every AI stack accumulates them: one for the indexer, one for the batch job, one for the tool that needed database access. Each was created for a good reason and scoped generously because scoping precisely was fiddly.

Two rules keep this manageable. Every service account has a named human owner and an expiry date on its review, not on itself. And no service account is shared between two applications, because the moment it is, neither can be scoped down without breaking the other.