OAuth co-founder says the protocol "can't protect AI agents" as vendors roll out workarounds

AI agents are accessing business systems on behalf of humans more and more often, and voices at the center of the industry are now pointing to the limits of OAuth itself, the standard for authentication and authorization. Work on OAuth began in 2006, led by Dick Hardt and others, and resulted in OAuth 2.0, published as RFC 6749 in 2012. Hardt, one of its co-founders, said bluntly, according to an article reporting his remarks, that "OAuth is a protocol designed for a web where humans make every call, and it has not resolved this mismatch." His point is that OAuth assumes a flow in which a human grants authorization in a browser each time. That design is fundamentally at odds with how AI agents behave, with machines issuing large numbers of requests on their own and at high speed. Nearly 20 years after standardization began, the core assumptions of the standard are being called into question.

Phishing experiment targets OAuth authentication

The concern is not just theory. Security company Varonis has published the results of a test of phishing resistance using GPT-5.4 and Gemini 3.1 Pro on OpenClaw, an agent development platform that runs locally. The test used four types of phishing email. In one, a fake time-tracking app asked for Google OAuth 2.0 authentication, and both models judged it suspicious and stopped. In another, an external Gmail address posed as an internal system outage and asked for access to the production environment. Here both models handed credentials to the outside party, both in Generic mode, the default defense setting, and in Strict mode, which applies tighter constraints. Varonis said that "agents lack social memory, organizational intuition, and the discomfort people feel at unusual requests," and warned that their eagerness to be helpful could itself become a new attack surface. The results show that constraints written into prompts are not enough on their own to push agents toward safe decisions.

Pairing SPIFFE with OAuth

In response, Palo Alto Networks states flatly in a company blog post that "simply issuing OAuth authorization tokens or static API keys is not a practical security measure for enterprise deployments." The company proposes giving each agent a short-lived, cryptographically verifiable identity through SPIFFE (Secure Production Identity Framework for Everyone), a CNCF project, as its base identity. On top of that, an OAuth flow is layered for when the agent acts on behalf of a specific user. The idea separates two things: the lasting proof of identity the agent holds as a machine workload, and the temporary delegated authority it holds when acting for a human. SPIFFE SVIDs renew automatically every few minutes to few hours, which is seen as a key strength because it keeps the window for abuse as small as possible if one leaks.

Implementation updates from Cisco Duo and Okta

Efforts to make authorization more fine-grained are also taking concrete form. Cisco Duo announced in a company blog post that, in line with the latest MCP specification released on November 25, it has added Resource Indicators (RFC 8707) and Dynamic Client Registration (RFC 7591) to its MCP integration and its OAuth 2.1/OIDC integration. With Resource Indicators, an agent can name the resource it wants to access when it requests authorization, which stops a token meant for one service from being reused at another. Duo said support for Client ID Metadata Documents is also in the works. Okta, meanwhile, is using its "Cross App Access" feature to fix the gaps in authorization that appear in existing OAuth when agents work across multiple apps on their own. These efforts share one goal: preventing "privilege bloat," in which a single token keeps too many permissions across multiple services.

Enterprise deployments and open questions

On the implementation side, NTT Data has published an architecture built on AWS Bedrock AgentCore. It combines user authentication with JWT access tokens issued by Okta and the OAuth 2.0 Authorization Code Flow for the Salesforce integration. For Tableau, which does not support OAuth, it uses Gateway Interceptors to implement custom authentication, which shows how several authentication methods can end up side by side even within a single architecture. Cloudflare has also adopted RFC 9728 in its managed OAuth for Access as part of an effort to make internal apps ready for agents. The companies are taking different approaches, but they increasingly agree that "OAuth alone is not enough; short-lived tokens, limited scopes and a machine identity foundation are essential." How well standards bodies and the industry can coordinate during this transition will determine how secure agent authentication becomes.