Picture that same agent from before, the one that walked past three weeks of guardrails in its first week in production. The attack is identical, with the same crafted message aimed at the same agent. What’s different is that every action now routes through a runtime first. The agent reaches for its first reckless call, and the call meets a flat, immediate denial at the tool boundary. Nobody wrote a custom rule for that attack, and nobody asked the model to be careful. The action simply never reaches the system.
The difference is architectural. Now, a control plane sits at the tool call and asks one question every time the agent tries to act.
Every capability below needs to answer at least one of those interlocked questions at runtime, for each action, before it happens.
Let’s take them one at a time to better understand the mechanics.
Authorization at the intersection of user and agent
Let’s start with identity, because most agent breaches start there.
When a team connects an agent to the systems it will act on, the team tends to make one of two identity choices, and both have flaws.
If you choose to give the agent its own identity (a service account) you’ve created a set of standing permissions that any user can reach through the agent, including the intern who should never have touched the finance system.
Or…
If you let the agent inherit the full access of whoever is driving it, then one prompt injection now cascades through every system that person can reach.
The workable answer is the intersection.
Arcade.dev treats the agent as a delegate, not a service account, and authorizes each action against what this user is allowed to do and what this agent is scoped to do. The result is least privilege by default: the agent operates inside the narrow intersection of those two permission sets, never on a broad standing grant like “access Salesforce.” That intersection is the ceiling on what the agent can do, so a compromised or misdirected agent can’t exceed it. Revoke the user and the agent loses that access in the same moment.
Because the agent is bound to that narrow intersection, its authority can’t widen mid-task. A service account can be talked into doing far more than intended. A delegated agent can only ever do what this user and this agent are both permitted to do. And because every action ties back to a real person, when your auditor asks who did this, there’s one answer.
AI Agent Impact: a poisoned lead, and the agent did the rest
In September 2025, researchers at Noma Security disclosed ForcedLeak (CVSS 9.4), a flaw in Salesforce’s Agentforce, its product for building AI agents. An attacker planted hidden instructions in the description field of a Web-to-Lead form. When an employee later had the agent work that lead, the agent followed the buried instructions, queried the CRM for sensitive records, and sent the data to a domain the attacker had picked up for about $5. Salesforce has since patched it. (The Hacker News, Noma Security)
No credential was stolen. The agent already held broad, standing access to the CRM, and one injected instruction turned that access into an exfiltration path. Delegated authorization changes the blast radius. An agent scoped to a single user’s permissions can only reach what that user can reach, so the same injection can’t vacuum up records the user was never entitled to. It doesn’t make prompt injection impossible. It turns a CRM-wide leak into a bounded one, and a Contextual Access policy on the risky action can close the gap further.
Your policy enforced inline, as code
Authorization decides whether the actor may act. Policy decides whether this particular action is allowed to proceed.
Arcade runs policy at the tool call so a denied action never reaches the downstream system. The policies are the ones your security team already thinks in: data-loss controls, PII redaction, egress limits, per-agent rate limits, and blast-radius caps on high-impact operations.
All of it is defined centrally and enforced by configuration on every call, instead of living in a document that hopes the agent complies.
The shift from trust to enforcement is the turning point. You are no longer hoping the agent behaves. You are enforcing the policy at the runtime, by configuration, on every call, whether the agent is cooperative or compromised.
Extending the stack you already run
A common fear is that governing agents means standing up a second security stack in parallel with the one you already operate. With Arcade it doesn’t.
Arcade plugs into the systems you run today through runtime hooks. Your identity provider stays the source of truth for who a user is. Your data-loss and compliance tools apply their rules at the tool call. Your logging pipeline receives the events. Arcade stays independent of any single model, framework, or client, so adopting it does not lock your agent roadmap to one vendor’s choices.
Credentials never reach the model. They’re held in isolated storage the agent can’t read, so a compromised agent has nothing to exfiltrate.
Particularly for our customers handling regulated data and information, that deployment shape is often the difference between a sign-off and a hard no when companies attempt to move agents into production.
See every agent, make the governed path easy to follow
You can’t govern what you can’t see, and with agents the blind spot is both the sprawl and the access underneath it.
For every agent that runs through Arcade, the control plane shows what’s deployed, who built it, and what it’s doing in production. Arcade governs the agent traffic that flows through our runtime, but in honesty we can’t force a determined team onto the governed path. That means the goal isn’t to abolish shadow AI by decree. It’s to make the governed path the easiest one to take, and to give you a real inventory of everything on it.
Sprawl isn’t only the agents you can see. When IT becomes the queue for every integration, the teams that won’t wait wire up their own connectors and personal tokens, and an agent ends up reaching a production system on access no one can see, revoke, or audit. The only effective response is making the governed path the easiest one. When the fastest way to connect an agent is through the governed path, the shortcut stops being worth taking, and the access that used to run on a personal token now runs as delegated, per-action authority with a name attached.
A shared registry does the rest. Instead of the tenth team building the tenth slightly different Salesforce integration, teams discover, request, and publish approved tools, agents, and skills, reusing what already exists and governing it the same way. That kills the shadow registries that otherwise multiply in the dark, each with its own access.
An audit trail that proves what every agent did
The last part of the question is “right now,” and answering it over time means proving what happened.
Arcade records every invocation at the level of the individual call: the agent identity, the human it acted for, the scope it was granted, the inputs, the outputs, and the policy decisions applied along the way. Those records are queryable in real time and stream to your SIEM over OpenTelemetry, so they land in the tooling your security team already watches.
This is what changes the stakes of an attack. When every action is attributed and replayable, a prompt injection that gets blocked at the tool call becomes a logging event you can review, rather than a breach you have to disclose.
Answering our core questions
Step back and the pieces line up behind our core question: can this agent, on behalf of this user, take this action, on this resource, right now?
| The question, clause by clause | The capability that answers it |
|---|---|
| Can this agent… | The agent’s own identity and scope, defining what this agent is allowed to do |
| …on behalf of this user… | Authorization at the intersection, binding the action to this user’s permissions |
| …take this action… | Policy enforced at the tool call, deny-by-default on anything unapproved |
| …on this resource… | The agent’s access to resources can never exceed the user’s access |
| …right now? | Live enforcement at the runtime, plus an attributed, replayable audit trail |
That is the shape of governance built to enforce rather than advise, covering policies your security team approves, execution your developers can rely on, and central oversight across every agent and action.
Agentic ROI starts to show up once this production issue is solved, which is where this series goes next. Stay tuned.
More in this series
- AI Agent Governance Is Not Governing People: Why the Rules Change When Agents Act on Your Behalf
- Guardrails vs. Governance Explainer: What Actually Stops an Agent From Doing the Wrong Thing
- Approve Once, Scale Every Agent: The ROI That Governance for Agents Unlocks (coming soon)
