Arcade's $60M Bet on Agent Authorization: Why Production AI Agents Need a Permission Layer

On June 15, 2026, Arcade raised $60M in a Series A led by SYN Ventures — with Morgan Stanley and Wipro writing checks alongside. The total is now $72M. The company builds authorization infrastructure for production AI agents, and the round is the clearest signal yet that the industry has moved past a question nobody wanted to say out loud: why do enterprise AI agent pilots almost never make it to production?

The answer, it turns out, isn't the model. The model is fine. The problem is permissions.

Why agents stall before production

Every enterprise AI pilot hits the same wall. The demo works flawlessly in the sandboxed environment. The model reasons well, executes multi-step tasks, calls the right tools. Then someone asks the obvious question before going live: if this agent acts on behalf of a user, how do we know what it's allowed to do?

That question does not have a good answer in most agent frameworks. The agent can read a system prompt that says "only do X," but there's no enforcement layer between the model's decision and the API call that hits the production database. No audit trail. No per-user permission scope. No way to prove, after the fact, that it was the agent — not a human — who made a given change.

Security and compliance teams see exactly this, and they block the rollout. Not because the technology doesn't work, but because the governance story doesn't exist.

What Arcade actually builds

Arcade calls itself "the secure action layer" for AI agents. The product sits between an agent's reasoning step and the tools it calls, checking every proposed action against a live policy engine before execution is permitted. If the agent requests an action the current user isn't authorized for, the call is blocked and logged. If it's authorized, it proceeds — and that authorization fact is written to an immutable audit trail.

The team behind this is deliberately not an AI lab. CEO Alex Salazar came from Okta, where he spent years building identity infrastructure for enterprises. CTO Sam Partee built distributed systems at Redis. That background shapes the product: Arcade treats authorization as an infrastructure problem with infrastructure-grade requirements — latency, reliability, auditability — not an AI problem you can patch with a better prompt.

The platform runs inside customer environments (not a SaaS cloud hop), ships thousands of prebuilt tool integrations, and is designed to be model-agnostic. You bring your own Claude Code, Cursor, or Codex setup; Arcade wraps the tool layer underneath.

Authorization vs. authentication

Most developers conflate authentication (who are you?) with authorization (what are you allowed to do?). OAuth handles the first. Arcade handles the second. They are different problems, and conflating them is exactly why so many agent pilots die at the security review.

An agent that authenticates as a user — using that user's OAuth token — inherits the user's full permissions. That's a security liability. A junior analyst whose token the agent holds can accidentally grant the agent write access to the production database, because that's what the token allows. The governance team rightly refuses to ship something they can't scope.

Arcade's policy engine separates agent identity from user identity. An agent gets its own credential with an explicitly declared scope. When it tries to do something outside that scope on behalf of a user, it's blocked even if the user's own token would allow it. This is the principle-of-least-privilege applied to autonomous systems — an idea older than AI agents, but never previously applied to them at this layer of the stack.

MCP integration and the vendor-neutral bet

Arcade's timing is deliberate. The Model Context Protocol, which Anthropic open-sourced in late 2024 and which became the de-facto standard for agent-tool communication through 2025, created a consistent surface for exactly this kind of middleware. Arcade integrates at the MCP layer, which means it works with any host that speaks MCP — Claude Code, Cursor, Windsurf, Kiro, and any custom agent that implements the protocol.

{
  "method": "tools/call",
  "params": {
    "name": "db_write",
    "arguments": { "table": "users", "id": "u_123", "patch": {...} },
    "_arcade_context": {
      "agent_id": "analytics-agent-v2",
      "user_id": "[email protected]",
      "session_id": "sess_abc"
    }
  }
}

The _arcade_context block is the authorization envelope. Before the tool executes, Arcade's runtime checks the policy for analytics-agent-v2 acting as [email protected] on db_write. The check is synchronous and in-process — no external round-trip that adds latency to every tool call.

The vendor-neutral bet is significant. Morgan Stanley and Wipro aren't betting on a single AI vendor winning enterprise. They're betting on the infrastructure that makes any agent deployable in enterprise. That's a different — and arguably more defensible — position than building another model wrapper.

