Agent Governance: Who Actually Approves What an Agent Is Allowed to Do

Table of Contents

• Why "Who Approves" Is the Hardest Governance Question
• The Three Layers of Agent Approval Authority
• Policy-Time vs. Run-Time Approval
• Mapping Approvals to Blast Radius
• Who Sits in the Approval Chain
• Designing the Approval Workflow
• Common Mistakes That Wreck Agent Governance
• Governance in the GaaS Vendor Relationship
• Insights Most People Overlook
• Frequently Asked Questions
• Conclusion
• References

Why "Who Approves" Is the Hardest Governance Question

Every other governance control assumes you've answered this one first. Scoped permissions, kill switches, audit logs, role-based access for fleets of agents, all of them are mechanisms for enforcing a decision that someone, somewhere, made about what the agent may do. If that decision is fuzzy, every downstream control inherits the fuzziness.

The reason it's hard is that agents collapse two things that used to be separate. In traditional software, a developer decides what the code can do (at build time), and a user decides what to actually do with it (at run time). The two are months apart and handled by different people. An autonomous agent compresses that gap to milliseconds. The agent reads a goal, plans a sequence of tool calls, and starts executing, deciding for itself which capabilities to invoke. So "who approves what the agent is allowed to do" is really two questions wearing one coat: who approved the capability the agent has, and who approves any given use of that capability in the moment.

Most failed agent deployments I've seen trace back to teams answering only the first question. They scope the agent's tools, pat themselves on the back, and ship. Then the agent uses a perfectly authorized capability in a way nobody anticipated, refunding a customer it shouldn't have, emailing a draft that was never meant to send, modifying a record that triggered a cascade. The capability was approved. The specific action was not. And no one had built a place for that second approval to happen.

The Three Layers of Agent Approval Authority

It helps to stop thinking of "approval" as one thing. In a well-governed GaaS deployment, approval authority lives in three distinct layers, each owned by different people.

The policy layer is the constitution. It defines, in advance, the universe of actions the agent may take and under what conditions. This is owned by governance, a risk officer, a security lead, often a cross-functional committee. Policy-layer decisions are slow, deliberate, and revisited on a schedule. "This agent may issue refunds up to $200 without human review; refunds from $200 to $2,000 require a manager's approval; refunds above $2,000 are forbidden entirely." That's policy.

The runtime layer is enforcement. When the agent actually tries to issue a $1,500 refund, something has to recognize that this crosses a threshold, pause the agent, route the request to a human, and resume only on approval. This is owned by the platform, the orchestration framework, the permission broker, the approval queue. Runtime decisions are fast and mechanical. The runtime doesn't decide the policy; it executes it.

The accountability layer is the human owner. Every agent should have a named person who is accountable for what it does, not the vendor, not the committee in the abstract, but an individual who would be the one explaining the incident. This is the principle behind the emerging "human accountable owner" requirement that mature governance programs are adopting. It's the answer to the question regulators and incident reviewers always ask: who owned this?

When all three layers are present and distinct, governance is legible. When they're collapsed, when the developer who built the agent also wrote the policy, enforces it, and is the only accountable party, you have no governance, just one person's judgment dressed up as a system.

Policy-Time vs. Run-Time Approval

The single most useful distinction in this whole topic is between approving a class of actions ahead of time and approving a specific action in the moment.

Policy-time approval is pre-authorization. A human (or committee) decides in advance that a category of action is acceptable, and the agent is then free to perform any instance of that category without further sign-off. Reading from a CRM, drafting an internal summary, querying inventory, these are typically pre-authorized because the downside of any single instance is small and the volume is high. You can't have a human approve every database read; the agent would be useless.

Run-time approval is just-in-time. The agent proposes a specific action, and a human reviews that exact action, with its exact parameters, before it executes. Sending money, deleting records, publishing content externally, signing contracts, anything irreversible or high-stakes. Here the human isn't approving a category; they're approving this transfer, to this account, for this amount.

