Agent Identity and Access Control: A Whitepaper

The first generation of enterprise AI agents was deployed the fast way: a service account with broad permissions, or an integration that reused the logged-in user's session. It worked in the pilot. It fails in the audit, and it fails badly in the incident, because nobody can say which agent did what on whose behalf, and revoking access means breaking something else.

This whitepaper sets out a reference model for agent identity and access control. It is written for security architects, identity teams, platform engineers, and the risk and audit functions that will be asked to sign off on agent deployments. It covers why agents need identities of their own, how to model delegated authority, how to permission tools, how to handle secrets, what to log, and how to run the lifecycle. It extends FISTA's AI agent security architecture whitepaper.

Why do agents break the existing identity model?

Enterprise identity models were built for two kinds of principal: people and services. Agents are a third kind with properties of both, plus one that neither has.

Property	Human user	Service account	AI agent
Acts on its own initiative	Yes	No; deterministic code	Yes, within a role
Acts on behalf of a specific user	Sometimes	Rarely	Usually
Actions are predictable in advance	Loosely	Fully	Partially; plans vary with input
Can be manipulated by content it reads	Yes, socially	No	Yes, through injected instructions
Needs approval gates	Sometimes	No	Yes, for consequential actions

The last two rows are the crux. An agent can be steered by the data it processes and it may take actions its designers did not enumerate. That is why an agent needs a bounded identity of its own: not to prevent it from working, but to guarantee that even a steered agent cannot exceed its role. The threat model is described in AI agent security risks.

What is the reference model?

FISTA's model has five components. Each maps to something identity teams already run, adapted for agents.

Component	Purpose	Implementation pattern
Agent identity	A distinct principal per agent role, with an owner and a lifecycle	Workload identity or service principal, registered in the agent registry
Delegated context	The user or process on whose behalf the agent acts	Token exchange or on-behalf-of flows; user identity carried on every call
Tool permissioning	What each tool may do, per agent role	Per-tool scopes; read / reversible / consequential classification
Credential brokering	How the agent obtains secrets	Short-lived credentials issued at call time by a broker; never in prompts
Audit and review	Evidence of who did what	Structured logs keyed by agent and user; scheduled access reviews

The model works whether agents reach systems through direct API calls or through a Model Context Protocol gateway; the gateway simply becomes the natural enforcement point for components three through five.

How should delegated authority work?

Most useful agents act for someone: a support agent for a customer, an HR agent for an employee, a finance agent for an approver. The effective permission on any action must be the intersection of two things: what the agent's role may ever do, and what the delegating user may do right now.

That intersection is what prevents the two classic failures. Without the role bound, an agent acting for an administrator can do anything the administrator can, including things the agent should never do. Without the user bound, an agent with a broad role can do things for a user that the user could not do themselves. Both are privilege escalation, and both are common in pilot deployments.

Implementation follows existing patterns: the user's identity is carried into the agent runtime, exchanged for a token that encodes both principals, and presented on every tool call. Systems that cannot evaluate two principals get a per-agent principal plus an application-layer check against the user's entitlements before the call is made.

How should tools be permissioned?

Permission tools, not agents in the abstract. Each tool an agent can call should have:

• A classification: read, reversible write, or consequential write.
• A scope: the narrowest principal that can perform it.
• An owner: the team responsible for the underlying system.
• Conditions: which agent roles may use it, and whether a human gate applies.

Consequential actions should be separate tools rather than modes of a general tool, so they can be withheld from most agents and gated for the rest. A tool named update_customer with a free-form payload cannot be permissioned meaningfully; update_customer_contact_details and close_customer_account can. Design guidance is in how to design tool permissions for AI agents.

How should secrets be handled?

Agents need credentials to act, and the wrong place to keep them is anywhere the model can see them. Prompts, context windows, retrieved documents, and tool outputs are all readable by the model and, through injection, potentially by an attacker.

The correct pattern is a credential broker. The agent runtime authenticates with its own identity, requests a short-lived credential scoped to the tool and the delegated user, uses it, and lets it expire. The broker logs every issuance. A leaked prompt then reveals nothing of lasting value, and a compromised environment yields credentials that expire in minutes. Details, including rotation and environment isolation, are in secrets management for AI agents.

What must be logged?

Every action should produce a structured record with at least:

Field	Why it matters
Agent identity and version	Which role and which configuration acted
Delegated user or process	On whose behalf
Tool and classification	What kind of action
Parameters and target record	What exactly was touched
Approval status and approver	Whether a human gate applied and who cleared it
Outcome and error	What happened
Trace identifier	Link to the full reasoning trace and any retrieved content

The trace identifier is what turns a log into an investigation tool: it lets a reviewer see what the agent read before it acted, which is essential when the question is whether an injected instruction caused the action. Building the trace pipeline is covered in how to build an AI audit trail.

How does the lifecycle work?

Agents are created, changed, and retired, and access must follow.

1. Registration: the agent is entered in the registry with an owner, a role description, tools, classifications, and delegated-context rules.
2. Provisioning: identity and scoped principals are created; no shared accounts.
3. Review: on a schedule, owners attest that the role and permissions are still correct; unused permissions are removed.
4. Change: spec and tool changes go through the same review; an agent gaining a consequential tool is a change worth a gate.
5. Incident: a kill switch disables the agent's identity centrally; see AI agent kill switch design.
6. Retirement: identity revoked, credentials invalidated, registry entry archived with its audit history.

How does the model map to existing standards?

None of this requires new standards; it requires applying existing ones to a new principal type.

Need	Existing mechanism	How it applies to agents
Agent identity	Workload identity frameworks such as SPIFFE, or cloud service principals	Each agent role gets a verifiable identity issued by the platform, not a static key
Delegated context	OAuth 2.0 token exchange (RFC 8693) and on-behalf-of flows	The user's token is exchanged for one that names both the agent and the user
Tool authorization	Fine-grained scopes and policy engines already used for APIs	Scopes are defined per tool; the policy engine evaluates agent role, user entitlements, and tool classification together
Secrets	Existing secrets managers and short-lived credential issuance	The agent runtime is a client of the broker like any workload
Audit	Existing SIEM and log pipelines	Agent logs carry the extra fields listed above and feed the same detection rules

Identity teams should resist building a parallel stack for agents. The winning move is to register agents in the identity platform that already governs services, extend the schema with the agent-specific fields (owner, role, tool classifications, delegated-context rules), and reuse the review, revocation, and monitoring processes that auditors already recognize. Where a legacy system cannot evaluate two principals or issue short-lived credentials, put the enforcement in the gateway in front of it rather than weakening the model for everything else.

What are the common mistakes?

1. Agents under human sessions. Convenient, unaccountable, and over-privileged.
2. One service account for all agents. Cannot revoke one without breaking all; logs are meaningless.
3. Secrets in prompts or configuration. Exposed to injection and to anyone reading logs.
4. General-purpose write tools. Cannot be classified, scoped, or gated.
5. No registry. Six months in, nobody can list which agents reach the ERP.
6. Access reviews that skip agents. Human access is reviewed quarterly; agent access grows unreviewed.

How does FISTA Solutions help?

FISTA Solutions designs and implements agent identity and access control as part of its AI enablement practice and builds every AI agent it delivers on this model: distinct identities, delegated context, per-tool permissions, brokered secrets, and structured audit logs. Our forward deployed engineers work with your identity and security teams so the controls fit your existing platform rather than a parallel one. FISTA has delivered 150+ projects across 12+ countries and does not deploy agents on shared accounts.

If your agents are reaching production systems on borrowed credentials, talk to FISTA on WhatsApp about an access-model review, or continue with non-human identities for AI agents.