Your Authorization Platform Doesn't Govern Your Agents
There's a sentence being said in every security review this year, and it's quietly wrong:
“Agent permissions? We're covered. We use OPA.”
Sometimes it's WorkOS FGA. Sometimes Oso, or Cerbos, or OpenFGA. All excellent tools, built by people who think seriously about access control. And if you're building an application that AI agents will touch, you should probably be using one of them.
Here's the problem. “AI agent permissions” is one phrase describing two completely different problems, and an authorization engine only solves one of them.
The engine decides what an agent may do inside your application. It says nothing about what your agents are doing everywhere else: which credentials they carry into GitHub, what they're spending on model calls, what they touched across nine systems last Tuesday. You bought a beautiful lock for the front door. Your agents left through the garage with your keys and a company card.
What authorization engines actually solve
Credit where it's due, because this layer is real and hard.
Fine-grained authorization platforms exist because traditional RBAC collapses under agent workloads. Roles were designed for humans with stable jobs. Agents need resource-level, dynamically evaluated permissions, and modeling that with roles produces monstrosities like support-agent-tier-2-read-only-repo-b. Role explosion isn't a failure mode at agent scale. It's a lifestyle.
The engines fix this properly. WorkOS FGA models hierarchical, resource-scoped permissions as a managed service. Oso embeds policy logic directly in your application. Cerbos centralizes YAML-defined decisions for microservices. OPA runs policy across cloud-native infrastructure. OpenFGA brings Google Zanzibar's relationship graphs to open source. If your question is “should this agent be allowed to read this document in my product,” these tools answer it in milliseconds, at scale, correctly. [LINK first mention of the engines to the WorkOS article]
That question matters. It's just not the question that produces the incident report.
Your agent has a life outside your app
An authorization engine evaluates requests that arrive at your application's door. But look at what an agent actually does in a working day.
It authenticates to GitHub with a token someone pasted into a config file. It calls an LLM provider on a key shared by eleven other agents. It posts to Slack, queries a warehouse, files a ticket in Jira, and spawns a sub-task that does all of the above again. Every one of those actions happens outside your application, beyond the reach of the policy engine, using credentials your identity provider has never seen.
That outbound life is where the actual risk lives. Of the 3,012 servers in the official MCP registry, 91.5% still rely on static keys, personal tokens, or no authentication at all. The enterprise ratio of non-human identities to humans has hit 144 to 1, and RBAC was built for the 1. And 88% of organizations running agents confirmed or suspected a security incident in the past year, per Gravitee's State of AI Agent Security 2026. Those incidents didn't happen because a policy engine returned the wrong answer. They happened because nobody was governing the credentials, the spend, and the audit trail of agents moving between systems.
A sub-50-millisecond decision about the wrong question is still the wrong question.
Two layers, both real
So the honest architecture has two layers, and neither replaces the other.
Inbound authorization is the engine's job: what may this agent do inside my application's resources. Fine-grained, hierarchical, evaluated at machine speed. WorkOS, Oso, Cerbos, OPA, OpenFGA. If you're building an agent-facing product, pick one and sleep better.
Outbound governance is the control plane's job: what do my organization's agents do across every system they touch. That means credentials brokered centrally and injected at runtime, so agents never hold raw keys and revoking one takes one action, not an archaeology project. It means workspace boundaries deciding which teams' agents reach which integrations. It means hard limits on model spend, enforced rather than suggested. And it means one audit trail that follows the agent across systems, because when security asks what an agent did last Tuesday, “check nine tools and correlate the timestamps” is not an answer.
That second layer is what Guild builds. It's framework-neutral and app-neutral by design, because your agent estate isn't one codebase. It's LangChain services, coding agents on laptops, and whatever the next team ships in Q4.
The two layers even compose cleanly: your application uses an authorization engine to gate what arrives, while the control plane governs what your agents carry and where they go. The bouncer checks IDs at your door. The control plane is how you know where your own people went after they left.
Which layer is your gap?
Run the diagnostic. Six questions:
- Revocation. Can you revoke an agent's access to one external service in a single action?
- Attribution. Can you attribute last month's LLM spend to specific agents?
- Trail. Does your audit trail follow an agent across systems, or stop at each system's edge?
- Keys. Do your agents hold raw API keys anywhere: configs, env vars, CI logs?
- Handoffs. When an agent spawns a sub-agent, does your trace survive the handoff?
- Offboarding. If an engineer leaves, do you know which agent credentials leave with them?
If you answered no to the first three or yes to the fourth, your gap is not authorization. You can have the finest policy engine ever written and fail every question on this list, because the list is about governance, and governance lives in a different layer than the one you bought.
FAQs
No, and it isn't trying to be. Authorization engines control what agents may do inside the application that embeds them. Governing agents across an organization requires a separate layer for credentials, spend limits, and cross-system audit trails, which is what an agent control plane provides.
Fine-grained authorization answers “may this agent perform this action on this resource in my app,” evaluated per request. Agent governance answers “what can my organization's agents access anywhere, with whose credentials, at what cost, and with what record.” The first is a component of your application. The second is a layer above all of them.
If you're building agent-facing products and running agents across your org, yes, and they don't overlap. The engine gates inbound requests to your application. The control plane governs your agents' outbound behavior across every system. Most incident reports come from the second category.
No. Different layers, complementary jobs. Keep your authorization engine for in-app decisions. Guild governs the agents themselves: credentials injected at runtime instead of stored in configs, workspace-scoped access to integrations, hard token limits, and a read-only session log of every LLM call, tool invocation, and sub-task.
In most organizations today, nobody. Keys live in config files and environment variables, outside SSO and outside the policy engine. A control plane centralizes them at the organization level and injects them at execution time, so agents never hold raw keys and disconnection is instant and universal.
Per-system logs can't answer this, because the story crosses their boundaries. You need session-level logging at the governance layer: every LLM call, tool invocation, error, and sub-task spawn in one timestamped, read-only record, including work that passed between agents.
Score both layers separately. For the authorization layer: granularity, latency, hierarchy support, policy flexibility. For the governance layer: credential brokering, one-action revocation, per-agent cost attribution, and whether the audit trail survives crossing systems. A vendor that answers layer-one questions with layer-two language, or vice versa, is telling you which layer they actually live in. For the fuller evaluation framework, see our guide to choosing an agent governance platform.
The complete agent lifecycle.
No credit card required.