AI agent identity management: How to govern access and delegation
Whose authority does your AI agent use when it changes a business record? Explore how AI agent identity management connects permissions, delegated access, credentials, and audit evidence so teams can control actions and withdraw access when needed.
- Give production agents distinguishable identities with clear owners, purposes, and scoped permissions.
- Define whether each integration uses a user’s delegated authority or the agent’s service permissions.
- Enforce access restrictions outside the model, and bind approvals to specific actions and parameters.
- Short-lived tokens do not guarantee task-bound access. Test how to stop execution, block renewal, and revoke downstream access.
- Connect agent activity, authorization decisions, and downstream changes through correlated audit records.
- Managed identity services still require careful configuration of roles, credential access, and logging.
- Before production, demonstrate that unauthorized requests are denied, consequential actions can be traced, and access can be withdrawn.
A support agent prepares a renewal summary, reads customer records, and updates a CRM entry. Later, a customer disputes a change. The activity log points to a shared integration account.
Which agent made the update? Was it acting for a support representative or running a scheduled task? Who approved the change, and can the security team stop further access without interrupting unrelated applications?
In this illustrative scenario, the investigation starts with missing identity and authorization evidence. A successful API call tells the team that a credential worked. It leaves other questions unanswered.
AI agent identity management connects an agent's access to an accountable owner, an appropriate source of authority, and enforceable permissions. For businesses moving agents into production, those connections determine how confidently teams can investigate activity and contain mistakes.
What is AI agent identity management?
AI agent identity management is the practice of registering, authenticating, authorizing, monitoring, and retiring the identities and credentials agents use to access systems.
Agent workload identities belong within the broader discipline of non-human identity management, which also covers service accounts and other workloads. User identities remain relevant when an agent acts on someone's behalf. Agents make the relationships between identity, task, and authority especially important because they can select tools and perform sequences of actions across systems.
These questions establish the foundation:
A unique identifier answers only the first question. It does not establish that the agent should read every customer record or change a contract.
Existing identity principles remain relevant. NIST’s February 2026 draft concept paper on software and AI agent identity and authorization examines how identification, authorization, delegation, and logging apply to agents. The paper explores a proposed demonstration project rather than defining a final standard. The practical challenge is applying identity controls consistently across the agent’s execution and downstream integrations.
Should AI agents have their own identity?
Production agents should be distinguishable wherever ownership, permissions, or isolation requirements differ. Giving several unrelated agents the same broad integration account makes both access reviews and investigations harder.
That does not require a new permanent identity for every tool call. A useful design separates a durable agent identity from the context of each execution.
For the renewal assistant, the durable record might identify its owner, production environment, purpose, and approved CRM integration. An execution record would identify the support representative, customer request, task identifier, and timestamps. Together, these records explain which workload acted and why that particular execution began.
Choose identity boundaries around meaningful differences. A renewal assistant and a finance reconciliation agent may need separate permissions and owners. A development deployment should be isolated from production customer data unless access is explicitly authorized for a controlled purpose.
Amazon Bedrock AgentCore represents agents through workload identities. AWS describes these as stable identity anchors across deployment environments and credential types. That identity can support consistent attribution while the credentials used for particular integrations change.
Preserve authority across every tool call
A user signing in to an agent application establishes their identity at the entry point. Each downstream integration still needs an appropriate authorization design.
Suppose a support representative may access customers assigned to their region. If the renewal assistant queries the CRM using an organization-wide administrator credential, the representative's restrictions may disappear at that boundary. A prompt telling the model to respect regional access is an inadequate enforcement mechanism.
There are two common authority patterns to evaluate.
User-delegated access
Use delegated access when the agent performs work for a particular user and the downstream system should enforce that user's permissions.
AWS documents an AgentCore architecture that exchanges authenticated user context for a user-scoped Salesforce token. Salesforce then applies its own sharing rules. The integration depends on configured identity mappings, token exchange, and downstream authorization.
For the renewal assistant, the intended result is that the CRM rejects requests for records outside the representative's access, even if the agent asks for them. Test that denial directly with representative users from different regions.
Machine-to-machine access
Scheduled work may use application or service authority. An overnight process checking upcoming renewals does not necessarily have a person initiating each run.
Give that workload a defined purpose, accountable owner, and scoped service permissions. Reading renewal dates may be appropriate; modifying payment details may require a separate workflow.
AgentCore supports both machine-to-machine and user-delegated access patterns. The choice belongs at the integration level: one agent may need different authority patterns for different tools.
Build AI agent access control around business operations
IAM for AI agents needs to connect technical permissions with the work the business has approved.
Start with operations. The renewal assistant may need to read contract dates, retrieve approved terms, and save an internal summary. Those requirements do not automatically justify bulk exports, contract amendments, or discounts.
For each tool, define the accessible records, permitted actions, allowed destinations, and approval requirements. Enforce those restrictions through trusted application components, authorization services, and downstream controls outside the model's discretion.
A narrowly defined tool is easier to govern than an unrestricted execution interface. For example, a tool that writes a renewal note can constrain the record and fields accepted. A general-purpose database tool can expose a much wider range of operations unless other controls restrict it.
Approval must also connect to execution. If a manager approves one discount for one customer, the system should bind that approval to the relevant operation and parameters. A generic approval message in the conversation leaves too much interpretation to the agent.
AgentCore Policy provides deterministic authorization for tool requests through associated AgentCore Gateways. Its enforcement covers that traffic path. Direct calls that bypass the Gateway need their own controls.
For Model Context Protocol (MCP) integrations, token handling is another boundary. Official MCP security guidance prohibits token passthrough: an MCP server must not accept a token that was not issued for that server and forward it to a downstream API. Validate inbound tokens for the MCP server and obtain separately authorized credentials for downstream access.
What AgentCore Identity provides, and what teams must configure
Amazon Bedrock AgentCore Identity provides building blocks for agent authentication and credential management, including workload identities, credential storage, and supported OAuth flows. These capabilities help implement an access design; teams still need to define its boundaries.
The credential-provider boundary deserves particular attention. AWS states that an agent's IAM role controls which credential providers it can call. The service does not enforce an additional binding between workload identities and providers within the same account. AWS therefore recommends scoping IAM resource permissions to the intended workload identity and credential-provider ARNs. Permission to call a provider does not automatically return credentials: for three-legged OAuth (3LO), the user must first have authorized access for that workload identity and user combination.
For the renewal assistant, review whether its execution role can request only the credentials needed for its approved integrations. A unique workload identity does not compensate for a role that can reach unrelated providers.
Two useful implementation references are AWS's credential-provider scoping guidance and user-authorization propagation example. Use them to examine specific access paths and denial conditions in your environment.
Define what your AI agents are allowed to do
Short-lived credentials still need a shutdown plan
Credential storage, token lifetime, and permission lifetime solve different problems. A vault protects stored secrets. A short-lived access token limits how long that token remains usable. Neither establishes that access ends with a business task.
Refresh capability changes the picture. For supported OAuth authorization-code flows, AWS documents AgentCore storing access tokens and any refresh tokens returned by the provider, then using those refresh tokens to obtain replacement access tokens after expiry. This supports continued authorized access, potentially across multiple tasks.
For each integration, record which credentials can be renewed, what grants allow that renewal, and how access is withdrawn. Task-bound access requires explicit lifecycle controls.
Consider what happens if the renewal assistant begins making incorrect updates. Stopping its scheduler prevents new scheduled runs, but an active execution or previously issued credential may remain usable. Removing access to a credential provider can block future acquisition without necessarily invalidating credentials already issued.
Revocation behavior varies across integrations. Record which shutdown steps block credential issuance, invalidate issued tokens, or end active sessions, and how long each takes. One disable operation may not produce immediate denial across every system.
Make audit evidence usable during an investigation
Logs should let an investigator connect an agent execution to its authority and consequences.
For a consequential CRM update, preserve enough evidence to answer: which workload ran, which user or service authorized it, which task triggered it, what operation was requested, which policy allowed it, and what the CRM actually changed?
Use correlation identifiers across execution records, tool requests, authorization decisions, and downstream activity where supported. An application log saying “update successful” is less useful than a record that can be matched to the CRM's transaction or change history.
Logging needs deliberate configuration. AWS states that AgentCore Gateway CloudTrail data events must be explicitly enabled. For JWT-authenticated Gateway data events, identity is captured through selected JWT claims rather than standard AWS identity information. Error details also appear within responseElements. Existing investigation queries may need adjustment. Gateway data-event request and response contents are redacted, so these events alone cannot reconstruct changed CRM fields. Correlate them with appropriately protected application records and downstream change history.
Test the evidence with a denied request and an approved change. Confirm that the team can reconstruct both. Protect logs with appropriate access and retention controls, and avoid recording credentials or unnecessary customer content.
Recorded instructions and actions support investigation. They cannot reliably establish a model's intent or prove that an authorized action served the intended business purpose.
Manage the identity through its full lifecycle
The following framework is a practical implementation aid. Revisit it whenever an agent's purpose, tools, environment, or owner changes.
Identity management also has boundaries. Two correctly authenticated agents could independently make conflicting changes or repeat the same operation. Coordinated change queues, concurrency controls, and idempotency checks help address risks that identity controls alone cannot resolve.
Before approving production access, ask the owner to demonstrate three things: an out-of-scope request is denied, a consequential action can be reconstructed, and access can be withdrawn through a tested procedure. Those demonstrations turn an identity design into operational evidence.
Put identity requirements into the implementation plan
For the renewal assistant, a useful starting deliverable is an access map covering each tool, its authority source, permitted operations, credential lifecycle, and evidence trail. Security and platform teams can review that map before expanding access to additional systems.
Applify’s AI agent development services include integration with business systems. Start the discussion with one production workflow and map its authority sources, permitted operations, credential lifecycle, and evidence requirements before extending access.
