+
+
+
+
+
+
+
+
Blog/Comparisons

AgentID vs Arcade: Who the agent is vs what the agent can reach

BPBinoy Perera

Arcade is an MCP runtime that lets agents act as real users against tools like Slack and Salesforce, with credentials that never leave the runtime. AgentID is a sign-in identity for agents themselves. Identity and tool access are different layers.

Comparisons
AgentID
TL;DR

Arcade is an MCP runtime that lets agents act as real users against tools like Slack and Salesforce, with credentials that never leave the runtime. AgentID is a sign-in identity for agents themselves. Identity and tool access are different layers.

What is Arcade?

Arcade describes itself as "the runtime between your agents and every system they need to reach". It is a middleware layer with three functions: authorization, tool execution, and governance. On authorization, "your agents act as real users with dynamic permissions. Your existing IDP plugs right in, credentials never leave the runtime". On tooling, Arcade ships pre-built MCP tools for systems including Google Workspace, Slack, Microsoft, and Salesforce. On governance, the pitch is auditability: "What did the agent do, on behalf of which user, in which system? You can answer that for every action".

The identity model is user impersonation through delegated OAuth rather than service accounts. End users authenticate through the company's existing identity provider; the agent then operates with each individual user's credentials and permissions, with tokens held inside Arcade's runtime rather than in agent code. Arcade is framework-agnostic (LangChain, LlamaIndex, CrewAI, and others), deploys to cloud, on-prem, air-gapped, or hybrid environments, and is priced "free to start, priced by usage, designed for enterprise volume".

It is a strong answer to a real problem: agents that need to do things in SaaS systems on behalf of known users, with security teams demanding audit trails.

What is AgentID?

AgentID is a "Sign in with AgentID" button apps put on their login pages, run by AgentMail as a standard OpenID Connect provider. The agent authenticates as itself: its signing credential never leaves it, each sign-in is a fresh one-time signature, and the app verifies against published keys without ever holding a reusable secret. The id_token carries a stable subject and the agent's inbox address, verified at token mint.

Registered clients (one RFC 7591 call with an AgentMail API key) can request owner_email, served from the userinfo endpoint after the code exchange, with a 403 on sign-in when the agent has not granted owner visibility. Free for apps in both tiers.

Different questions

Arcade's world is delegation: a known user, inside an organization, granting an agent authority to use their tools. The agent's own identity is incidental; what matters is whose permissions it wields. AgentID's world is disclosure: an agent arriving at an application that has never seen it, needing to prove what it is and who stands behind it. In Arcade's model the app being called already trusts the user's IDP. In AgentID's model there is no prior relationship at all, which is precisely why the identity must be portable and verifiable by anyone.

When your agent posts to your company Slack, that is Arcade's job. When it signs up for a new SaaS product and the product wants to know one human is behind these five agents, that is AgentID's job.

Side-by-side

AgentIDArcade
ForApps accepting agent sign-ins; agent developers needing portable identityTeams whose agents call SaaS tools on behalf of known users
Cross-app supportYes, one identity valid at any OIDC-capable appBroad tool catalog, but access is per-user delegation, not portable agent identity
Owner email supportYes, owner_email scope via userinfo for registered clientsUser attribution per action via the existing IDP; no owner claim presented to outside apps
Standards supportStandard OIDC: code flow + PKCE (S256), ES256, RFC 7591OAuth-based delegation, MCP runtime, existing IDP integration
PricingFree for appsFree to start, usage-priced
Time to integrateMinutes on an existing OIDC stack; two config valuesRuntime deployment plus per-tool authorization setup
Who owns the identity rootAgentMail inbox controlled by the agent's ownerThe organization's existing IDP; agents borrow user permissions

When to choose Arcade

Choose Arcade when your agents need to operate inside the tools your organization already uses, and the security requirement is that every action maps to a real user with real permissions. The pre-built MCP tool catalog saves integration work, the runtime keeps tokens out of agent code, and the per-action audit trail answers the question security reviews actually ask. If your deployment needs on-prem or air-gapped options, that flexibility is there too.

Arcade is not trying to give your agent an identity the outside world can verify, and its user-impersonation model means the systems being called see the user, not the agent.

When to choose AgentID

Choose AgentID when the agent needs to be seen as an agent. Apps on the receiving end of agent traffic need sign-ins that disclose agenthood, resolve to a stable identity, and (for registered clients) carry the owner's email for per-human limits, abuse control, and KYC pass-through. Agent developers get an identity that works at every app showing the button, plus a working email inbox attached to it, without lending the agent their personal credentials.

The composition is natural: an agent might reach its owner's tools through Arcade and sign in to new services with AgentID. One handles authority inside an existing trust relationship; the other establishes identity where no relationship exists yet.

Get started

Add AgentID as a custom OIDC provider (issuer https://auth.agentid.com plus your client_id), or register a client for owner scopes. Guides for Clerk, Supabase, Auth0, and Better Auth at auth.agentid.com/docs.

FAQ

Let your agent sign in. Give it an AgentID and its own email address.