The art of agent governance is drawing the line between these two correctly. Draw it too far toward pre-authorization and the agent operates with dangerous autonomy. Draw it too far toward run-time and you've rebuilt a manual process with extra steps, paying for an agent that can't actually act. Google's published Secure AI Framework and similar industry guidance both point in the same direction: tie the level of human oversight to the risk of the action, not to a blanket rule applied uniformly.

Mapping Approvals to Blast Radius

The cleanest way I've found to set that line is to score every action by its blast radius, how much damage a wrong call could do, and assign an approval mode accordingly. This is where governance stops being philosophical and becomes a table you can actually implement.

A practical four-tier model:

Tier 0, Read-only and reversible. Querying data, generating drafts, internal analysis. Pre-authorized, no runtime approval, logged but not gated. The blast radius is near zero because nothing changes in the world.

Tier 1, Reversible writes, low value. Updating a non-critical field, scheduling an internal meeting, tagging a ticket. Pre-authorized but logged prominently, with the ability to roll back. A human reviews these in aggregate after the fact, not one by one.

Tier 2, Consequential or hard to reverse. Refunds above a threshold, customer-facing emails, changes to production config, anything involving money below a ceiling. Run-time approval required from a human in the relevant function. The agent prepares the action and waits.

Tier 3, Irreversible, high value, or legally significant. Large financial transactions, contract execution, data deletion, anything regulated. Run-time approval plus a second reviewer, plus often a hard policy ceiling above which the agent simply may not operate at all.

The discipline this imposes is healthy: it forces teams to enumerate what the agent can actually do and honestly rate each capability. That enumeration alone catches more governance gaps than any tool, because it surfaces the actions nobody thought to think about. It also pairs naturally with least-privilege permission design, if an action sits in Tier 3, you question whether the agent needs that capability at all, which connects directly to the scoped-permissions discipline that underpins safe agent architecture.

Who Sits in the Approval Chain

"A human approves it" is too vague to implement. The right human depends on the action's domain, and getting this wrong is a quiet but common failure.

The functional owner approves actions within their domain of expertise. A refund approval should route to someone in customer operations who understands refund policy, not to a generic on-call engineer who'll rubber-stamp it because they don't know any better. A contract action routes to legal. A production change routes to the service owner. The approver must have the context to make the call meaningfully, otherwise the approval is theater.

The accountable owner is the named person ultimately responsible for the agent, who may or may not be the same as the functional approver. They own the agent's policy, its scope, and its incidents. When something goes wrong, they're the one who answers for it.

The governance committee approves the policy, not individual actions. They decide which tiers exist, where thresholds sit, and which capabilities an agent may hold at all. Enterprises maturing their agent programs increasingly stand up a dedicated cross-functional body for exactly this, a governance committee that reviews and sanctions new agent capabilities the way a change-advisory board reviews infrastructure changes.

A recurring mistake is routing approvals to whoever is technically convenient rather than whoever is contextually correct. If your approval queue dumps everything on the engineering team because they built the integration, you've created a bottleneck staffed by people without the business context to approve well. They'll either block everything or approve everything, and both defeat the purpose.

Designing the Approval Workflow

Once you know what needs approval and who approves it, the workflow itself has to be designed, and this is where the agent permissioning UX problem bites hard. A badly designed approval flow trains humans to rubber-stamp, which is worse than no approval at all because it manufactures a false record of oversight.

A few principles that hold up in practice:

Show the action, not the prompt. The approver needs to see exactly what will happen, "transfer $1,500 to account ending 4471, reference invoice #8823", not the agent's internal reasoning or a vague summary. Approval on a clear, concrete action is meaningful; approval on a wall of chain-of-thought is not.

Make the safe default the easy one. If rejecting requires three clicks and approving requires one, you've biased the system toward approval under time pressure. The friction should match the risk.