What this means for your agent stack

If you're building production agents today, Arcade signals three things about where the market is going.

Authorization is a first-class problem. If your agent pipeline doesn't have an explicit authorization model, you don't have a production agent — you have a demo. The security review will find this, and it will kill the rollout. Build the permission layer now, even if it's manual.

Audit trails are not optional. Compliance teams need to answer "what did the agent do, and was it authorized?" for every action. If you can't produce that log, the agent can't touch production data. Structured logging at the tool-call level — not just the LLM output level — is the minimum.

MCP is the integration surface that matters. Arcade's MCP integration isn't a coincidence. The protocol provides the consistent abstraction that makes middleware viable. If you're not building your tool integrations on MCP yet, you're making the authorization problem harder.

Authorization patterns you can use today

Arcade isn't generally available to all teams yet, but the pattern it implements is something you can approximate now. Here's the minimal version.

---
name: authorized-db-agent
description: Database agent with explicit authorization scope.
tools:
  - Read
  - Bash
skills:
  - db-read-only
---

AUTHORIZATION SCOPE:
- Read: users table (own record only, filtered by session user_id)
- Read: analytics table (read-only, no PII columns)
- Write: BLOCKED — this agent has no write authorization

Before every tool call, verify the action is within scope.
If a request requires write access, halt and surface the limitation.
Log every tool call to stdout in structured format:
{"ts": "...", "agent": "authorized-db-agent", "action": "...", "authorized": true|false}

This is declarative, not enforced — the model can still violate it. The real fix is a tool wrapper that checks scope before execution. In Python with the Anthropic SDK:

AGENT_POLICY = {
    "analytics-agent": {
        "db_read": ["users.own", "analytics.*"],
        "db_write": [],          # no write access
        "file_read": ["reports/"],
    }
}

def authorized_tool_call(agent_id, tool_name, args, user_id):
    allowed = AGENT_POLICY.get(agent_id, {}).get(tool_name, [])
    if not allowed:
        audit_log(agent_id, tool_name, args, user_id, authorized=False)
        raise PermissionError(f"{agent_id} is not authorized for {tool_name}")
    audit_log(agent_id, tool_name, args, user_id, authorized=True)
    return call_tool(tool_name, args)

def audit_log(agent_id, tool_name, args, user_id, authorized):
    import json, datetime
    print(json.dumps({
        "ts": datetime.datetime.utcnow().isoformat(),
        "agent": agent_id,
        "user": user_id,
        "tool": tool_name,
        "authorized": authorized,
    }))

This doesn't replace Arcade's policy engine for enterprises that need real enforcement, but it demonstrates the pattern: authorization logic lives outside the model, runs before the tool executes, and every decision — authorized or not — is logged.

The broader shift: demos to production

Arcade's Series A is one data point in a larger pattern. In 2025, the news cycle was dominated by model releases and benchmark scores. The question was always "what can this model do?" In 2026, the question shifted to "how do you run this model safely in production?" — and the infrastructure category answering that question is now raising serious capital.

The shift mirrors what happened with cloud infrastructure in 2012. AWS launched in 2006. Enterprise adoption stalled on security and compliance. The breakthrough came when the tooling layer — identity, audit, compliance automation — caught up with the raw infrastructure. Agent authorization is today's version of that missing layer.

For developers building agent pipelines today: the authorization problem is not an enterprise-only problem. Any agent that touches real data on behalf of real users needs a permission model. Start with the pattern above. Add structured audit logging. Build your tool integrations on MCP so a proper authorization layer can wrap them later.

The companies that ship production agents in 2026 will be the ones that treated authorization as infrastructure from day one — not something to bolt on after the pilot.

# Install the agent-authorization skill to build compliant agent pipelines
npx @skills-hub-ai/cli install agent-authorization

See the full security skills category for authorization patterns, audit logging, and compliance skills for production agent deployments. Related reading: Claude Code Subagents for multi-agent architecture, and MCP 2026 stateless protocol upgrade for the protocol layer Arcade builds on.