AgentID vs Arcade: Who the agent is vs what the agent can reach
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.
- 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.
Arcade and AgentID sit at different layers of the agent stack. Arcade is an MCP runtime that lets an agent act as a known user against tools like Slack and Salesforce, with delegated credentials that stay inside the runtime. AgentID is an OpenID Connect provider that gives the agent an identity of its own, so an application that has never seen it can verify what it is and, for registered clients, which human owns it.
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". Source: https://www.arcade.dev/pricing, read 2026-09-09.
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 (an application created in the AgentID console or with the CLI) can request owner_email, which arrives in the id_token and from the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim. Free for apps in both tiers.
Different questions
The two products answer different questions, which is easiest to see side by side.
| AgentID | Arcade | |
|---|---|---|
| The problem | Disclosure: an agent arriving at an application that has never seen it, needing to prove what it is and who stands behind it | Delegation: a known user, inside an organization, granting an agent authority to use their tools |
| What matters | The agent's own identity, and the human accountable for it | Whose permissions the agent wields; the agent's own identity is incidental |
| Prior relationship | None at all, which is precisely why the identity must be portable and verifiable by anyone | The app being called already trusts the user's IDP |
| Typical job | An agent signs up for a new SaaS product and the product wants to know one human is behind these five agents | An agent posts to your company Slack |
Side-by-side
| AgentID | Arcade | |
|---|---|---|
| For | Apps accepting agent sign-ins; agent developers needing portable identity | Teams whose agents call SaaS tools on behalf of known users |
| Cross-app support | Yes, one identity valid at any OIDC-capable app | Broad tool catalog, but access is per-user delegation, not portable agent identity |
| Owner email support | Yes, owner_email scope for registered clients | User attribution per action via the existing IDP; no owner claim presented to outside apps |
| Standards support | Standard OIDC: code flow + PKCE (S256), ES256, RFC 7591 | OAuth-based delegation, MCP runtime, existing IDP integration |
| Pricing | Free for apps | Free to start, usage-priced |
| Time to integrate | Minutes on an existing OIDC stack; two config values | Runtime deployment plus per-tool authorization setup |
| Who owns the identity root | AgentMail inbox controlled by the agent's owner | The 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 create an AgentID application for owner scopes. Guides for Clerk, Supabase, Auth0, and Better Auth at www.agentid.com/docs.
