Arcade's $60M Round Makes Agent Permissions Infrastructure

Arcade.dev raised a $60 million Series A on June 15, 2026, led by SYN Ventures with strategic investment from Morgan Stanley and Wipro. The money funds an authorization layer for AI agents: scoped permissions, policy enforcement at the moment of the tool call, and an audit trail of every action. Agent permissions just became an infrastructure line item.

The company’s own announcement, published June 12, puts the problem in one sentence, and it is a security sentence rather than a product one:

Agents fail because nobody can prove that this agent, on behalf of this user, can perform this action on this resource.

— Alex Salazar, co-founder and CEO, Arcade.dev

Updated September 2026: the round closed as announced and nothing below has been superseded. The MCP authorization specification still places the burden on the server — it requires an MCP server to reject any token not issued specifically for it — and that is still the line most agent deployments have not drawn.

The round brings Arcade’s total financing to $72 million after a $12 million seed, according to PYMNTS, and SiliconANGLE reports the platform brokers access to more than 8,000 MCP tools by integrating with a company’s existing identity provider. The reason this belongs in the security conversation is simple: Arcade is not pitching a better chatbot. It is pitching authorization, policy enforcement, tool execution, and audits for agents that use MCP, A2A, and business-system connectors.

Key Figures

Figure	What it measures	Source
$60M	Series A raised, announced June 15, 2026	Arcade.dev
$72M	Total financing including a $12M seed	PYMNTS
8,000+	Agent-optimized MCP tools in the catalog	SiliconANGLE
25x	Growth in tool-call volume over six months	Arcade.dev
3	Things enforced per action: enforce, execute, govern	Arcade.dev
OAuth 2.1	Role the MCP spec assigns a protected MCP server (resource server)	MCP authorization spec
RFC 8707	Resource Indicators clients MUST send to bind a token to one server	MCP authorization spec
RFC 9728	Protected Resource Metadata every MCP server MUST implement	MCP authorization spec
401 / 403	Codes an MCP server must return for invalid token vs insufficient scope	MCP authorization spec
85%	Exploitation rate in the Agentjacking research, where authorization was never the failure	Cloud Security Alliance

That is exactly where the public debate has been heading. Developers are asking how to authorize AI agent actions in production. MCP builders are still debating why OAuth for MCP is hard. The questions converge on identity and authorization: who is making the request, on whose behalf, and across how many hops?

The Agent Needs Less Than The User Has

The uncomfortable default for many agent integrations is still borrowed user power.

A user connects GitHub, Slack, Google Drive, Sentry, Jira, Linear, a database, or a cloud account. The agent receives a tool. The tool can often do whatever the integration token can do. The agent then reasons over instructions, tool descriptions, documents, issues, telemetry, and other data that may include attacker-controlled text.

That model works until it does not.

Figure: the difference is not who the user is, but how much of that user’s power survives into a single tool call.

If an agent only needs to read one repository issue, it should not inherit broad repository write access. If it needs to draft a Slack response, it should not automatically be allowed to send it to every channel. If it needs to inspect a Sentry event, it should not be able to run arbitrary remediation commands because the event body suggested them.

This is the same lesson from Agentjacking. A legitimate MCP-connected Sentry tool returned hostile event data, and coding agents treated that data as instructions across an 85% exploitation success rate. It is also the lesson from the MCP security draft: tool invocation is a security boundary, not just a developer convenience.

Authorization has to become more specific than “this user connected this app.”

The better question is: should this agent, in this context, using this input, be allowed to take this action with this scope right now?

Why MCP And A2A Raise The Stakes

MCP made tools easier to expose. A2A makes agent delegation easier to imagine. Marketplaces and connector platforms make capabilities easier to discover. Those are useful shifts, but each one stretches the permission problem.

An MCP server can expose a tool list that changes over time. A hosted connector can alter behavior server-side. An agent-to-agent flow can pass work to another actor with a different trust boundary. A marketplace listing can make a tool feel reputable before a team has reviewed its implementation. A local skill can steer the model toward one tool path over another.

When these pieces combine, the old SaaS permission model starts to look too coarse.

The MCP specification already anticipates part of this. It assigns a protected MCP server the role of an OAuth 2.1 resource server, requires it to implement Protected Resource Metadata (RFC 9728), and requires clients to send the RFC 8707 resource parameter so a token is bound to exactly one server. The normative language is blunt:

MCP servers MUST only accept tokens specifically intended for themselves and MUST reject tokens that do not include them in the audience claim.

— Model Context Protocol, Authorization (revision 2025-06-18)

Token passthrough — forwarding the client’s token unmodified to an upstream API — is explicitly forbidden for exactly the confused-deputy reason. The OWASP guide to secure MCP server development and CSA’s agentic MCP best practices say the same thing in operational terms.

Human identity still matters, but it is not enough. Security teams also need agent identity, tool identity, source identity, artifact identity, and invocation identity. They need to know which agent asked, which skill or plugin shaped the task, which MCP server executed, which downstream service was reached, which user was represented, which scopes were used, and which policy approved or blocked the action.

That is why the phrase “secure action layer” is interesting. It suggests a layer below model reasoning and above raw application APIs where policy can be enforced before the agent does something irreversible. Arcade’s framing is that the control cannot live inside the agent at all — the thing taking an action never gets to authorize itself or write its own audit log.

For high-risk actions, that layer should be able to say no.

This Is Still A Supply-Chain Problem

Agent authorization is often discussed as identity infrastructure. It is also supply-chain infrastructure.

