TL;DR
AI agent authentication is how an agent proves which workload it is, and whose authority it carries, before an API, tool, or other agent trusts it. Give every agent its own workload identity by default. Use delegated user tokens only when the task depends on what one specific user may access. Retire static API keys and shared service accounts, because neither can tell you which agent did what. Prefer short-lived tokens bound to a single audience, and add proof of possession where the platform supports it. Log the agent, the user, and the credential behind every action, but never the secret itself.
Key Takeaways Authentication proves who is calling, while authorization decides what that caller may do, so design them as two separate controls. An agent should run under its own workload identity, and switch to a delegated user token only when user-specific access is needed. Shared service accounts destroy attribution, which turns any incident into guesswork about which agent acted. Short-lived, audience-bound tokens limit the damage of a leak far better than static API keys that live for years. MCP servers must accept only tokens issued for them and must never forward a client’s token downstream. Every log line should tie the agent, the originating user, and the credential ID to the action, with no secret values recorded. Watch on YouTube
How MCP Makes AI Smarter, Faster, and Business-Ready | Model Context Protocol
Kanerika explains how the Model Context Protocol connects AI agents to enterprise tools, and what it takes to run it in production.
The Breach That Ran on a Chat Agent’s OAuth Tokens
In August 2025, Google’s Threat Intelligence Group issued an advisory about a data theft campaign against Salesforce customers. The way in was not a Salesforce exploit.
Instead, the actor, tracked as UNC6395, walked in with stolen OAuth tokens. Those tokens belonged to Drift, Salesloft’s AI chat app, which customers had connected to their Salesforce orgs.
From as early as August 8 through at least August 18, those tokens let the actor export large volumes of records. After that, it searched the stolen data for more credentials, such as AWS access keys, passwords, and Snowflake-related access tokens. On August 20, Salesloft and Salesforce revoked every active access and refresh token held by the Drift application.
The uncomfortable lesson, then, is simple. A connected app that holds long-lived tokens is an identity, and attackers treat it as one.
AI agents copy that same pattern across dozens of systems. So AI agent authentication, the way an agent proves who it is, has become one of the first questions in agentic AI security .
What Is AI Agent Authentication?
AI agent authentication is the process an agent uses to prove its identity to the systems it calls. First, the agent presents a credential, such as a signed token or a client certificate. Then the receiving API, tool, or agent checks that the credential is genuine, current, and meant for it.
The IETF’s working draft on the subject puts the starting point plainly, in a section titled “Agents are workloads” . In other words, an agent is software that loops between a language model and a set of tools.
It should therefore authenticate the way modern services do, rather than the way people do. That draft (version 03, dated July 6, 2026) is still an Internet-Draft, so treat it as guidance rather than a ratified standard.
Authentication vs Authorization
The two words get blurred constantly, yet they answer different questions. Authentication asks who is making this request and whether the proof holds. Authorization then asks what that verified identity may do, against which resource, and for how long.
This guide stays on the first question. For the second, the agentic AI permission control framework covers action classes, grants, and revocation.
Meanwhile, the AI access control guide explains RBAC, ABAC, and policy models. Still, weak authentication breaks both, since a permission rule is only as good as the identity it is attached to.
Four Questions Every Agent Request Must Answer
Which agent is this? A unique, stable identifier for that specific agent instance or deployment.On whose behalf is it acting? Its own authority, or a named user who delegated part of theirs.What proves it? The credential type, who issued it, and when it expires.Who is the token for? The intended audience, so a token minted for one service cannot be replayed at another.If a request cannot answer all four, the receiving system is trusting it on faith. So the rest of this guide works through each answer in turn, starting with the identity the agent carries.
Who Does an AI Agent Authenticate As?
An agent can carry three kinds of identity, and choosing between them is the most consequential decision in the design. If you get it wrong, no amount of token hygiene will fix attribution later.
Its Own Workload Identity
Here the agent is a first-class principal in your identity provider, with its own client ID or service identity. As a result, every call it makes is recorded under that name, and you can rotate, restrict, or disable it without touching anything else. For autonomous jobs, such as a nightly reconciliation agent, this is the right default, and it fits cleanly into a well-designed AI agent architecture .
In OAuth terms, an agent acting for itself typically uses the client credentials grant from RFC 6749. That RFC says the grant must only be used by confidential clients. As a result, the agent needs a safe place to hold whatever proves it is that client.
On Behalf of a User
Some tasks, on the other hand, only make sense with the user’s own access. An assistant that drafts replies from a manager’s inbox should see that manager’s mail, and nobody else’s. So the agent exchanges the user’s token for a new one that names both parties.
RFC 8693, OAuth 2.0 Token Exchange , defines this pattern. A delegation token carries the user as the subject and the agent in an “act” (actor) claim, so downstream systems can see both identities.
Vendors are also building on the same idea. For instance, Microsoft Entra Agent ID lets agents act for signed-in users through on-behalf-of flows that require consent.
When the user is not sitting in front of the agent, the OpenID Client-Initiated Backchannel Authentication (CIBA) flow helps. The agent asks the identity provider to reach the user on a separate device, and the user approves there. This model also shows up in AI agent integration work, where agents sit inside tools people already use.
A Shared Service Account, and Why It Fails
The tempting shortcut is one service account for every agent, often with broad rights inherited from an older integration. At first, it works.
Then the first incident arrives, and every log line points to the same account. Now nobody can say which agent ran the query or which user asked for it.
Shared accounts also make revocation blunt. For example, if one agent leaks the credential, you must break all of them at once to contain it.
Identity model Use it when What the log shows Main risk Agent’s own workload identity The agent works autonomously or for the whole business The specific agent Over-broad scopes if nobody reviews them Delegated user identity Access depends on one user’s rights The user plus the acting agent Consent fatigue and long-lived refresh tokens Shared service account Avoid for agents One account for everything No attribution, blunt revocation, wide blast radius
The table settles the default. Start with a dedicated identity per agent, add delegation where the task is personal, and treat any shared account as debt to pay down.
Kanerika Service
Agentic AI Services
Kanerika designs, builds, and secures enterprise AI agents with their own verifiable identities, scoped tokens, and audit trails.
Explore Agentic AI Services AI Agent Authentication Methods Compared
Once the identity model is set, the next choice is the credential that proves it. Five methods cover nearly every enterprise case, and they differ most in how long a credential lives and whether a thief can reuse it.
API Keys
API keys are the simplest option and the weakest. The IETF draft calls static API keys an antipattern for agent identity.
That is because they are bearer artifacts with no cryptographic binding and no identity, and they usually live long and resist rotation.
OAuth 2.0 Client Credentials and Token Exchange
OAuth 2.0 client credentials give the agent short-lived access tokens issued by an authorization server. The agent still has to prove it is the client, so the real question becomes how that client secret or key is protected.
Token exchange under RFC 8693 swaps one token for another with a narrower audience or an added actor. As a result, it suits delegation and multi-hop calls, where each service should receive a token minted for it alone.
Workload Identity Federation and Managed Identities
Federated and managed identities remove the stored secret entirely. Take Microsoft Entra workload identity federation as an example.
A workload in GitHub Actions or Kubernetes trades its own platform token for an Entra token, so nobody manages a secret. Google Cloud documents the same approach, along with a guide to migrating away from service account keys .
Mutual TLS and Proof of Possession
Mutual TLS and proof of possession bind a token to a key the agent holds. RFC 8705 covers mutual-TLS client authentication and certificate-bound tokens. Similarly, RFC 9449 (DPoP) does the same at the application layer and lets servers detect replayed tokens.
Checklist
AI Governance Checklist
A practical checklist to confirm agent identities, owners, credentials, and audit evidence before AI agents go live.
Get the Checklist → Method Proves identity? Typical lifetime Stolen credential reusable? Best fit Static API key Weakly, often shared Months or years Yes, anywhere Legacy tools only, behind a vault OAuth client credentials Yes, per client Minutes to hours per token Yes, until the token expires Autonomous agents calling APIs Token exchange (RFC 8693) Yes, user plus actor Short, per audience Only at the named audience Delegation and multi-hop calls Workload identity federation Yes, from the platform Short, issued at runtime Limited, no stored secret Agents on cloud or Kubernetes mTLS or DPoP binding Yes, tied to a key Short, bound to the key No, without the private key High-risk APIs and payments
Most teams end up combining methods. A common pattern starts with federation to obtain the agent’s own token. Next, exchange narrows it per call, and binding protects the few APIs where a stolen token would hurt most.
Why Short-Lived, Audience-Bound Tokens Beat Static Secrets
A leaked secret is a timing problem. GitGuardian’s State of Secrets Sprawl 2025 counted 23,770,171 new secrets in public GitHub commits during 2024.
It also found that 70% of the secrets leaked in 2022 were still valid. A static key that leaks today may still work years from now.
Short-lived tokens cap that exposure window by design. So a sound agent token carries four properties.
Issuer that the receiver trusts and checks.Audience naming the one service allowed to accept it.Scope limited to the task at hand.Expiry measured in minutes or hours, not months.Equally, audience matters as much as expiry. If a token minted for a reporting API is accepted by a payments API, a single leak travels further than anyone intended.
For that reason, receivers should reject any token whose audience is not their own. High-risk services should also demand a sender-constrained token through mTLS or DPoP.
The SPIFFE project, which the IETF draft cites, shows what this looks like at scale. It provisions short-lived workload credentials automatically at runtime, so no human ever copies a secret into a config file.
How to Store, Rotate, and Revoke Agent Credentials
Agents add a new hiding place for secrets, namely the model’s own context. Anything placed in a system prompt, a tool result, or long-term memory can be echoed back to a user or exfiltrated through prompt injection . Therefore, keep every credential out of prompts, out of code, and out of agent memory.
The OWASP Secrets Management Cheat Sheet frames the work as a lifecycle of creation, rotation, revocation, and expiration. It also recommends dynamic secrets, which are generated per session so nothing long-lived waits to be stolen. In practice, that means three habits.
Inject at runtime. The agent fetches a credential from a vault or the platform’s identity endpoint when it starts a task, and the tool layer attaches it to calls the model never sees.Rotate automatically. Rotation that depends on a calendar reminder tends to fail, so schedule it in the platform and alert when it does not run.Rehearse revocation. Know how to kill one agent’s tokens in minutes without breaking every other agent, then test that path before an incident forces it.The Drift case shows why the last habit matters. Containment required revoking every token tied to the app, which is far easier when each agent has its own credential.
Credential retirement belongs in AI agent lifecycle management too, so a decommissioned agent leaves no live secret behind. The same discipline applies to wider data security programs.
Datasheet
Elevate Data Governance , Compliance and Security
See how Kanerika helps organizations secure data access, manage credentials, and keep audit evidence ready.
Download the Datasheet → How Should AI Agents Authenticate to MCP Servers?
The Model Context Protocol has become a common way for agents to reach tools, so its authentication rules deserve a close read. The current revision of the MCP authorization specification , dated July 28, 2026, builds on the OAuth 2.1 draft.
Authorization is optional in MCP, but remote HTTP servers that support it should conform to the spec. For background on the protocol itself, see this explainer on the Model Context Protocol .
Remote HTTP Servers
For a remote server, the agent’s MCP client gets a token from the server’s authorization server and presents it on each request. The spec requires clients to use RFC 8707 resource indicators to name the exact server the token is for. It then requires servers to validate that every token was issued specifically for them, and to reject any token sent in a URL query string.
On-Demand Webinar
Strategies to Reduce LLM Security Risks
An on-demand Kanerika webinar on the practical controls that keep enterprise LLM and agent deployments secure.
Watch the Webinar → Servers advertise where to get tokens through OAuth protected resource metadata (RFC 9728). Sometimes a request needs more access than the token carries. In that case, the spec describes a step-up authorization flow in which the client asks for a token with added scopes.
Local STDIO Servers
Local servers that talk over standard input and output follow a different rule, however. The spec says STDIO implementations should not use the OAuth flow and should instead retrieve credentials from the environment. That is convenient, yet it also means a local server inherits whatever secrets sit in the environment it launches from, so scope those variables tightly.
Why Token Passthrough Is Forbidden
Token passthrough happens when an MCP server accepts a client’s token and forwards it unchanged to a downstream API. The MCP security best practices call it an anti-pattern, and the specification explicitly forbids it. After all, it lets tokens cross service boundaries they were never meant for.
It can also create a confused deputy, where the downstream API trusts the request as if the MCP server had vetted it. Instead, the server should get its own credential for each downstream system and keep the client’s token at its own boundary.
Agent-to-Agent Authentication and Delegation Chains
Multi-agent systems turn one request into a chain. A planner hands work to a researcher, which calls a data agent, which queries a warehouse. As a result, each hop is a fresh trust decision, and in agentic AI systems those hops multiply quickly.
The safe pattern is to authenticate each agent as its own workload and to carry the user’s identity forward explicitly. With token exchange, every hop can mint a token for the next audience.
That token names the original user as subject and the calling agent as actor. RFC 8693 allows actor claims to nest, so the full chain stays visible.
{
"iss": "https://idp.example.com",
"aud": "https://warehouse-api.example.com",
"sub": "[email protected] ",
"exp": 1793900400,
"act": {
"sub": "agent:data-retriever",
"act": { "sub": "agent:research-planner" }
}
}In this illustrative token, the warehouse sees that the data-retriever agent is acting for Maria, and that a planner agent called it first. RFC 8693 treats the outermost actor as the current one, so policy applies to the user and that agent. The nested planner entry is a history trail for audit, and the RFC says not to use it in access decisions. Delegated authority across these chains is covered in Kanerika’s unified AI governance architecture guide.
Above all, two rules keep chains honest. First, never let an agent pass its own token to another agent, since the receiver would then act with the sender’s identity. Second, never trust an identity claim that arrives in message text or tool metadata, because only a verified token proves anything.
When an Agent Should Ask a Human to Step Up
Some actions, however, deserve fresh proof that a person still wants them done. Wiring money, deleting records, or emailing a customer on someone’s behalf all fall in this group. A token issued at nine in the morning says little about what the user intends at four in the afternoon.
Step-up authentication handles this by asking the user to verify again, at the moment of the sensitive action. CIBA fits agents well, because the request reaches the user’s phone while the agent waits.
The IETF draft’s human-in-the-loop section names CIBA for this, so the user approves on their own device without the agent ever seeing their credentials.
In addition, bind the approval to the specific action rather than the session. An approval for “pay invoice 4471 for $8,200” should not let the agent pay a different invoice ten minutes later. The design of when a human approves, and who, is covered in Kanerika’s guide to human-in-the-loop AI agents .
Logging Agent Identity So Every Action Is Attributable
Authentication is only half done if nobody can reconstruct it later. When a regulator, auditor, or incident responder asks who changed a record, the answer should come from the log in seconds. So every agent action needs an identity trail that survives hand-offs between agents and tools.
Record these fields for each call.
Agent identifier and version. Originating user, if the agent was acting for one. Credential or token ID (the jti claim, or a hash), plus issuer and audience. Tool or API called, resource touched, and result. Any approval or step-up event linked to that action. At the same time, keep secrets out. The OWASP Logging Cheat Sheet lists access tokens, session identifiers, passwords, and database connection strings among the data to keep out of logs.
Instead, mask, hash, or encrypt those values. Agents make this harder, because a model may paste a tool’s raw response into a trace, so scrub traces as well as application logs.
AI agent observability ties traces to identities, and the same records double as evidence for AI compliance reviews and for the policy reporting described in the generative AI governance program.
AI Agent Authentication Decision Matrix by Scenario
No single method fits every agent. For that reason, the matrix below maps common enterprise scenarios to an identity model, a credential, and the extra control that matters most.
Scenario Identity model Credential Extra control Scheduled back-office agent, no user Own workload identity Federated or managed identity, then client credentials Narrow scopes, automated rotation Assistant working in one user’s mail or files Delegated user identity On-behalf-of or RFC 8693 token exchange User consent, short refresh lifetime Agent calling another agent Each agent’s own identity, user carried forward Token exchange per hop, with actor claims Audience check at every hop Agent using a remote MCP server Agent identity or delegated user OAuth token with RFC 8707 resource indicator No token passthrough downstream Agent using a local STDIO MCP server Host process identity Environment credentials Tightly scoped variables, no shared shells Payments, deletions, or external email Delegated user identity Sender-constrained token (mTLS or DPoP) Step-up approval bound to the action Legacy tool that only accepts API keys Own workload identity, wrapped Vaulted key behind a gateway Rotation plus replacement plan
Where several agents share one legacy key, a broker helps. An LLM gateway or identity proxy can hold the key, authenticate each agent separately, and log who used it.
Case Study
65% Self-Service Resolution with an AI Support Agent
Kanerika built an AI member support agent that resolves routine queries with context, cutting manual search and turnaround time.
Read the Case Study → A Six-Step Plan to Put Agent Authentication Into Production
Inventory agents and their connections. List every agent, the systems it calls, and the credential it uses today, starting from your data access governance records.Assign an identity model. Choose workload or delegated identity per agent, and flag every shared account for removal.Replace stored secrets. Move agents onto federation or managed identities where the platform allows, and vault what remains.Tighten tokens. Set audience, scope, and expiry on every token, and add binding for high-risk APIs.Test the hard paths. Rehearse revocation, a multi-hop delegation, and a step-up approval as part of AI agent evaluation .Turn on attributable logging. Confirm that one query can answer which agent acted, for whom, with which credential.Teams usually finish steps one and two in a few weeks, since they are mostly discovery. Steps three and four take longer, because each platform has its own identity features, so sequence them by risk rather than by system. Funding and ownership for that sequence belong in the wider AI governance strategy .
How Kanerika Builds Verifiable Identity Into Agent Programs
Kanerika designs AI agent authentication during the build, long before any security review. Our agentic AI services teams build agents one workflow at a time. We pick the workflow and design the agent, including the tools it may call and where a person approves before it acts.
Then we connect it with scoped access to ERP, CRM, and documents. We test it on historical cases before go-live and run it with monitoring and audit logs. Identity design, rotation, and revocation drills sit inside those steps.
AI Assessment
How Ready Are Your AI Agents for Production?
Take Kanerika’s AI Maturity Assessment to see where your agent identity, credentials, and controls stand today.
Start Your AI Assessment → In our experience, ownership is usually the first gap. In one engagement, a global logistics provider that sells, leases, and services equipment had unclear ownership of hosted applications and a pile of redundant apps. Then a malware attack forced servers offline.
Kanerika established clear ownership, removed redundant applications, and closed security gaps. The case study reports a 90% decrease in security vulnerabilities. Agent credentials need the same named owner.
We also build agents that hold up in production. A member support agent Kanerika delivered reached 65% self-service resolution for its client. Kanerika holds ISO 27001, ISO 27701:2019, and SOC 2 Type II.
In addition, our AI governance consulting team maps these identity controls to the client’s audit evidence. The pitfall we watch for most is a pilot that quietly keeps its demo API key after go-live.
Wrapping Up
The Drift campaign showed what happens when a connected app’s tokens outlive anyone’s attention, and every AI agent is another connected app.
Start with the agents that touch money or customer data, and extend the same rules to the rest of your agentic AI governance program.
Frequently Asked Questions
What is AI agent authentication?
AI agent authentication is the process an AI agent uses to prove its identity to the APIs, tools, and other agents it calls. The agent presents a credential such as a signed token or certificate, and the receiving system checks that it is genuine, unexpired, and issued for that system before trusting the request.
How is AI agent authentication different from authorization?
Authentication answers who is making the request and whether the proof holds. Authorization answers what that verified identity may do, on which resource, and for how long. Agents need both, but they are separate controls, and a permission rule is only as reliable as the identity it is attached to.
Should an AI agent have its own identity?
Yes, in most cases. A dedicated workload identity per agent makes every action attributable, lets you rotate or disable one agent without breaking others, and keeps scopes reviewable. Switch to a delegated user token only when the task depends on what one specific user is allowed to see or change.
Are API keys safe for AI agents?
Static API keys are a poor fit for agents. They are bearer secrets that usually live for months, carry no real identity, and work for anyone who copies them. Where a legacy tool demands one, keep it in a vault or gateway, rotate it on a schedule, and plan its replacement with short-lived tokens.
How does OAuth work for AI agents?
An agent acting for itself usually uses the OAuth client credentials grant to get short-lived access tokens. An agent acting for a user exchanges that user’s token, through on-behalf-of or RFC 8693 token exchange, for a narrower token naming both the user and the agent. Each token should target one audience.
How do AI agents authenticate to MCP servers?
For remote HTTP servers, the MCP authorization specification uses OAuth. The client requests a token for the exact server using a resource indicator, and the server must reject tokens issued for anyone else. Local STDIO servers instead read credentials from their environment, so those environment variables must be scoped tightly.
What is token passthrough and why is it dangerous?
Token passthrough is when a server accepts a caller’s token and forwards it unchanged to another service. The MCP specification forbids it because tokens then cross boundaries they were never issued for, and downstream systems may wrongly trust the request. The server should obtain its own separate credential for each downstream system.
How do you authenticate agent-to-agent calls?
Authenticate each agent as its own workload, then carry the user forward explicitly. With token exchange, each hop receives a fresh token for its own audience that names the original user as subject and the calling agent as actor. Never let one agent hand its own token to another agent.
Can AI agents authenticate without storing secrets?
Often, yes. Workload identity federation and cloud managed identities let an agent trade a platform-issued token for an access token at runtime, so no long-lived secret sits in code or configuration. Microsoft Entra and Google Cloud both document this approach for workloads running in pipelines, Kubernetes, and other clouds.
What should an AI agent audit log record?
Each entry should record the agent identifier and version, the originating user, the credential or token ID with issuer and audience, the tool or API called, the resource touched, the result, and any linked approval. It should never record access tokens, passwords, or connection strings, which belong masked or hashed.
