AI Agent Identity and Permissions: The Overlooked Design Problem

An AI agent’s identity is the credential it authenticates with when it calls a system, and its permissions are the entitlements attached to that credential. In most pilots neither is designed: the agent runs with a developer’s token, a shared service account, or the delegated session of whichever user triggered it.

Key takeaways

• An AI agent is a non-human principal. It needs its own identity, not a borrowed human one.
• Identity inheritance is the most common permission failure in agent pilots: the agent silently acquires every entitlement the user accumulated over years.
• Least privilege for agents is scoped per workflow, not per agent — one agent may legitimately need several narrow roles rather than one broad one.
• Attribution breaks before security does. If the audit log shows a human’s ID for an action the agent took, you cannot answer “who authorized this”.
• Design the identity, the scope, the approval gate and the audit trail together. Any one of them alone is incomplete.

In most pilots the permission model is whatever the borrowed credential already carried. That is the overlooked design problem. It does not announce itself, because the pilot works — the agent can reach everything it needs, precisely because it can reach everything the borrowed identity could. The problem surfaces later, in one of three ways: an action nobody can attribute, an entitlement review that cannot classify the account, or an agent reading untrusted content with permissions that let it do something about it.

This piece sets out how agent identity should be modelled, what breaks under inheritance, and the four controls that have to be designed as one thing.

Why can’t an AI agent just use the user’s access?

Because delegated human access carries scope the agent was never assessed for, and it destroys attribution.

Enterprise entitlements accumulate. A finance manager of six years holds access granted for a role they left, a project that closed, and a system they use twice a year. Those entitlements are tolerable for a human because human behavior is bounded by intent, working hours and the friction of navigating twelve systems. An agent has none of those bounds. Given the same token, it will use whatever the scope allows, at machine speed, whenever the workflow reaches a step that calls for it.

The second problem is attribution, and it is the one auditors raise first. If the agent authenticates as the user, the audit log records the user. The question “who approved this journal entry” returns a person who did not approve it and may not have been at their desk. Reconstructing what actually happened means correlating application logs with agent logs by timestamp, which is not an answer — it is a research project.

What an agent identity should look like

A distinct machine principal, per agent, per environment, with credentials that are short-lived and workload-bound.

The pattern is not new. Zero trust architecture treats every subject — human or machine — as an entity whose access is evaluated per request against policy, which is the model described in NIST SP 800-207. Applying it to agents means four properties:

• Distinct: One identity per agent, not one shared “automation” account. Shared accounts defeat both attribution and revocation.
• Environment-scoped: Separate principals for development, test and production. An agent that can be pointed at production from a developer’s laptop is a production system with a development change process.
• Short-lived credentials: Federated, workload-bound tokens rather than long-lived static keys where the platform supports it. A static key in a config file is the credential most likely to outlive the project.
• Classified as non-human: Tagged in the identity system so that joiner-mover-leaver processes, access reviews and anomaly detection treat it as what it is. An agent identity that looks like an employee will be reviewed as one, which means not at all.

That last point is where most of the operational value sits. An organization that cannot list its agent identities cannot run an access review over them, which is the same discovery problem as agent sprawl — an inventory is the prerequisite for governance, not a consequence of it.

Least privilege, scoped to the workflow rather than the agent

Give the agent the narrowest scope that lets each step succeed, and accept that this means several roles rather than one.

The instinct is to create an “agent role” holding the union of everything the workflow might need. That produces a role that is broad by construction and grows with every new use case. The better decomposition is per action: this agent may read supplier records, may create a draft requisition, and may not approve one. Three scopes, granted separately, revocable separately.

Four scope dimensions are worth being explicit about, because permission systems usually model only the first:

The fourth dimension is the one that lives outside the IAM platform. Most target systems cannot express “allowed, but only with a recorded approver”, so the orchestration layer has to. That gate is a design pattern in its own right, and it is what stands between an agent with write access and an agent that writes unsupervised.

Boundary scope deserves particular attention in ERP environments. An agent operating across a multi-ledger or multi-subsidiary structure needs its scope expressed in the system’s own terms — ledger, business unit, legal entity — rather than as blanket module access. Getting that wrong does not produce a security alert; it produces postings in the wrong entity, which is a finance problem discovered at period close. We cover that ground specifically in Oracle AI consulting.

The four controls that have to be designed together

1. Identity

A distinct, classified, environment-scoped machine principal with short-lived credentials.

2. Scope

Narrow entitlements per operation, with boundary filtering, granted and revoked independently.

3. Approval

An enforcement point in the orchestration layer that refuses irreversible or high-impact actions without a recorded approver. Policy that lives only in a document is not a control; the system has to be able to say no.

4. Audit

A log that records the agent principal, the tool called, the arguments, the approver where one was required, and the outcome — in a store the agent cannot write to.

These four fail as a set. Identity without scope gives you attributable over-access. Scope without approval gives you a narrow agent acting unsupervised inside that scope. Approval without audit gives you a control you cannot prove ran, which an auditor treats as a control that did not. The dependency between them, and the risk classes they contain, is mapped in the enterprise generative AI risk register.

The compounding case is worth stating directly, because it is the one that turns a nuisance into an incident. An agent that reads untrusted content — a support inbox, a supplier email, a web page — and holds write access to a system of record behind the same credential is one successful indirect prompt injection away from an unauthorized transaction. Splitting the read and the write across separate identities is what contains it, which is also one of the four conditions that justify splitting a workflow across single-agent and multi-agent designs.

What to do with an agent pilot that already runs on borrowed access

Sequence the remediation; do not try to fix it in one change.

1. Inventory – List every agent, the identity it authenticates with, and the systems it reaches. Most organizations discover more agents than expected at this step.
2. Attribute first – Even before scopes are narrowed, give each agent its own principal so the logs stop naming people for machine actions. This is usually the fastest meaningful improvement.
3. Observe, then narrow. Run for a period with the existing scope while logging every call, then cut the scope to what was actually used, plus a reviewed exception list. Narrowing by guesswork breaks workflows and erodes trust in the programme.
4. Split read from write. Separate credentials for any agent that touches untrusted input and privileged systems.
5. Add the approval gate for irreversible actions, and confirm the audit log captures the approver.
6. Put the identities into the access review cycle so the position holds without anyone remembering to maintain it.

Frequently asked questions