Arcade's $60M Round Makes Agent Permissions Infrastructure

The most important agent security story this week is not another exploit. It is a funding round that says the quiet operational problem has become a market category.

On June 15, Arcade.dev announced $60 million in Series A funding to build what it calls the secure action layer for production AI agents. The story was quickly picked up by the Wall Street Journal, SiliconANGLE, PYMNTS, and agent ecosystem roundups such as The Daily Agentic.

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.

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 Coalition for Secure AI noted after RSAC that MCP security questions repeatedly converged on identity and authorization: who is making the request, on whose behalf, and across how many hops?

Arcade’s round is the story to watch because it turns those questions from architecture notes into funded infrastructure. Agent permissions are no longer an implementation detail inside a demo. They are becoming a control plane.

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.

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. 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.

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.

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.

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?

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.

Practical Defenses

Start by separating 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.

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.

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.

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.

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?