What breaks when PKCE is used for agentic access but the client is not authenticated?

Why This Matters for Security Teams

PKCE was designed to stop code interception, not to prove that an agent, workload, or service is actually allowed to initiate the OAuth flow. That distinction matters because agentic systems often act on behalf of multiple users, services, or automations, and the token endpoint can become a trust shortcut if the client is not authenticated. In practice, PKCE can make the exchange look secure while the real control failure sits one layer earlier: identity binding.

This is the same pattern seen in agent abuse cases such as CoPhish OAuth Token Theft via Copilot Studio, where the attack path targets authorization trust rather than token mechanics. The broader risk is also visible in the AI Agents: The New Attack Surface report, which shows how quickly agent behaviour can drift beyond intended scope when governance is weak. When a client is unauthenticated, PKCE only tells you the same party completed the exchange, not whether that party should have been trusted in the first place. In practice, many security teams discover this after an agent has already obtained a valid token and started calling downstream systems.

How It Works in Practice

For agentic access, PKCE should be treated as one control in a larger workload identity design, not as a substitute for client authentication. The practical model is: prove what the agent is, prove what it is trying to do, then issue only the minimum token needed for that task. That usually means combining PKCE with client authentication, workload identity, and runtime policy checks.

In well-designed flows, the agent presents a cryptographic workload identity, such as an OIDC-backed identity or a SPIFFE-based identity, and the authorization server validates both the PKCE verifier and the client assertion before issuing tokens. The access decision should also consider context, including task, scope, tenant, risk level, and whether the request matches the agent’s expected behavior. NIST AI Risk Management Framework guidance supports this kind of layered governance, while the OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 both reinforce the need to treat non-human actors as first-class identities.

• Authenticate the client, even when PKCE is present, so the server can distinguish a real workload from an arbitrary requester.
• Use short-lived credentials and task-bound scopes so tokens cannot be reused far beyond the intended action.
• Evaluate policy at request time, not just at registration time, because agent behavior changes with prompts, tools, and context.
• Prefer workload identity over static secrets for agents that can chain actions, call tools, or delegate work.

This guidance breaks down in legacy OAuth deployments that only support public clients, static redirect handling, or broad scopes without runtime policy enforcement, because those environments cannot reliably bind a token request to a specific authenticated workload.

Common Variations and Edge Cases

Tighter client authentication often increases integration overhead, requiring teams to balance security against deployment complexity. That tradeoff becomes more visible in multi-tenant agent platforms, embedded agents, and local development tooling, where a single generic client can seem easier to operate but creates a weak trust boundary.

There is no universal standard for this yet, but current guidance suggests treating unauthenticated PKCE flows as acceptable only for very limited public-client scenarios, not for autonomous agents with execution authority. Where agents can act on behalf of users, the stronger pattern is to require both the PKCE proof and a separate workload credential, then bind the issued token to the specific agent instance or session. This reduces replay risk and limits token theft impact.

Edge cases also arise when teams try to use one client registration for many agents. That can obscure attribution and make abuse detection harder, especially when the same application ID is reused across environments. The Replit AI Tool Database Deletion incident shows how quickly autonomous tooling can produce real operational harm once trust is overly broad. For agentic systems, the safer default is unique workload identity per service, per environment, or per execution domain, with explicit revocation when the task ends.

Where the agent can self-initiate new actions based on prior outputs, static client trust breaks down fastest because the authorization server cannot distinguish a legitimate continuation from lateral movement.

Related resources from NHI Mgmt Group

• What breaks when organisations upgrade access platforms without checking license and client compatibility first?
• What breaks when access decisions are not time-bound in modern IAM programmes?
• What breaks when airline loyalty programs rely too heavily on status tiers and lounge access?
• What breaks when firewall rules are too permissive or ordered incorrectly in third-party access environments?