# Identity

> SSO for every internal AI app by default, and access for partners and contractors that expires.

Source: https://brocs.fyi/control/identity/
Part of the surface: C · Control. Keep a hand on the wheel.
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---

## The Control surface

- Configuration: declarative, versioned, reviewed, reversible
- Ingress: one front door for internal AI apps
- Identity: SSO by default, external access without VPN sprawl
- Storage and backups: retention, lifecycle, restore drills
- Routing: model and provider routing, pinning, failover
- Remote access: work reaches the data instead of the data reaching the laptop


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.

{{< aside title="How identity practitioners think about this" >}}
The mature version of this is the least-privilege lifecycle: entitlements attached to
roles, roles attached to people through groups, periodic recertification, and
just-in-time elevation for the rest. None of it is new. The AI amendment is that agents
are a new principal type that acts continuously and on behalf of others, so the
delegation model, not just the permission model, has to be explicit.
{{< /aside >}}

## 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.

{{< checklist >}}
- When an AI application reads data, whose permissions apply?
- Does every agent have its own identity, distinct from the person who runs it?
- For an autonomous agent action last week, can you name both the agent and the person it
  acted for?
- Which named consultant accessed what, last Tuesday? If the access record says "the
  contractor account", that is the finding.
- Do external grants expire on the statement of work date, or on a review cycle?
- What does your leaver process do about model provider accounts?
- List your AI service accounts. Who owns each, and when were they last reviewed?
- Is any service account used by more than one application?
{{< /checklist >}}