An AI agent is an identity. Treat it like one.
Shared API keys and over-permissioned service accounts are how most AI deployments reach data today. Control issues distinct identities to users, service accounts, agents, and models, and scopes each one with roles and attributes, so an agent acting for a user can never see more than that user can.
Four kinds of actors, each addressable in policy.
| Identity | How it is established | Typical scope | Common mistake it prevents |
|---|---|---|---|
| User | Federated from your existing identity provider; groups map to roles | What the person can open in source systems | AI answers that include records the user could not open directly |
| Service account | Issued by Control with scoped, rotating credentials | A single application or pipeline | One long-lived key shared by every integration |
| AI agent | Registered with an owner, purpose, and tags | Explicit datasets and tools, intersected with the user it serves | An agent inheriting an admin's full permissions |
| Model | An approved endpoint in the AI gateway registry | Which data classifications may be sent to it | Regulated data reaching an unapproved or external model |
On whose behalf? The question shared keys cannot answer.
When an agent retrieves a document for a user, two identities are involved: the person who asked and the agent doing the work. Control records both and computes effective permission as the intersection: the agent can only reach what it is scoped to and what the user is entitled to. A broadly scoped agent serving a junior analyst sees what the analyst sees. A narrowly scoped agent serving an administrator sees only its own scope.
Source-system permissions are evaluated at query time, not copied once at ingest. If a user loses access to a SharePoint folder or a database role, their AI requests stop returning that content without waiting for a re-index.
RBAC for the baseline, ABAC for the exceptions.
Roles express what a job function needs. Attributes on subjects, resources, and context handle the cases roles cannot: department, region, matter assignment, environment, or the classification of the data itself.
id: agent:claims-triage
owner: user:j.alvarez
purpose: Summarize incoming claims and route to queues
tags: [rcm, read-mostly]
scope:
datasets: [claims.inbound, claims.payer_rules]
tools: ["mcp:ticketing/create_ticket"]
delegation:
mode: on_behalf_of # effective = agent scope ∩ user entitlements
require_user: true # no unattended runs
credentials: managed # issued and rotated by ControlIllustrative example · final API surface documented in /docs
Identities that stay accurate after day one.
Owned agents
Every agent has a named human owner. When the owner leaves, the agent is flagged for reassignment instead of running indefinitely.
Managed credentials
Control issues and rotates agent and service-account credentials, so connectors and tools never hand raw secrets to a model.
Least privilege by default
New agents start with no access. Scope is added explicitly, reviewed in Git, and visible in the simulator.
Access reviews
List every identity with access to a classified dataset, and which role, attribute, or delegation granted it.
What happens when an agent acts for a person.
Take a claims-triage agent asked by an analyst to summarize new claims. The agent authenticates with its own token and names the analyst it is acting for.
- 1
Authenticate the agent
The gateway checks the agent's token, which is stored only as a hash. Suspended or retired identities and revoked or expired tokens are refused before anything else is evaluated.
- 2
Resolve the person
The on-behalf-of user must be a known member of the organization. If the agent is configured to require a user, a request without one is refused rather than run unattended.
- 3
Evaluate twice
The request is evaluated once as the agent and once as the analyst. The stricter result wins, which is how agent scope intersected with user entitlement is enforced in practice.
- 4
Apply the ceiling
If the agent declares a scope, anything outside it is denied even when a broad allow would match. Scope is a hard limit, not a hint.
- 5
Record both identities
The decision log captures the agent, the person, the decision, and the policies involved, so an access review can see who really asked.
Avoiding role explosion without losing readability.
Pure role-based models are easy to read and easy to review, which is why they make a good baseline. They break down when access depends on a combination of facts: an analyst in one region, on one matter, in production, touching data with one label. Expressing that with roles alone means a role for every combination, and soon nobody can say what any role grants.
Pure attribute-based models solve that but can become opaque, because effective access is spread across many conditions. Control uses roles for what a job function needs and attributes for the narrowing conditions, then makes the result inspectable: the simulator and effective-permission views evaluate the same engine used in production, so the answer to "what can this agent reach right now?" is computed rather than inferred from documents.
A practical rule of thumb is to keep roles stable and few, push variable facts such as region, matter, environment, and classification into attributes, and write explicit deny rules for boundaries that must survive future changes to either.
Questions buyers ask
Do we have to recreate our users and groups in Control?
No. Users and groups are designed to federate from the identity provider you already run, and roles map to those groups. Agent and service-account identities are the ones Control creates, because most identity providers have no concept of them.
Is this RBAC or ABAC?
Both. Roles give a readable baseline for job functions, and attribute conditions handle region, matter, environment, and classification rules that would otherwise explode into hundreds of roles.
Can an agent run with no user behind it?
Yes, as a service-type agent with its own explicit scope, for scheduled jobs for example. Policies can treat unattended agents differently, such as requiring approval for any write action.
What happens when someone's access is revoked in the source system?
Source permissions are evaluated at query time, so the next AI request reflects the change. You do not have to wait for a sync or rebuild an index for revocation to take effect.
Are models really identities?
For access purposes, yes. A model endpoint is a destination for data, so policies can state which classifications each approved model may receive, independent of who is asking.
How are agent tokens protected?
Tokens are shown once when issued and stored only as hashes. They can be revoked or expired at any time, and disabling an identity stops it at the next request because every call is authenticated and evaluated.
Can one agent call another agent with more access?
The delegation chain is carried with the request, and the original user's limits still apply. An agent cannot borrow a wider-scoped agent's permissions to reach data its requester could not.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.