A few weeks ago in late March I hosted an event in San Francisco on the topic of “AI Agents” – what’s missing and what needs to happen for them to work.

Erich Elsen, the cofounder of Adept, an early agent platform that raised $300M+, and Sam Partee, cofounder of Arcade.dev, spoke at our event. I’ve been reflecting on their commentary, and wrote up this post (with the help of AI!) to catalog where agents stand today.

The overlooked bottleneck in agentic AI

There’s a gold rush around AI agents – the dream has taken hold of autonomous AI programs that can execute tasks, use tools, and coordinate workflows without constant human prompting or monitoring. 

We’ve seen progress on some fronts – memory stores, evaluation frameworks, and orchestration tools for these agents. 

Yet, after watching dozens of agent deployments, one reality has become clear: the true bottleneck to scaling AI agents isn’t their IQ – it’s their credentials. 

Authentication is the missing foundational layer of today’s AI agent stack and it’s holding back the next leap.

Without a robust way to authenticate agents (and authorize what they can do), we end up inserting humans back into the loop for every login, approval, or sensitive action. 

The Roadblock

Memory and orchestration aren’t the main roadblocks. Open-source vector databases and context window hacks have extended agents’ memory. Teams are using tools like OpenAI Evals and custom benchmarks to improve quality control on agent decisions. 

And dozens of frameworks (LangChain, Guidance, Haystack, etc.) tackle the orchestration of multi-step reasoning. These advancements have made it easier to build an agent that looks impressive in a demo – remember AutoGPT chaining web searches, or a customer support bot handling an entire ticket.

However, when it comes time to deploy agents in the wild, these capabilities aren’t what break down. 

The roadblock is trust. 

An agent might be perfectly capable of drafting an email or updating a database entry, but can it log in to the email account or database securely? In practice, whenever an agent hits a task that requires verifying identity – say, accessing a user’s Gmail or an internal CRM – suddenly a human has to step in to provide credentials or approval. 

The agent pauses, awaiting some OAuth token or API key that only a human can grant. In effect, human-in-the-loop authentication has become the choke point for agent automation. 

All the fancy memory in the world don’t matter if your AI butler is stuck at the front door, unable to prove it’s authorized to enter.

API keys and OAuth were not built for this

Today’s authentication primitives – API keys, OAuth2 flows, service accounts – were designed for relatively static contexts: a human user logging in, or a known server-to-server integration exchanging credentials. 

They break down in the face of ephemeral, autonomous, multi-agent systems. 

Why? A few reasons:

• Ephemeral Agents, Permanent Credentials: AI agents are often spun up on demand, run briefly, then disappear. Managing long-lived API keys for each agent is impractical and unsafe. Hardcoding keys is obviously a non-starter (any compromise and the key leaks). Even storing keys in a vault and fetching them introduces risk if done at scale. Traditional API key security assumes a small number of known clients – not hundreds of micro-agents popping in and out of existence.
  
• OAuth’s Interactive Friction: OAuth2, the standard for user-granted access, assumes a user can be redirected to click “Approve” in a browser. That works when I connect my Slack account to a single app. But imagine an autonomous agent that needs to access Slack on behalf of many users, or many different services on the fly. Requiring a human approval step for each scope won’t scale. Agents need a way to get tokens without halting to ask “Mother, may I?” every minute.
  
• Compound Identity Ambiguity: In an agent world, a request hitting an API might be on behalf of a user and initiated by an AI agent. Systems today often can’t distinguish: Is this Alice, or Alice’s AI assistant, making this request? As one security analysis noted, “If your system can’t tell a human user from an AI agent acting on their behalf, it may apply the wrong policies.” An agent might legitimately log in for Alice, but so might a malicious bot pretending to be her agent. Lacking a concept of agent identity, systems either over-provision (giving the agent all of Alice’s privileges) or block it entirely. Neither is tenable.
  
