Somewhere in your codebase, three functions deep in a service nobody volunteers to touch, is the logic that decides what your AI agent is allowed to do. It's an if statement. Maybe a switch. It was written by an engineer who has since changed teams, and it has never been read by anyone in security, compliance, or legal.

When an auditor asks the obvious question — "what is this agent permitted to do, and who approved that?" — the honest answer is "give me a day to read the code." That's not a policy. That's a liability with syntax highlighting.

The permission problem got quantitative

For a long time you could get away with it, because you had a handful of agents and you knew them all by name. That era is over. KPMG's Cybersecurity Considerations 2026 report puts non-human identities — service accounts, machine credentials, and now AI agents — at 80 to 1 against human users in the average enterprise, and finds 92% of executives naming "managing AI agents" as the defining security skill of the next five years. (KPMG, 2026)

You cannot hand-audit an 80:1 fleet by reading service-layer code. The buried if statement doesn't scale to that headcount, and it was never legible to the people now accountable for it.

The OWASP community gave the failure mode a name this year. The 2026 OWASP Top 10 for Agentic Applications calls it Excessive Agency, and pairs it with a principle it calls Least Agency: autonomy is a feature an agent should earn, not receive by default, and every consequential action should pass a per-request scope check rather than riding on a token that's simply too broad. (OWASP / aikido.dev, 2026) That's the right instinct. But "earned autonomy" only means something if there is a rule — written down, somewhere legible — that reads the earned state and gates the action. Most teams don't have that rule anywhere you could point an auditor at.

Make the rule a document

The fix is not new; it's just newly urgent. Authorization-as-code has a mature, boring, formally-grounded answer in Cedar — the open-source policy language that also powers Amazon Verified Permissions. Cedar's entire premise is that you decouple the authorization logic from the application logic: permissions become policies your security team can read and change without touching application code, expressed against four things — the principal, the action, the resource, and the context. Cedar's own documentation makes readability a design goal, calling the language "analyzable... easily read and understood by new team members." (Cedar docs)

A rule you can read is a rule you can diff, test, and hand to an auditor. That's the whole game.

There's just one catch, and it's the interesting part.

Cedar is binary. Agents aren't.

Cedar returns exactly two answers: allow or deny. Permit the request, or forbid it.

Real agent governance has a third state, and it's the one that matters most. Sometimes the correct answer isn't "yes" and isn't "no" — it's "I'm not sure; a human should look at this." That's not a hypothetical nicety: KPMG found 61% of US companies have already mandated a human-in-the-loop step for autonomous agents. A binary allow/deny engine cannot express "route to a human." It has to guess, and both guesses are wrong — reflexively denying kills legitimate work, reflexively allowing is how incidents happen.

This is exactly where VeriSwarm's Gate decision engine sits. Gate runs on Cedar — every trust check an agent makes is evaluated against a Cedar policy — but it maps Cedar's two outcomes onto three:

• A matched permit rule → allow.
• An explicit forbid rule → deny.
• The case Cedar treats as an implicit deny — nothing permitted the action, but nothing explicitly forbade it either → review.

That third mapping is the whole point. The absence of a matching permit isn't treated as a hard "no." It's treated as "this wasn't anticipated — send it to a human." Cedar gives you a formally-grounded, readable rulebook; Gate gives that rulebook the vocabulary agent governance actually needs.

What the rule looks like

The agent is the Cedar principal, and its attributes come straight from the trust layer: the policy tier it earned through its behavior, its live risk score, and whether it carries a verified Passport credential. A few rules from the default policy every VeriSwarm agent runs under:

// A killed or restricted agent is denied everything — unconditionally.
// Verifying its identity does not bring it back online.
forbid(principal, action, resource)
when { principal.policy_tier == "tier_x" };

// High live risk overrides everything else.
forbid(principal, action, resource)
when { principal.risk_score >= 75 };

// A verified, low-risk agent gets the safe actions. Destructive
// actions still require a tier the agent has to earn — identity
// verification alone can't unlock them.
permit(principal, action, resource)
when {
    principal.is_verified
    && principal.risk_score < 40
    && (action == Action::"read_data" || action == Action::"send_message")
};

Notice what isn't here: any action that would move money or delete data slipping through on identity alone. Verification is necessary, not sufficient. Autonomy is earned — the OWASP principle, made enforceable.

On Max and Enterprise, tenants write their own rules on top of this. A healthcare workspace can forbid a payment action below its top tier; a support workspace can permit refunds only under a live risk ceiling. The policies are tenant-scoped, so your rulebook is yours.

And you change a rule the way you'd change a document, not the way you'd ship a hotfix. You post the policy to the API, validate its syntax before it's ever stored, and dry-run it against a hypothetical agent to see whether it returns allow, deny, or review — all before it goes anywhere near a live decision. No deploy, no downtime, no coordinating a release across teams.

Two properties matter for the people who'll be audited on this:

It fails closed. If a custom policy is malformed at evaluation time, the decision denies — it does not silently fall back to the permissive default. A broken rule cannot quietly widen access, which is the exact way homegrown policy code tends to fail.

Every change is on the ledger. Each policy you create, update, or delete is written to VeriSwarm's hash-chained Vault audit trail. So the auditor's question from the top of this post — "what was this agent allowed to do on June 1, and who changed the rule?" — has a cryptographic answer, not a git-blame guess.

Start with the engine already running

Here's the part worth knowing: you don't have to write a line of Cedar to benefit from this. Gate is free, and every agent in every workspace is already evaluated against the default policy — you're getting declarative allow / deny / review from day one, whether or not you ever open the policy editor. The upgrade to Max isn't the engine. It's the pen: the ability to write rules specific to your own risk model.

Point your agents at Gate and watch the decisions resolve at veriswarm.ai. When "let me read the code and get back to you" stops being an acceptable answer — and at 80:1, it already has — the rule should be a document. Cedar makes it one. Gate gives it the third answer.