Arcade.dev recently secured a $60 million Series A funding to enhance authorization for AI agents, addressing crucial enterprise concerns about agent actions and permissions. Many agents currently operate with broad, persistent credentials, lacking necessary audit trails and specific permissions, which poses significant governance risks.
The post emphasizes that authorization should be treated as a user experience and product design issue, not merely an engineering task. Founders are encouraged to clearly define and display an agent’s permissions within the product interface, ensuring transparency and fostering user trust.
Most founders treat agent authorization as something the infrastructure team handles. Last week, the market charged $60 million to disagree.
On June 15, Arcade.dev closed a $60M Series A led by SYN Ventures, with Morgan Stanley and Wipro writing checks alongside. The company builds what it calls a secure action layer for production AI agents — in plain terms, it solves the question your enterprise buyer asks before any deal progresses: how do I know this agent is actually allowed to do what it just did, on behalf of whom, and with what scope? Arcade authored the MCP authorization specification that Anthropic adopted, and tool call volume on its platform has grown 25x in six months. That is not a niche infrastructure story. That is a signal.
The Problem Most Founders Miss
Here is what is actually happening in production: agents inherit broad, persistent credentials and execute actions without task-scoped, time-limited permission logic attached. The agent can read everything, write to most things, and act on behalf of a user who granted access once, six months ago, in a consent screen nobody remembers approving. When something goes wrong — and in agentic systems, something will go wrong — there is no clean audit trail, no clear ownership, and no obvious rollback. For a consumer app, that is embarrassing. For an enterprise deal, it is fatal.
Gartner’s projection that 40% of organizations will limit or retire AI agents due to governance failures is not a headline about regulation. It is a headline about product design. Agents that cannot prove their identity, scope, and action history are not enterprise-ready products — they are impressive demos with a liability problem.
Why This Is a UX and Product Decision, Not Just Engineering
Authorization has a user-facing dimension that most teams completely ignore. When an agent requests access to a system, modifies a record, or triggers a workflow, the experience of that action — for the user approving it, the admin reviewing it, and the person whose data was touched — is designed or it is chaos. The founding insight behind Arcade’s model is clean: agents should acquire access strictly for the actions they are executing, not accumulate standing privileges. Zero standing privilege is not just a security posture. It is a UX posture. It tells your user, “this agent only has what it needs, right now, for this task.” That is the sentence that converts skeptical enterprise buyers and rebuilds trust after your agent does something unexpected.
CrowdStrike moved in the same direction on the same day Arcade announced its raise, unveiling Continuous Identity for AI Agents at Identiverse 2026 — cryptographically verifiable agent identities, context-aware authorization, and zero standing privilege, all in production. Two enterprise security heavyweights converging on the same architecture in the same week is not a coincidence. It is the market telling you what the floor looks like now.
What Founders Need to Do This Week
The architecture is becoming standardized. The MCP authorization spec exists, Anthropic adopted it, the tooling is funded and maturing. What is not standardized is how founders expose that authorization model inside their own product UI.
Here is the one concrete move: define your agent’s identity contract and make it visible in the product.
That means writing down, for every agent your product ships, three things:
- What it is authorized to do — specific actions, named data sources, defined scope, not a vague capability description
- What it explicitly cannot do — billing changes, deletions, external sends — without explicit human approval
- What the user can see after the fact — a plain-language action log, not a raw API event stream
Then build those three things into the interface. Not in an admin console buried behind three levels of settings. In the primary product flow, visible to anyone the agent acts on behalf of. If a user cannot answer “what did my agent do and why” in under ten seconds, your authorization model is invisible — which means, from a trust standpoint, it does not exist.
Poplab’s AI agent governance work goes deeper on the specific UX patterns: audit views, human-readable permissions, and kill switches that belong in the product, not the backend dashboard.
The founders who treat authorization as a product design challenge will close enterprise deals faster and lose fewer users to “I’m not sure what this thing just did.” The founders treating it as a sprint ticket will keep watching their agents die in security reviews.
Identity is not a checkbox. It is the handshake between your agent and every person who ever trusts it.
Leave a Reply