• Over-Privileged Access & No Granular Control: Because current auth methods are all-or-nothing, agents often get full access if they get access at all. If an agent uses your login cookie or API key, it can do anything you could do. That’s a nightmare waiting to happen. As the team at Stytch observed, an agent operating under your account could “delete data, make purchases, or reconfigure settings” far faster than any human. Without a way to grant limited, specific permissions, one bug or hijacked agent can wreak havoc.
  
• Lack of Accountability: Today, if an agent abuses an API or performs an unintended action, it’s hard to trace responsibility. Was it Alice’s request or the agent misbehaving? We lack the basic audit trail because the agent has no distinct identity. Security teams have emphasized the need for logs and traceability tied to each agent’s identity. API calls need to say “this was Agent X acting for Alice” – and right now, they often can’t.
  

In short, current auth infrastructure was built for a world of human users and static servers, not dynamic AI actors. 

Just as cloud computing needed new IAM (Identity and Access Management) models for virtual machines and microservices, agentic AI needs a new approach to identity.

The new primitives: what’s needed for agent trust

Solving this will require inventing and standardizing entirely new primitives in our digital identity toolkit. In particular, a few key concepts are emerging as must-haves for a robust agent authentication layer:

• Agent Identity: We need a way to issue unique, verifiable identities to AI agents – akin to service accounts or digital certificates, but tailored to non-human actors. This identity should answer “who is this agent and who (or what) does it represent?” 
• Delegation and Scope Protocols: It’s not enough for an agent to have an ID; it must carry proof of what it’s allowed to do. We need delegation protocols so that a user or organization can hand an agent limited authority – e.g., “Alice’s scheduling agent can read her Google Calendar and send emails, but not transfer funds.” OAuth scopes are a primitive version of this, but we likely need more dynamic, fine-grained delegation (potentially with hierarchical or chaining delegation as agents call other agents). 
• Fraud and Liability Standards: With agents acting autonomously, fraud detection and liability assignment become tricky. If an AI agent commits a fraudulent transaction, who is liable – the user, the agent’s developer, or the platform? The industry will need standard ways to flag suspicious agent behavior and assign accountability. This spans technical standards (for anomaly detection, rate limiting, kill switches for rogue agents) and legal standards (clarifying responsibility when an agent misbehaves). Early efforts like the EU AI Act are already pushing in this direction by requiring traceability and oversight for autonomous systems.
• Access Brokers and Credential Escrows: We may see the rise of “access broker” services that securely mediate between agents and traditional apps/APIs. These brokers would hold user credentials (or API keys) in escrow and issue short-lived tokens to agents on demand, after verifying the agent’s identity and scope. In effect, an agent identity provider or trust broker that vouches, “Agent X is acting for Alice and is allowed to do Y,” and then translates that into a real API call to Google, Salesforce, etc. This is analogous to how human SSO (Single Sign-On) providers like Okta broker trust between users and applications – but now it’s non-humans logging in. Without such brokers, every AI developer is hand-rolling integrations to hundreds of APIs, re-solving the auth problem poorly each time.
  

These primitives are in their infancy, but they form the blueprint of an “agent authentication stack”. 

Whoever builds and popularizes this stack will define how AI agents safely interact with the digital world.

Early movers: startups building the agent auth layer

There are a few forward-thinking startups zeroing in on agent authentication:

• Composio (AgentAuth): Composio’s AgentAuth product is an early attempt at an auth layer for AI agents. It lets developers build agents that securely connect to apps on users’ behalf, handling OAuth, API keys, JWT, and other auth methods behind the scenes. The idea is that your AI agent can have one unified way to say “I need access to this user’s Gmail or Slack,” and AgentAuth will take care of obtaining and managing the credentials securely. In practice, AgentAuth acts like an adapter between the agent and existing auth flows – the agent never sees the user’s raw password or token, it just gets delegated access. By supporting popular agent frameworks (LangChain, etc.), Composio is trying to become a plug-and-play solution for agent identity.
• Arcade: Arcade.dev (founded by veterans from the identity world) is another startup squarely focused on this pain point. Arcade provides pre-built connectors and an SDK so that an agent can log in to Gmail, read and send emails, access a database, or update Salesforce – all through Arcade’s secure interface. By handling token exchange, storage, and refresh, it removes the “token headache” for developers. This is essentially “OAuth for AI” as a service. 
• Others: Cloudflare announced integrations to let AI agents use its Workers platform with identity providers like Auth0 and Stytch for authentication. Startups like Logto and WorkOS have blogged about adapting SSO and identity management for AI agents. And of course, existing identity management giants (Okta, Microsoft, Google) are likely eyeing this space – their whole business is managing identities and access, so they won’t sit idle as “non-human” identities proliferate. The race is on to become the “Okta for AI agents.”
  

