Many organizations deploying AI agents have not fully answered how those agents authenticate to services, what credentials they carry, or what happens to those credentials when the task ends. In some organizations, the agents work, so the question gets deferred.
The problem is that “it works” is doing a lot of heavy lifting. The agent works because it has an API key hardcoded into its configuration, or because it is running under a shared service account that has broad permissions, or because it inherited a user’s OAuth token and nobody has revoked it yet. The task completes. The logs show something happened. But there is no reliable record of which agent did it, under whose authority, or whether those credentials should still be active.
This is the default state of most agentic deployments todayl It is what happens when teams move fast on agent capabilities without a corresponding investment in the identity and auth infrastructure that should be underneath them.
Why AI Agents Break Traditional IAM Assumptions
Traditional IAM was built around a set of assumptions that are reasonable for human users: identities are known in advance, they authenticate from recognizable locations, they access defined resources, and their access patterns are relatively predictable. Access decisions get made at authentication time and enforced at the perimeter.
AI agents break most of these assumptions.
A single agent task might involve authenticating to an external API, reading from a database, calling a third-party tool, and writing results somewhere, all within a single autonomous workflow. Each of those steps crosses a service boundary. Each requires credentials. Unlike a human user following a deliberate sequence of actions, the agent may make those calls in any order, at any time, based on reasoning that is not directly visible to the systems it is calling.
Agents are also not static workloads. Many are ephemeral, spun up per task and torn down when it completes. Their required permissions vary by what they are doing, not just what they are. An agent running a read-only research task needs a different access profile than the same agent running a task that modifies production data, even if it is the same underlying model and codebase.
And when an agent acts on behalf of a human user, the downstream services it calls need to know two things: which agent is acting, and which user authorized the action, with what permissions. When that second piece is missing, authorization decisions downstream are made with incomplete information.
How Most Teams Are Handling Agent Auth Today
The most common pattern for autonomous agents is hardcoded credentials. API keys embedded in agent configurations, in system prompts, or in environment variables of the orchestration layer. This works until the credential is compromised, rotated, or shared with another team, at which point there is typically no way to determine which agents were using it, for what, or for how long.
Shared service accounts are similarly common. Multiple agents, or agents and humans, operating under the same identity. No per-agent attribution, no task-scoped permissions, no audit trail that is meaningful at the agent level. When something goes wrong, the logs show the service account acted. That is a starting point for an investigation, not a conclusion.
Delegated human tokens introduce a different failure mode. An agent inherits a user’s OAuth session and carries that token into downstream calls. The scope is often broader than the agent needs. The token may not expire when the task ends. When the user’s session is eventually revoked, the agent may break in ways that are hard to trace because the dependency was never explicit.
A variation of this is the passed API key: a tenant owner holds a credential, a team member needs access, the owner passes the key, the team member gives it to the agent. The credential chain is several hops long and identity is effectively lost at each one. The logs reflect the owner’s identity. There is no record of who actually initiated the work.
Finally, many internal agents call internal services with no authentication at all, relying on network trust. This was a reasonable approach in tightly bounded microservice architectures. It becomes a liability when agents have access to external tools and services that span organizational or trust boundaries.
To make the passed-key problem concrete: some SaaS platforms with MCP integrations handle authentication cleanly for tenant owners, routing them through a standard OIDC redirect that ties the agent’s access to a verified user identity. But non-owner users on the same team often cannot use that path. They need an API key obtained from the owner and handed to the agent. From that point, every action the agent takes is attributed to the owner. There is no record of which team member initiated it, which agent ran it, or what the task was scoped to. The tool works. The audit trail does not.
What Authentication and Authorization Actually Need to Look Like
Start with Identity: One Agent, One Identity
The foundation is that each agent instance needs its own cryptographically verifiable identity. Not a role. Not a shared service account. Not a credential borrowed from a human user. An identity that is unique to that agent, verifiable at runtime, and scoped to its actual lifetime.
IAM for Agentic AI provides this. It gives workloads an identity that is attestable based on runtime context: the platform they are running on, the workload they are executing, the environment they are operating in.
The IETF WIMSE working group (Workload Identity in Multi-System Environments) is actively standardizing this space. WIMSE is chartered to address the specific gaps that show up in multi-service, multi-cloud deployments: how workloads establish identity, how that identity is carried across service boundaries, and how OAuth, JWT, and SPIFFE interoperate in practice. Proposed standards covering JOSE-based token formats, token exchange profiles, and claim mapping are working through the IETF process. This reflects broad industry recognition that workload identity needs the same kind of standardization that human identity got from OIDC and OAuth.
Attestation: The Step Before Authentication
For human users, authentication asks whether someone is who they claim to be. For agents, there is a prior question: is this workload actually running in the environment it claims, executing the code it claims, on the platform it claims.
That is attestation, and it is where agent authentication should start. Before any credential is issued, the workload’s identity is verified against its runtime context. This is not a one-time check at deploy time. It is a verification that the agent presenting itself for authentication is the workload it claims to be, running where it says it is running.
Once attestation establishes that foundation, authentication can proceed with confidence. OAuth 2.1 with PKCE is the emerging standard for agent-to-service authentication. OIDC tokens handle cross-service trust. mTLS handles east-west authentication for agent traffic within a service mesh.
Attestation and authentication answer different questions. Attestation asks whether the agent is what it claims to be. Authentication asks whether that agent is permitted to talk to this service. Both questions need answers.
Authorization: Scoped to the Task
Authentication establishes identity. Authorization determines what that identity can do. For agents, authorization needs to be more granular than it typically is for human users, because the range of actions an agent might take in a single session is wide and not always fully predictable in advance.
The practical direction is least-privilege per task rather than per agent type. An agent running a research workflow needs read access to specific data sources. That same agent running a workflow that modifies configuration needs different permissions. The agent’s identity is consistent; the authorization should reflect what it is actually doing in the moment.
Just-in-time access makes this tractable. Rather than granting standing permissions that the agent holds indefinitely, credentials are issued for the specific task and expire when it completes. The window for credential misuse is bounded by the duration of the task rather than the lifetime of the agent.
Dynamic, policy-based authorization handles this at scale. Rather than pre-configuring access rules for every possible combination of agent and resource, policy enforcement evaluates requests in context: what the agent is doing, which resources it is accessing, and under what conditions.
Every action should produce a log entry that includes the agent’s identity, the task context, and enough detail to reconstruct what happened. Attribution is not just a compliance consideration. It is what makes incident response possible.
Blended Identity: When Agents Act for People
A harder problem is when an agent is not acting autonomously but acting on behalf of a specific user. The agent has its own workload identity. The user who initiated the task also has an identity, and that identity carries authorization context that downstream services need to make correct access decisions.
Blended Identity addresses this directly. The agent carries its own verifiable workload identity through the call chain. The user’s identity and authorization context travel alongside it. Downstream services can see both: which agent is acting, and on whose behalf, with what user-level permissions.
This matters because authorization decisions are frequently user-dependent. An agent acting for a user with read-only access to a system should not be able to perform write operations, even if the agent’s own workload identity would otherwise permit it. Without Blended Identity, a downstream service either sees only the agent and grants agent-level permissions regardless of who asked, or sees only the user and loses the auditability of the agent’s involvement. Neither is accurate.
The passed-key scenario from earlier illustrates the cost of not having this. If the non-owner user’s identity and authorization context were preserved and propagated through the agent, there would be a complete, attributable record of who asked for what, through which agent, at what time. Instead, there is a key that could belong to anyone.
MCP Tool Access: A Privileged Operation
Model Context Protocol gives agents structured, tool-based access to external services. That is useful, and it expands the authorization surface area that needs to be managed.
OAuth 2.1 is emerging as the auth layer for MCP servers. When the server is designed to support it, the OIDC redirect path ties agent access to a verified user identity and the auth story is reasonably clean. The gaps appear in multi-tenant and delegated-access scenarios, where the server’s auth model does not map to the actual user doing the work and the fallback is a shared credential with no attribution.
Each MCP tool invocation should be treated as a privileged operation: authorized against a policy, not just authenticated at connection time. The agent’s identity, the user’s context when applicable, and the specific tool being called should all factor into whether the call is permitted.
What This Looks Like End to End
Consider an agent running a research task: pull keyword data from an external analytics tool, retrieve competitor content from the web, write a summary to a shared workspace.
With the right auth stack in place, the flow looks like this. The agent bootstraps with a short-lived workload identity token, attested against its runtime environment. The user who initiated the task is identified, and their authorization context travels with the agent through the call chain alongside the agent’s own identity.
When the agent connects to the analytics tool’s MCP server, access is authorized on behalf of the specific user, with the user’s identity context preserved alongside the agent’s workload identity. The web fetch and workspace write use separately scoped, short-lived credentials issued for those specific operations. Every step is logged with both the agent’s identity and the user’s context. When the task completes, the credentials expire.
The alternative: the user does not have direct access to the analytics tool. They get an API key from whoever owns the account, pass it to the agent, and the agent runs all three operations under the owner’s identity. Nothing in the logs indicates who initiated the task. Nothing marks the credentials as task-scoped or time-bound. The key stays active. Three operations, one credential, no attribution.
The security gap between these two paths is real.
Getting the Basics Right
A practical starting point for teams building or auditing agentic authentication:
- Give every agent a unique, verifiable identity scoped to its workload context.
- Use runtime attestation, not only deploy-time configuration.
- Issue short-lived credentials scoped to the task.
- Authenticate at every service boundary.
- Preserve user identity and authorization context when an agent acts on someone’s behalf.
- Treat MCP tool invocations as privileged operations.
- Log every agent action with enough context to reconstruct who initiated it, which agent acted, and what access was used.
Wrapping Up
The auth patterns being used for AI agents today were designed for a different model of software. Static roles, shared credentials, and perimeter trust were built for workloads that are predictable and human-initiated. Agents are neither, and the gaps that result are practical and immediate.
The standards work is moving in the right direction. WIMSE, OAuth 2.1, OIDC for workloads, and attestation frameworks are all maturing. The challenge is applying them to agentic workloads systematically, rather than leaving each team to discover the limitations of the shared-credential path on their own.
See how Aembit handles workload identity and Blended Identity for AI agent workflows. Request a demo or get a free tenant today.