Set timeouts that fail safe, not fail open. If no human responds within the window, a Tier 3 action must not proceed by default. Plenty of poorly designed systems quietly execute when approval times out, which converts a governance control into a delay. Fail closed on anything consequential.

Log the approval as part of the chain of custody. Who approved, when, what they saw, and what the agent then did, all linked. This is the raw material every audit log regulators will demand is built from, and the foundation for any later forensic investigation of an agent's decision. If the approval isn't logged with the action, you can't reconstruct accountability after the fact.

McKinsey's research on scaling AI agents repeatedly lands on the same operational truth: the organizations capturing value from agents are the ones that built the oversight scaffolding first, then expanded autonomy as trust accumulated, not the other way around.

Common Mistakes That Wreck Agent Governance

A short field guide to the failure modes, because naming them is half the cure.

Approving capabilities, forgetting actions. The most common one. Teams scope tools carefully and never build a runtime gate for high-stakes uses of those tools. The capability is governed; the action is not.

The omnibus approval. A human clicks "approve" once on the agent's entire plan at the start, and the agent then executes a dozen steps, some of which drift far from what was actually reviewed. Approval should attach to consequential actions as they arise, not to a plan that hasn't run yet.

Approver without context. Routing approvals to people who lack the domain knowledge to judge them, producing reflexive sign-offs.

No accountable owner. The agent runs, but no single person owns it. When it errs, the incident review discovers a diffusion of responsibility where everyone assumed someone else was watching, the accountability gap that haunts agents no single person controls.

Static policy, evolving agent. The policy was set at launch and never revisited as the agent's behavior, tools, and usage patterns changed. Governance is not a launch gate; it's a standing function.

Governance in the GaaS Vendor Relationship

When you buy agents as a service rather than building them, the approval question gets a second dimension: which approval controls does the vendor provide, and which must you build on top?

This is a procurement conversation that should happen before signing. A serious GaaS vendor exposes configurable approval policies, you should be able to set your own tiers, thresholds, and human-in-the-loop gates without filing a support ticket. If the vendor's agent only offers "fully autonomous" or "fully manual," that's a red flag; real governance lives in the gradations between. Ask to see the approval configuration surface during evaluation, not after.

You should also clarify where the accountability layer sits. The vendor runs the agent, but in nearly every framework you remain accountable for what it does on your behalf, a reality that becomes painfully concrete in liability and incident scenarios. Contracts and liability waivers shift some risk, but they don't relocate the operational responsibility to supervise. The questions to ask map directly onto the buyer's security questionnaire: Can I configure approval tiers? Are approvals logged immutably and exportable? Can I designate the accountable owner on my side? What happens to a pending Tier 3 action if your service has an outage?

This is also where third-party agent risk enters: an agent you didn't build, approving its own actions inside your environment, is a governance surface you have to extend your own approval policy over rather than trust by default.

Insights Most People Overlook

Approval fatigue is a security vulnerability, not just a UX annoyance. When humans face too many approval requests, they stop reading and start clicking. An attacker, or a misbehaving agent, can exploit this by burying one malicious action in a flood of routine ones. The defense is aggressive pre-authorization of genuinely low-risk actions so that every runtime approval request is rare enough to deserve real attention. Counterintuitively, fewer approval gates, placed precisely, produce more actual oversight than many gates placed indiscriminately.

The agent should propose its own risk tier, and you should never trust it. Useful agents can self-classify a proposed action ("this looks like a Tier 2 refund") to route it efficiently. But the classification must be verified by deterministic policy code, not accepted from the model. An agent that can talk its way into a lower tier is an agent that can be prompt-injected into doing the same. Self-assessment for routing, hard policy for enforcement, never let the thing being governed decide how it's governed.

