Key Takeaways
- A bearer token doesn't prove who is holding it. Any party that possesses one can use it, so a token is only as trustworthy as the check made before it was issued.
- Static credentials in configuration files are a common weak point. GitGuardian's 2026 report found 24,008 unique secrets exposed in MCP configuration files.
- The gap sits upstream of OAuth, with authorization servers that issue tokens without verifying the identity of the requesting client.
- Three layers help close the gap. Workload attestation, policy enforcement and short-lived tokens work together, with DPoP or mTLS helping prevent token replay.
An AI agent can have a valid token without proving it is the agent you intended to authorize.
The problem starts with how the agent gets the token. If it relies on a static credential stored in a configuration file, anyone who obtains that credential may be able to use it to get a token. GitGuardian’s State of Secrets Sprawl 2026 report found 24,008 unique secrets exposed in Model Context Protocol (MCP) configuration files.
In an MCP deployment, this creates a gap between possessing a credential and establishing an agent’s identity.
OAuth defines how an authorization server issues access tokens and how clients present them, but the strength of a token still depends on how the authorization server verified the client before issuing it.
Device authentication has long addressed this problem by using a unique credential that can be verified against a trusted authority. AI agents need a similar foundation: verify the workload first, then issue the token.
Bearer Tokens and What They Don’t Prove
An accepted token is not inherently trustworthy. A bearer token, for example, doesn’t prove identity, and any party that possesses it can access an organization’s resources.
While bearer tokens are the most common access token in OAuth 2.0, their lack of identity proof is a considerable security gap.
Bearer token best practices include always transmitting tokens over HTTPS to prevent interception and never storing them improperly. Before granting access, servers must validate tokens, including expiration, revocation status, signature, issuer and audience.
These controls protect a token once it exists. They don’t tell you whether the agent that received it was legitimate in the first place.
We Expect Proof of Identity From Devices. What About AI Agents?
Certificate-based authentication (CBA) for devices is the standard for enterprise organizations and has been for years. Users, computers and other devices must verify their identity with a cryptographic digital certificate before gaining access to a network or resource.
Compared with credential-based authentication (usernames and passwords), CBA is considerably more secure, making it much harder for the wrong parties to gain access.
But for AI agents accessing MCP servers, we’ve taken a step backward, relying on static credentials stored in configuration files. Static passwords and tokens that don’t prove identity can lead to unwelcome visitors accessing an organization’s systems.
July 2026, the Hugging Face incident showed the risks of exposed credentials and tokens in an AI agent environment. An OpenAI agent escaped its sandbox environment and subsequently accessed production Kubernetes pods, including the secrets and tokens stored in them. This gave the agent a foothold inside Hugging Face’s perimeter, illustrating how credentials available to an agent can provide a path to additional resources.
The Problem Sits Upstream of OAuth
When MCP servers require authorization, they rely on OAuth 2.1. OAuth allows an app to access resources without sharing user credentials with that app. It also scopes data access, as well as the access duration, so you don’t have to just trust that AI agents will only use the information you want them to access.
The problem isn’t with OAuth. The issue sits upstream, with authorization servers that issue tokens without verifying the identity of the requesting client. As long as a client has a token, it can walk right through the door, regardless of who it really is, making it an authorization policy issue instead of an OAuth one.
In addition to identity and policy, token lifetime must be addressed. The next section breaks each component down.
Steps to Take Beyond Static Credentials and Bearer Tokens
A stronger approach to closing the gap starts before the token is issued. Three components work together to establish identity, enforce access policies and limit token exposure.
1. Establish Workload Identity With SPIFFE
With SPIFFE (Secure Production Identity Framework for Everyone), workloads can establish their identities with cryptographically verifiable, short-lived SVIDs (SPIFFE Verifiable Identity Documents).
In SPIRE (SPIFFE Runtime Environment), workload attestation can be used to verify that a workload matches a registered identity before issuing an SVID. Each workload can then receive a unique identity that can be used for authentication. This reduces an organization’s reliance on static credentials and supports Zero Trust architectures.
2. Enforce Access With a Policy Decision Point (PDP)
PDP involves evaluating contextual inputs (resource attributes, subject identity, risk signals, tenant scope) and returning an authorization outcome for enforcement points to apply. This is directly applicable to AI agents requesting a token.
Once requested, the decision point checks the agent’s scope, tenant boundary and session purpose before constrained access is granted.
3. Use Short-Lived Tokens
Token replay (such as with longer-lived access and refresh tokens) is a common threat. Even if stolen, short-lived tokens significantly limit what attackers can do because they expire so quickly.
Add Another Layer With Sender-Constrained Tokens
Short-lived tokens limit how long a stolen token works, but they don’t stop it being replayed while it’s still valid.
RFC 9700, Best Current Practice for OAuth 2.0 Security, recommends that authorization and resource servers use sender-constrained access tokens to prevent token replays.
To reduce the risk of stolen and leaked access tokens being replayed, organizations can implement Demonstrating Proof of Possession (DPoP) or mutual TLS (mTLS).
DPoP binds an access token to a public key and requires proof of possession when the token is used. For organizations with Transport Layer Security (TLS) certificate infrastructure, mTLS can provide both client authentication and certificate-bound access tokens.
DPoP and mTLS can help ensure that possession of a stolen token alone isn’t enough to use it.
Don’t Stop at the Token
A valid token doesn’t tell you whether the correct workload received it. If you aren’t verifying what is holding that token or how it was obtained, you’re leaving an opportunity for bad actors to gain access to your systems.
Luckily, you can do something about it. Before issuing a token, verify the workload, enforce access policies and limit how long the token remains useful. Sender-constraining mechanisms such as DPoP or mTLS can add another layer of protection if a token is stolen.
Make the right decisions about what happens upstream of OAuth.