An agent’s effective capability is assembled from many parts: model behavior, skills, plugins, MCP servers, connector manifests, OAuth grants, hosted tool implementations, local config, runtime tool output, and delegated agents. Change one part, and the permission story can change.

Figure: install-time provenance and run-time policy answer different questions. A deployment that runs only one of them has a gap the other was supposed to cover.

A clean OAuth flow does not prove a tool is safe. A reputable MCP server does not prove its tool descriptions are unchanged. A signed skill does not prove the runtime action is appropriate. A least-privilege token does not help if the agent was tricked into spending that privilege on the wrong instruction.

The artifact layer and the action layer have to meet.

Before install, teams should verify what the skill, plugin, connector, or MCP server claims to add. Does it request shell access, filesystem writes, credential reads, external network calls, browser automation, SaaS write permissions, or production deployment paths? Does it tell the agent to trust tool output blindly? Does it fetch remote instructions? A SkillSafe scan answers those questions before the artifact reaches an agent.

At runtime, teams should verify whether the requested action matches the reviewed capability. Has the tool list changed? Did the schema expand? Did the connector request broader scopes? Is the agent acting on untrusted data? Is the action crossing from read to write, from summarize to execute, or from local diagnosis to external side effect?

That is the supply-chain lens: provenance before use, policy during use, and drift detection after use. More on that pattern: /blog/tag/supply-chain/.

Practical Defenses

Separate user authorization from agent authorization. The user may have broad access, but the agent should receive narrow, task-specific permission with clear expiry and audit trails. Short-lived tokens are the spec’s own recommendation.

Treat tool execution as a privileged boundary. Shell commands, package-manager calls, filesystem writes, cloud APIs, ticket updates, message sends, repository changes, browser actions, and production database access should have explicit policies and logs.

Bind every token to one resource. Send the RFC 8707 resource parameter, validate the audience claim server-side, and never pass a client token through to an upstream API. This is the single control that closes the confused-deputy path.

Preserve provenance through the tool chain. Tool output should retain which fields came from trusted platform metadata, authenticated users, unauthenticated clients, public internet content, or generated guidance. Policy cannot reason about flattened blobs.

Pin and review tool surfaces. MCP tool names, descriptions, schemas, handlers, connector scopes, and skill instructions should be versioned or hashed when possible. Meaningful changes should require review instead of inheriting old approval.

Require stronger gates for cross-boundary actions. Moving from one agent to another, from MCP to A2A, from read-only inspection to write action, or from untrusted input to command execution should be visible and enforceable.

Log the chain, not just the API call. A useful audit record shows the agent, user, skill or plugin, MCP server, connector, input source, selected tool, parameters, policy decision, approval state, and downstream action.

Where SkillSafe Fits

SkillSafe focuses on the artifact layer: AI skills and plugin-like files that shape what agents do before they ever call a tool.

Arcade’s funding round is a useful signal because it shows the runtime authorization layer maturing around the same problem. The industry is starting to accept that agents need more than a prompt warning and a user token. They need scoped permissions, action policies, provenance, and auditability.

Those runtime controls are stronger when the artifacts are verified first.

A SkillSafe scan can flag skills that ask agents to run commands from tool output, fetch remote instructions, access secrets, modify files, or escalate from analysis to action without a clear boundary. Dual-side verification can prove the installed artifact matches the reviewed one. An Agent Bill of Materials can make the skill, plugin, MCP server, and connector inventory visible enough for policy engines to use. Our MCP security guide covers the server-side controls in detail.

The direction is clear: agent security is becoming a stack. Scanners verify what gets installed. Authorization layers govern what gets executed. Logs explain what happened. Drift detection watches for changes after approval.

Frequently Asked Questions

What is the difference between agent authentication and agent authorization?

Authentication proves which agent and which user are making a request. Authorization decides which specific action that pair may take on which resource, right now. The MCP specification handles the first with OAuth 2.1 and Protected Resource Metadata (RFC 9728); the second is per-action policy the protocol does not define, which is the gap a secure action layer sells into.

What are the best practices for MCP authentication?

Four, from the specification itself: treat the MCP server as an OAuth 2.1 resource server; implement RFC 9728 Protected Resource Metadata and return WWW-Authenticate on a 401; require clients to send the RFC 8707 resource parameter so tokens are audience-bound; and never forward a client’s token to an upstream API. OWASP’s secure MCP server guide covers the implementation details.

Why is OAuth for MCP hard?

Because the classic OAuth model assumes one user authorizing one app, while an agent chain has several actors: a human, an agent, possibly a delegated sub-agent, an MCP client, an MCP server, and a downstream API. Each hop can re-scope or re-delegate. The specification forbids token passthrough for that reason, but it cannot tell a server whether this particular action, on this input, is reasonable.

Should an AI agent inherit the user’s permissions?

No. Standing permissions equal to the user’s are the failure mode the whole category exists to fix: an agent authorized around the clock turns any successful prompt injection into full account access. Arcade’s stated model is that the agent gets the access its user has, only for the action it is taking, which is the shape to copy whether or not you buy a product.

Does an authorization layer stop prompt injection?

Not by itself. In the Agentjacking research every step was authorized, and an 85% exploitation rate was achieved without violating a single policy. Authorization limits blast radius, but stopping the injection also needs provenance on tool output, approval gates before shell and package-manager calls, and scanning of the skills that tell an agent to trust what it reads.

The teams that connect those layers will have a much easier time answering the question that matters most: what exactly did this agent have permission to do, and why?