Governance is not new to your enterprise. Long before anyone connected an AI agent to any model or business system, you had already decided who can approve a purchase order, who can see a salary, who can push to production, and who signs off once the amount crosses a threshold. That logic lives in Workday, in SAP, in Salesforce, and in your identity provider, built up over years of audits and access reviews.
So when AI agents arrived, the first instinct for many was to point them at the same systems, let them inherit the same rules, and move on. Governance is a solved problem, agents only extended that solution.
Unfortunately, AI agent governance doesn’t extend cleanly. The primitives are right, but the entity being governed has changed shape. A person acts for themselves. An agent acts for someone else.
Every governance system you own assumes the actor and the accountable party are the same. Agents break that assumption, and bolting them onto human governance leaves a gap that you’ll eventually have to answer for.
Human governance primitives are necessary, but not sufficient
Let’s start with what carries over.
Strip any governance decision down and you find the same four variables, whether the actor is a person or a piece of software.
- Who is acting?
- What are they permitted to do?
- Which resource are they touching?
- When are they touching that resource?
A policy is logic written over those variables, and nothing about an agent changes that.
That is why the question at the center of AI agent governance sounds like something your access model has always asked: can this actor take this action, on this resource, right now? Role-based access control asks it. Your approval chains ask it. Your segregation-of-duties rules ask it.
So yes, the vocabulary transfers. Identity, permission, policy, audit, all of it still holds. If the primitives were the whole story, extending governance to agents would be a configuration exercise.
They’re not the whole story. The logic that sits on top of them is where people and agents diverge.
An AI agent acts on someone’s behalf
When you govern a person, the actor and the accountable party are one and the same. The analyst who runs the report is the analyst who answers for it. Permission and responsibility sit on the same shoulders, which is why “is this user allowed?” is enough of a question. The person carries the consequence of their own yes.
An agent splits that in two. The agent takes the action. A human carries the consequence, either the operator who deployed it or the user it is acting for. Permission and responsibility come apart, and no amount of access-control configuration puts them back together, because that model was written for a world where they never came apart in the first place.
That split is the whole reason governing agents is a different discipline, not a larger version of the same one.
The praise goes to the agent, the blame rolls uphill
Watch how credit and blame move, and the deterrent to adoption comes into focus.
On the happy path, the agent looks great. It closed the tickets, reconciled the accounts, and onboarded the customer in a fraction of the usual time, and everyone celebrates the productivity. The agent gets the praise.
On the flip side, the agent answers for nothing. When it wires the wrong amount or exposes a record it should have left alone, the agent does not get a warning or lose its job. The consequence rolls uphill to a person; the operator who put it into production, and the executive who signed off.
AI Agent Impact: the operator owns what the agent does
In 2024, Air Canada argued before a tribunal that its own support chatbot was a separate entity, responsible for its own statements. The tribunal rejected that outright and held the airline accountable for a refund policy its bot had invented, ordering it to pay. The bot was not hacked. It made something up, and the company was bound by the result. (Forbes)
That asymmetry is a powerful deterrent to real adoption. Ask a leader to put their name behind an agent that will take thousands of actions a week across systems they are accountable for, knowing the credit is diffuse and the blame is personal, and prudent hesitation is the rational response.
It shows up in the security numbers. Teams have moved agents past planning into testing and live use almost everywhere, while only 14% report full security sign-off. That gap isn’t the result of slow moving security teams. It is the accountability gap, showing up as a stalled approval.
So AI agent governance has to do a job that human governance never had to. It has to close the distance between the actor and the accountable party, at the moment of action, so a person can put their name behind an agent without inheriting unbounded risk.
What classical governance leaves on the table
Classical role-based access answers one question well: is this identity allowed to do this thing? For a human that is enough, because the human is also the one on the hook.
Give the same model to an agent and you are forced into one of two poor choices. Hand the agent a standing credential of its own, a service account, and you have created a set of permissions that anyone who can reach the agent can borrow, including people who should never have held them. More precise agent-identity models are emerging, but a standing credential and full inheritance are what most teams still reach for first. Let the agent inherit a user’s full access instead, and a single bad instruction now moves with everything that person can reach.
Neither choice reflects what is actually happening, which is one specific user asking one specific agent to do one specific thing. The logic agents need is the intersection of the two: authority scoped to what this user may do and what this agent was asked to do, narrowed to the task, and expired when the task ends.
What changes when the actor is an agent.
| Governing a person | Governing an AI agent | |
|---|---|---|
| Actor and accountability | The same party. The person acts and answers for it. | Split. The agent acts, a human answers for it. |
| The question that suffices | Is this identity allowed? | Can this agent, for this user, take this action, right now? |
| Permission lifespan | Relatively stable, reviewed on a cycle | Per task, scoped to the action, expired when it ends |
| Where the decision lives | Access reviews and approvals, often after the fact | At the tool call, before the action lands |
| A single mistake | Contained to one person’s authority | Moves with whatever access the agent was given |
Time carries more weight here too. A person’s permissions are relatively stable and reviewed on a quarterly cycle. An agent’s legitimate scope is per-task and momentary, which is why “right now” is doing real work in that question, and why a control that runs after the fact cannot answer it. The decision has to happen where the action happens, at the tool call, in the runtime. A nightly access review and an immutable log can tell you what an agent did. They cannot decide, in the instant, whether it may take that action.
The primitives you already trust were built to sit in the wrong place for this. That is what classical governance leaves on the table.
Your systems of record don’t speak agent
The governance you’ve built isn’t wasted. It just needs a bridge to the agentic world.
Consider Workday. The governance sitting inside it is yours, and there are years of rules in it. Which roles can see compensation. Who signs off on a termination. Which fields on a worker record are restricted, and to whom. Nobody ships that configuration out of the box, and none of it was designed for an agent. Workday can tell you whether a recruiter may view an offer. It has no native way to enforce that same rule against an agent acting for that recruiter, at the moment the agent reaches for the tool, scoped to that one call.
The stakes are concrete, because a system of record holds data that is both critical and regulated: social security numbers, bank accounts, compensation, dependents, garnishments. A single worker lookup can pull all of it into a model’s context, and an agent that takes a destructive action, whether from a bad reasoning step or an instruction injected in a resume, can expose or corrupt whatever it was able to reach. The recruiter’s agent should never be handed the payroll tool. The social security number on a candidate record should never reach the model at all. Those are governance decisions your business already made for people. They simply have no way to enforce themselves against an agent.
Every system of record can ship an MCP server to expose itself to agents, and they will. But exposure is not enforcement. Every enterprise also runs its own custom build on top of Workday, SAP, and Salesforce, with its own roles and its own exceptions, so someone still has to translate those specific policies into controls that hold at the tool call.
The real question is whether you build that bridge yourself, per system and per agent, or hand it to someone who has already done it.
This is the layer Arcade.dev was built to serve as. As the actions runtime, Arcade sits between your agents and the systems they act on, reads the identity, entitlements, and policy you already maintain, and enforces them on every agent, every user, and every tool call. The agent acts as the delegate of a named person and never as its own principal, so that person’s existing permissions already bind it. Your entitlement system stays the source of truth. Arcade is where that truth gets enforced, so the governance you spent years building finally applies to the actors you are deploying now.
As one financial services customer put it, the entitlement system is the policy store, and Arcade is the policy enforcement.
The actor changed. Your governance has to know it.
The primitives did not move. Who, what, which resource, and when are still the whole vocabulary of governance, for people and for agents alike.
What moved is the actor. For the first time, the entity taking the action and the person answering for it are not the same, although every control you’d built previously assumed they were. Close that gap at the moment of action and the deterrent that keeps agents away from production workflows disappears because the relationship between a person and their agent becomes collaborative instead of adversarial.
That is the focus of this series. The next post will take this thinking one layer down, to the control most teams reach for first and why guardrails, the instinct everyone starts with, sit in the wrong place to hold the line.