"Human-in-the-loop" is often a liability-laundering ritual, not a control. Plenty of deployments insert a human approval step purely so the org can say a human approved it, while designing the flow so the human can't realistically do anything but approve. That's worse than honest automation, because it manufactures a paper trail of oversight that didn't happen, and in an incident review, that gap is brutal. If you put a human in the loop, give them the context, time, and genuine power to say no.

The hardest actions to govern are the reversible-but-noisy ones. Everyone gates the irreversible $1M wire. Few think about the agent that sends 4,000 slightly-wrong customer emails, each individually reversible, collectively a reputational fire. Blast radius isn't only about per-action severity; it's severity times volume times reversibility. Tier your approvals on all three, or the agent will find the cheap-per-action, expensive-in-aggregate path you forgot to gate.

Governance maturity is measured by how fast you can safely expand autonomy, not how tightly you restrict it. The point of all this scaffolding isn't permanent restriction, it's earning the data and trust to remove gates over time. A program that still requires the same manual approvals after a year of clean operation has failed differently than one that over-automated. Good governance is a ratchet toward justified autonomy, with the audit trail to prove each loosening was earned.

Frequently Asked Questions

How is agent approval different from traditional RBAC? Role-based access control answers "what is this identity allowed to access." Agent approval adds a temporal, contextual layer: even within its permitted scope, this specific action right now may need sign-off. RBAC for fleets of agents handles the standing permissions; approval workflows handle the in-the-moment decisions RBAC can't capture. You need both, and they're not interchangeable.

Can an agent ever approve another agent's actions? For low-tier, reversible actions, an agent can route, validate against policy, and pre-screen, but the accountability for high-stakes approvals must trace to a human. An agent approving another agent's irreversible action with no human in the chain is exactly the accountability gap that makes incident reviews and regulators nervous. Agent-to-agent validation is fine as a filter; it shouldn't be the final authority on consequential acts.

What's the right number of approval tiers? Three or four covers most real deployments. Fewer than three usually means you've collapsed meaningfully different risk levels together. Many more than four tends to produce a system so complex that approvers can't reason about it, which reintroduces rubber-stamping. Start with read-only, reversible-write, consequential, and irreversible, then adjust.

Who owns approval policy when the agent is from a GaaS vendor? The vendor provides the configuration surface; you own the policy decisions within it. Accountability for the agent's actions in your environment almost always remains yours regardless of contract language. Treat vendor-supplied defaults as a starting point to override, not a policy to inherit.

How do approvals connect to audit and compliance? Every runtime approval should be logged as part of the action's chain of custody, who saw what, who approved, what executed. That record is what audit logs are built from and what makes a later forensic investigation possible. If approval isn't logged with the action it authorized, your compliance story has a hole exactly where regulators look first.

Does requiring approval defeat the purpose of an autonomous agent? Only if you tier it badly. The goal isn't to approve everything, it's to pre-authorize the high-volume, low-risk majority so the agent runs autonomously where it's safe, and reserve human attention for the rare consequential moments. Done right, approval workflows are what allow you to grant more autonomy, because you've contained the downside.

Conclusion

The question "who approves what an agent is allowed to do" doesn't have a single answer, and that's the whole point. Approval authority is layered: policy decides the universe of allowed actions, runtime enforcement gates specific high-stakes actions in the moment, and a named human owner remains accountable for all of it. The teams that govern agents well separate these layers cleanly, map approvals to blast radius rather than applying one rule everywhere, route each decision to someone with real context, and design workflows that produce genuine oversight instead of reflexive sign-offs.

In the broader trust, safety, and governance work of running agentic AI-as-a-service, this is the load-bearing decision. Scoped permissions, kill switches, audit logs, identity for non-human actors, role-based access, every one of those controls exists to enforce an approval decision someone made. Get the approval architecture right and the rest of your governance stack has something solid to stand on. Get it wrong and you're enforcing rules nobody clearly set, which is just expensive ambiguity with a logging system attached.

References

• Google Secure AI Framework (SAIF)
• McKinsey QuantumBlack, AI Insights