In Control Identity
C / Control

Identity

SSO for internal AI applications, delegated identity, and expiring access for partners and contractors.

View as Markdown

Identity is the question of who is making a request, carried consistently from the person at the keyboard through every layer to the data. A service account may replace that identity before the request reaches a data tool. At that point, downstream systems lose the user's permissions and attribution.

Preserve identity across the request 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.

Each link supports a specific control. The gateway identity enables cost attribution, the tool identity preserves data permissions, and the trace identifies the person behind the request. If the tool uses broad service credentials, any user may receive data available to that account.

Passing user context through a tool call takes more work than assigning broad service credentials. The tool should apply the requesting user's permissions whenever it accesses data.

Agents need identities of their own

An autonomous or scheduled agent needs its own workload identity. Human credentials give it permissions that were scoped for another purpose, stop working when the person leaves, and attribute automated actions to that person.

Give the agent a workload identity with its own permissions, and record both identities when it acts on someone's behalf. The record should identify the agent and the person who requested the action.

Identity lifecycle for AI systems

Review whether offboarding covers model provider consoles and agent tooling. Include vector databases and prompt-editing interfaces, along with tools bought on personal cards. Older procedures may omit these systems.

Check for leavers whose personal provider accounts still hold organization keys. Also review access after role changes, because old entitlements may remain and pass to any agent acting on that person's behalf.

Manage service accounts explicitly

AI stacks accumulate service accounts for indexers and batch jobs. Tools that need database access add more. Broad permissions are quicker to set than precise ones, which creates work during later access reviews.

Give every service account a named human owner and a scheduled access review. Use a separate account for each application so its permissions can be narrowed without breaking another application.

Questions to ask your vendor, or your own team

  • 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?