AI Agent Identity: Your IAM Was Built for Two Kinds of Users

Agents are a third identity class and your IAM has two

Identity systems were built for humans and for machines. Humans authenticate interactively, get reviewed quarterly, and leave the company. Machines hold static credentials, do one narrow thing forever, and never surprise anyone.

An agent is neither. It authenticates like a machine, acts with the breadth of a human, changes what it does when its instructions change, and can be pointed at a new system in an afternoon.

That mismatch is why the first AI access review at most retailers finds a service account with read access to the entire warehouse, shared by three tools, created by someone who left in March.

The four failures that show up in every review

Shared identities. Two agents on one service account. Your logs can no longer tell you which one ran the query, so your audit trail is decorative.

Static long-lived keys. An API key in an environment variable, set once, never rotated, present in three deployment configs and one Slack thread.

Over-broad scope. The agent needed six tables and got the schema, because granting the schema was one line and granting six tables was a ticket.

Inherited human permissions. The agent runs as an analyst's account, which means it can do everything that analyst can do, including the things nobody intended to automate. When the analyst is promoted, the agent's permissions change with them.

None of these are exotic. All four are normal engineering shortcuts that were fine for a nightly ETL job and are not fine for a system that decides its own next query.

The access model that works

One agent, one identity. Non-negotiable, because everything downstream depends on attribution.

Short-lived credentials. Workload identity federation or a token exchange, with a lifetime measured in hours. If your platform supports it, you should not be issuing static keys to agents at all.

Scope to tables, not schemas. Enumerate what the agent reads. The enumeration is also your data-scope registry entry, so it does two jobs.

Read by default, write by exception. Write access is a separate identity with a separate approval, not an extra grant on the read identity.

Row-level controls where they already exist. If a district manager cannot see other districts, the agent acting on their behalf should not either. Agents that ignore row-level security become a data exfiltration path that looks like a feature.

An expiry date. Every agent identity expires. Renewal requires an owner to confirm the agent is still running and still needs what it has. Most of the sprawl in any environment is things nobody turned off.

Delegated identity versus service identity

This is the design decision that most deployments get wrong, and it has two defensible answers depending on what the agent does.

Service identity: the agent has its own permissions and acts as itself. Correct for scheduled monitors that run without a person present. Simple to reason about, simple to log, and the permissions are stable.

Delegated identity: the agent acts on behalf of the user who asked, inheriting that user's permissions. Correct for interactive question-answering, because it means the answer respects whatever the user was already allowed to see.

The failure is using a service identity for interactive use. Then a store manager asks a question and gets an answer computed across all 400 stores, including labor cost data they have never been allowed to see. Nothing was breached. The permissions were simply bypassed by design.

The confused deputy problem, in plain terms

An agent with broad permissions taking instructions from a user with narrow permissions is a classic privilege escalation shape. The user cannot read the table. The agent can. The user asks the agent.

Two controls handle it. Delegated identity for anything user-initiated, so the agent never has more access than the requester. And an output filter for the cases where delegation is not possible, checking the result against the requester's entitlements before it is returned.

This matters more once agents can be prompted freely. A monitor that runs a fixed set of queries is bounded by its query set. A chat interface is bounded only by what the identity can reach, which is why the identity scope has to be right rather than convenient.

Running the access review

Add agent identities to the same quarterly access review cycle as employees. The reviewer is the named owner from the agent registry, and they answer four questions.

• Is this agent still running, and is anyone reading its output?
• Does its data scope still match what it does?
• Has its action tier changed since the last review?
• Who approved anything above read-only, and is that person still in the role?

Expect the first review to retire 20 to 40% of the agent identities in the environment. Most will be pilots that ended without anyone revoking the credential. That cleanup is the highest-value hour in the whole program.

What to require from a vendor

Ask whether they support a dedicated service principal rather than a shared login. Ask whether they can operate on short-lived credentials. Ask whether they honor your row-level security or bypass it. Ask what their credential is scoped to by default, and whether their default is read-only in the contract rather than in the settings screen.

A vendor whose onboarding asks for an admin account and a broad grant is telling you how the rest of the relationship will go. The good ones arrive with a scoped role definition and a list of the exact tables they need.

How Ward connects

Ward provisions one identity per deployment, scoped to an enumerated table list, read-only, with the grant script shipped for your team to review before anything connects. Interactive questions run under delegated identity, so an answer never crosses a boundary the asker could not cross themselves.

The credential is yours to revoke, and revoking it stops everything. That is the property that makes an access review meaningful.