Beyond context: Why MCP alone isn’t enough

What about the big tech players? Notably, Anthropic introduced the Model Context Protocol (MCP) in late 2024 as an open standard for connecting AI assistants to external tools and data. MCP is a significant step toward a unified “plug-in” ecosystem for AI, often described as a “USB-C for AI applications”. It standardizes how an AI agent can call a tool or query a data source, enabling seamless integration across systems. Providers like OpenAI have even begun adopting MCP to let their AI agents interact with third-party services .

However, it’s crucial to distinguish connectivity from identity. 

MCP focuses on how agents exchange information with external systems (the context and calling interface). It does include security considerations, but it largely assumes the authentication problem is solved elsewhere. 

Think of MCP as defining the ports and protocols – you still need to decide who is allowed to plug in and what they can do. Even Anthropic acknowledges that secure connections require additional auth layers on top of MCP. 

In fact, we’re already seeing projects that pair MCP with identity providers (e.g. Cloudflare enabling OAuth flows for MCP servers). 

MCP is a great enabling technology – it will make it easier for agents to retrieve context and perform actions in a standardized way – but it doesn’t solve the trust and authentication issue by itself. That missing piece is exactly what Arcade, Composio, and others are tackling.

In analogy, MCP might become the “HTTP for agent-tool communications,” but we still need the “SSL/TLS + verifiable identity” layer to ensure those communications are trusted. 

Without authentication, a standard protocol alone could actually increase risk (e.g., making it easier for a rogue agent to plug into many services unless we verify identities).

We’re going to need regulatory clarity 

We’re on the cusp of new rules that will mandate authentication and accountability for AI systems. 

The EU’s upcoming AI Act is a prime example. While it doesn’t explicitly use the term “AI agent,” it does require that autonomous AI systems be traceable, registered, and monitored. In essence, European regulators are saying: if an AI is operating without direct human oversight, you must be able to identify it, track what it’s doing, and hold someone accountable. We can imagine future compliance checklists: did you register your high-risk AI agents with authorities? Are you logging their actions with an ID stamp? Can you shut them off if they misbehave?

In the USA – the FTC has warned about AI systems enabling new forms of fraud and consumer harm. The Treasury Department’s FinCEN recently alerted banks about criminals using generative AI to create deepfake identities and fake documents to bypass verification checks. I’ve met with policy makers in US senators offices who are actively trying to design for liability. 

We may see requirements for “AI agent KYC” (know-your-customer for bots), audit trails for agent decisions, and even licensing or certification of certain autonomous agents. 

I’m hearing from industry players that they are craving this regulatory clarify – if they are able to understand how agents will be regulated, they would take more risk and build more creative tools. 

They’re holding themselves back right now. 

The End

Every major technology shift has eventually required a trusted identity layer. 

The internet needed HTTPS and certificate authorities to become viable for commerce. 

Smartphones needed app store review and signing to trust third-party apps.

Enterprise IT needed single sign-on and identity management to scale software access. 

Many thought blockchain and crypto zero knowledge proofs would solve this. 

Each time, the solution (and the companies that delivered it) unlocked enormous value.

AI agents are the next platform in dire need of a trust layer.

Network effects and moats will abound: a trust layer gets stronger as more services integrate with it and more agents rely on it, creating a virtuous cycle that is hard for latecomers to break (classic platform defensibility).

In conclusion, it’s becoming clear that authentication is the missing foundational layer for AI agents – not memory, not better reasoning, not fancy orchestration. Until we can trust an agent’s identity and intentions, we’ll hesitate to let it truly run free.