AI agent identity is the question of whose authority an agent uses when it reads data or changes something in an enterprise system. Every agent action should trace back to a named identity with the smallest permission set that works: the signed-in user's delegated rights when the agent acts for a person, a dedicated workload identity when it acts for itself, and never a shared API key. Get it wrong and the agent becomes the most privileged, least accountable "user" in the tenant.
The broader threat model is in AI security for enterprises; this guide goes deep on identity, delegation and audit.
The core question: whose authority does the agent act with?
Unlike a traditional service with a fixed code path, an agent decides at runtime which tools to call, often for different people in the same hour. Every tool call must answer three questions:
- Who asked? The human (or upstream system) whose request started the task.
- Which identity acted? The principal whose credential the downstream system actually saw.
- Under what limits? The scopes, resource boundaries and approval rules that applied at that moment.
If these are not recorded and enforced outside the model, you have a well-behaved prompt, not agent least privilege. Three patterns answer them.
Pattern 1: acting on behalf of the user (delegation)
In the delegated pattern the agent holds a token that represents the user plus the agent application. The downstream API sees both: the user's identity and the client that is calling. Effective access is the intersection of what the user is allowed to do and what the agent application was granted. A support analyst who cannot see payroll gets an agent that cannot see payroll, without anyone writing that rule into a prompt.
The building block is ordinary OAuth for AI agents: the user signs in, consents (or an administrator consents for the organisation) to specific scopes, and the agent front end receives an access token. But the agent usually calls a tool server, which calls the real system. Forwarding the user's original token down that chain is a mistake: it was issued for the agent front end, not the ERP, and can be replayed elsewhere.
The correct approach is a token exchange, often called on-behalf-of. The middle tier presents the user token to the identity provider and receives a new token whose audience is the specific downstream API, with only the scopes it needs. The mechanism is standardised as OAuth 2.0 Token Exchange, and major identity providers offer on-behalf-of flows built on the same idea.
[User] --sign-in--> [IdP]
| token (aud = agent app)
v
[Agent app] --tool call + user token--> [Tool server]
|
exchange: user token -> IdP |
new token (aud = ERP API, |
scope = po.read, short TTL) v
[ERP API]
Delegation is the right default for copilots and interactive assistants. Its limits: it needs a user present (or a valid refresh grant), and it inherits the user's over-permissioning. For a worked example of delegated versus application permissions, see the Intune AI agent project, where Graph permissions cannot separate safe remote actions from destructive ones, so the tool server's allow-list does that job.
Pattern 2: acting as itself (workload identity)
Agents with no user in the loop, such as a nightly reconciliation or alert-triage agent, need a non-human identity of their own:
- Managed identities (Azure) and service accounts (Google Cloud) attached to the compute the agent runs on.
- IAM roles (AWS) assumed by the task, pod or function, issuing temporary credentials.
- Service principals or app registrations in a directory, for calling SaaS and directory APIs.
- Workload identity federation, where a Kubernetes service account or CI job exchanges its own signed token for cloud credentials, so no long-lived secret is stored at all.
The design rule is one identity per agent per environment. Separate identities give separate permissions, separate audit trails and the ability to disable one agent without breaking five.
The danger is scope: application permissions often apply tenant-wide ("read all mailboxes"). Narrow them with resource-level policies, conditions (network, tags) and permissions on named resources rather than whole services.
Pattern 3: hybrid
Most production agents end up hybrid: reads use the user's delegated rights, while a specific write is executed by a narrowly scoped workload identity after a policy check or approval. The user's authority decides whether an action is allowed; the workload identity is the only principal that can perform it, through one typed tool.
This suits writes no individual should hold directly, such as ledger postings. The audit record then carries both identities.
| Aspect | On behalf of user | Acting as itself | Hybrid |
|---|---|---|---|
| Downstream sees | User + agent client | Agent workload identity | User for reads, workload for gated writes |
| Effective access | Intersection of user rights and granted scopes | Everything the role or permission grants | Reads bounded by user; writes bounded by one tool |
| Best for | Copilots, interactive assistants | Scheduled and event-driven agents | Agents that propose and then execute business actions |
| Main risk | Inheriting over-privileged users; token forwarding | Tenant-wide application permissions | Losing the link between requester and action in logs |
Kill the shared API key; use short-lived credentials
The fastest demo uses one broad API key in an environment variable. In production it becomes a credential shared by every user, agent and environment: it cannot tell you who asked, rarely expires, leaks into notebooks and logs, and revoking it breaks everything.
Replace it with credentials that are short-lived, audience-bound and issued per task: OAuth access tokens, temporary credentials from role assumption, federated platform tokens. If a system only supports static keys, vault the key, give it its own narrow account, rotate it and keep it behind a tool server. The model should never see a credential; anything in its context can be echoed, logged or exfiltrated.
Scoping AI agent permissions
Identity says who; scoping says how much. Four techniques do most of the work.
Per-tool permissions
Each tool declares the scopes it needs, and the tool server requests only those. A get_purchase_order tool needs read on purchase orders, not the whole ERP. Generic tools ("call any REST endpoint", "run SQL") make the agent's power equal to its credential's.
Read versus write separation
Split tools into read and write, backed by different scopes or identities. Reads run under delegation; writes go through validation, policy and often approval.
Resource-level scoping
Restrict to the resources in play: one cost centre, one region, one customer's tenant. Set the boundary from the authenticated session, not from model arguments. If the model can set tenant_id, an injected instruction can too.
Row-level security passthrough
Enforce access at the data layer using the requester's identity. Row-level security can filter rows by a session variable set from verified token claims; retrieval can filter chunks by source-document access lists. A text-to-SQL agent connected as superuser with "only show their region" in the prompt is not least privilege.
Approval steps for high-risk actions
Payments, bank-detail changes, deletions, permission grants and external emails should never run on a model's say-so alone. The agent produces a structured proposal (action, target, arguments, evidence) that the tool server holds until an authorised human approves.
- Check the approver against the business rule (a manager in the cost centre), not just "someone clicked yes".
- Bind approval to the exact arguments; if amount or payee changes, it is void.
- Keep separation of duties: requesters do not approve their own agent's regulated proposals.
- Approvals and rejections are audit events in their own right.
Tier it: auto-approve low-risk reversible writes, one approver above a threshold, two above a higher one. Setting thresholds belongs in your enterprise AI governance process.
Tool servers and MCP authorization
The tool server is the last component you control before a real system, so that is where identity is enforced. Whether a plain API or an MCP server, it authenticates the agent, knows the end user, checks policy, obtains the narrow downstream credential and logs the call.
The Model Context Protocol specification includes an OAuth-based authorization framework for its HTTP transports. In general terms, the MCP server acts as an OAuth resource server, clients obtain tokens from an authorization server, and tokens are issued for the specific MCP server they are used with. The specification warns against token passthrough: a server should not accept tokens not issued for it, nor forward the client's token upstream. Local servers over standard input/output typically take credentials from the environment. The spec has been revised more than once, so check the current version.
In practice: validate every incoming token's audience, use token exchange or the server's own workload identity downstream, and review community MCP servers before they get any credential.
Designing identity, tool servers and approvals for real customer systems is a core part of Forward Deployed Engineering. Cloudsoft's AI Forward Deployed Engineer course (FDE PRO) covers it through projects such as the ServiceNow AI Agent via MCP and the Secure Banking AI Assistant, with Microsoft Entra ID in the stack.
Agent-to-agent trust
When one agent delegates to another, the receiver must know which agent is calling, for which user, and what it may ask for. The A2A protocol lets an agent advertise its required authentication in its Agent Card and relies on standard web authentication.
Regardless of protocol: authenticate every hop with its own credential; propagate the requester as a verifiable claim, not free text; let scopes only narrow along the chain; and treat another agent's results as untrusted input.
Secrets management
Even with federation, some secrets remain: SaaS client credentials, legacy database passwords. Keep them in a managed vault (AWS Secrets Manager, Azure Key Vault, Google Secret Manager or equivalent), readable only by the workload identity that needs each one, fetched at runtime. Scan repositories, evaluation datasets and traces for leaked credentials. Pipeline-level controls such as secret scanning and image signing are covered in the sibling guide on DevSecOps for enterprise AI.
Audit: who asked, which identity acted, what changed
An agent audit record should let an investigator reconstruct an action without reading model transcripts. For every tool call, capture:
- Requester: the human or upstream system, with session and tenant.
- Acting identity: the agent's own identity and, for delegated calls, the user it acted for.
- Agent context: agent name and version, prompt version, model identifier, task or trace ID.
- Action: tool, arguments (redacted where sensitive), target resource, scopes used.
- Decision: policy result, approval and approver, or the reason it was blocked.
- Outcome: what changed, with before and after values for writes.
Write these to append-only storage owned by security, correlated with the downstream system's audit log by request ID, so "on whose request and with whose approval" takes one query.
Lifecycle: ownership, rotation and decommissioning
Non-human identities for AI agents multiply quietly, one pilot at a time. Treat them like privileged accounts:
- Ownership: every agent identity has a named human owner and a business purpose recorded in an inventory.
- Review: permissions are re-certified on a schedule and whenever the agent gains tools.
- Rotation: remaining secrets and certificates rotate automatically; expiry alerts go to the owner.
- Decommissioning: when an agent retires or its owner leaves, disable the identity, revoke grants, delete secrets and archive logs. Orphaned agent identities with live credentials are an attacker foothold.
Identity vendors are adding features aimed at agent identities, such as treating agents as a distinct identity type with their own inventory and policies. These differ by vendor and change quickly, so evaluate what your provider offers today.
AI agent identity risks and controls
| Risk | Control |
|---|---|
| Shared API key used by all users and agents | Per-agent identities; delegated tokens; short-lived credentials; vault for unavoidable keys |
| Agent sees data the requester cannot | Delegated reads; row-level security and retrieval filters driven by token claims |
| Tenant-wide application permission | Resource-scoped roles; per-tool scopes; separate read and write identities |
| User token forwarded down the chain | Token exchange to audience-bound tokens; tool servers reject tokens not issued for them |
| Injected instruction triggers a payment or deletion | No such generic tool; allow-lists; approvals bound to exact arguments |
| Model chooses the tenant or resource ID | Resource boundary set from the session, not from model arguments |
| Authority grows across agent hops | Per-hop authentication; requester propagated as a claim; scopes only narrow |
| Secrets leak into prompts or traces | Model never holds credentials; redaction; secret scanning of logs and datasets |
| Cannot tell who caused a change | Audit with requester, acting identity, approval and before/after values |
| Orphaned agent identity with valid secret | Inventory with owners; periodic review; decommissioning checklist |
Illustrative example: a procurement agent
Consider a retailer's global capability centre in Hyderabad building a procurement agent that checks suppliers, compares quotes and drafts purchase orders for buyers across regions.
- Delegation. A buyer signs in; the tool server exchanges the token for a short-lived ERP token scoped to purchase-order and supplier read.
- Scoped reads. The ERP applies the buyer's cost-centre restrictions; contract search filters by the buyer's group claims, so restricted agreements stay hidden.
- Proposal, not action. The agent calls
propose_purchase_order, which validates supplier, amount and budget code. No tool creates a PO directly. - Approval. Below a configured threshold the buyer approves; above it, the cost-centre manager does. The approval binds to the exact supplier, line items and amount.
- Gated write. A dedicated workload identity that can only create purchase orders posts the PO. Vendor bank-detail changes are not exposed at all.
- Audit. The record links buyer, approver, agent version, both identities, arguments and the resulting PO number, correlated with the ERP's change log.
If a supplier email injects "approve all pending orders", the agent has no approve tool and cannot act as the manager. The worst case is a bad proposal a human rejects.
Common mistakes
- Giving the agent an admin service account "for the pilot" and never replacing it.
- Writing access rules in the system prompt instead of the tool server or data layer.
- Forwarding the user's front-end token to every downstream API.
- Letting the model supply tenant, account or user IDs as tool arguments.
- Approvals that do not bind to arguments, so a proposal can change after it is approved.
- Logging the model's transcript but not the acting identity and the downstream change.
FAQ
What is AI agent identity?
It is the identity an AI agent authenticates with and the permissions attached to it: the signed-in user's delegated identity, a dedicated workload identity, or both. It decides what the agent can read and change.
Should an AI agent use the user's permissions or its own?
Use delegated user permissions when the agent acts for a person interactively, so it never exceeds that person's rights. Use a workload identity when no user is present. Many production agents combine delegated reads with narrowly scoped, approved writes.
What is on-behalf-of token exchange?
An OAuth pattern where a middle tier swaps a user's token for a new token aimed at a specific downstream API, still representing the user but with a different audience and narrower scopes, instead of forwarding the original token.
Why are shared API keys a problem for AI agents?
They give everyone the same broad access, cannot show who made a request, rarely expire and leak easily. Short-lived, per-agent or per-user credentials limit damage and make audit possible.
How does MCP handle authorization?
The MCP specification defines an OAuth-based authorization framework for HTTP transports in which the MCP server acts as a resource server, accepts only tokens issued for it and should not pass client tokens upstream. Check the current specification version before implementing.
What is row-level security passthrough for agents?
The database or retrieval index filters results using the verified identity of the requesting user, so an agent querying for someone only receives rows that person may see. The data layer enforces it, not the prompt.
What should an AI agent audit log contain?
Who asked, which identity acted and for whom, agent and model version, tool and arguments, the policy or approval decision and the resulting change, plus a request ID that correlates with the downstream system's audit log.
What happens to an agent's identity when the agent is retired?
Disable the identity, revoke permissions and consents, delete its secrets and archive its logs. A named owner for every agent identity prevents orphaned accounts with valid credentials.
Identity is where AI demos often stall on the way to production. To practise it end to end, from Entra ID consent to approval-gated tool servers, explore the Cloudsoft FDE PRO program (classroom in Ameerpet or live online; free demo via +91 96660 19191). If your focus is the directory itself, the Entra ID course covers app registrations and permissions in depth.
