Why Not Just Use OPA and a Service Mesh?
Every time I talk about the Agentic Control Plane, someone asks the same question: “Why can’t I just use OPA? Or Istio? Or my API gateway? I already have policy enforcement and identity.”
It’s a fair question. If you’ve spent years building a mature infrastructure stack — Open Policy Agent for fine-grained authorization, a service mesh for mTLS and traffic policy, an API gateway for rate limiting and auth — the idea that you need something new for AI agents is annoying. You’ve solved this before.
So let me take the objection seriously. Where does your existing stack actually work for AI agent governance? Where does it break? And what’s genuinely missing?
What your existing stack handles well
OPA is excellent at policy decisions. You define rules in Rego, feed it structured input (who’s asking, what they’re asking for, what context exists), and it returns allow/deny. If you can get the right input to OPA, it will make the right decision. The policy language is expressive enough to handle complex RBAC, ABAC, and even context-dependent rules.
Istio/Linkerd handle service-to-service identity. mTLS between services means your finance API knows it’s talking to an authenticated service, not a random caller. Traffic policies can enforce which services talk to which. This is real security, and it works.
API gateways (Kong, Apigee, AWS API Gateway) handle rate limiting, API key validation, OAuth token verification, and request transformation. If you need to throttle calls to an API and verify that the caller has a valid credential, your gateway does this today.
IAM (AWS IAM, GCP IAM, Azure AD) handles which service accounts can access which cloud resources. If your agent runs as a Cloud Run service, IAM controls what that service can reach.
These aren’t toys. They’re production-grade systems that protect real infrastructure at scale. The question isn’t whether they work — it’s whether they work for the specific problem AI agents introduce.
Where it breaks: the identity gap
Here’s the scenario. A user asks an AI agent to pull last quarter’s revenue numbers. The agent calls your finance API.
In your existing stack, this is what happens:
- The agent runs as a service with a service account.
- Istio verifies the service’s mTLS certificate. The mesh sees:
agent-service → finance-api. Valid. - The API gateway checks the service’s API key or JWT. Valid.
- OPA evaluates the policy. Input:
{ "service": "agent-service", "action": "read", "resource": "revenue" }. The agent service is allowed to read revenue data. Allow. - IAM confirms the service account has the
finance.readrole. Allow.
Everything passed. The request goes through.
But who asked?
Was it the CFO? A sales rep? An intern? Someone who left last week? Your entire stack authenticated the service. Nobody authenticated the user behind the service. The agent has one identity to your backend regardless of which user is driving it.
OPA made the right decision given its input. The problem is that OPA never received the user’s identity as input because it wasn’t in the request. The service mesh verified service-to-service trust. But the question was never service-to-service — it was user-to-service-via-agent.
This is the three-party identity problem. Your infrastructure was designed for bilateral trust (user ↔ service or service ↔ service). AI agents add a third party, and the user’s identity gets lost at the boundary where the agent makes the call.
“I’ll just pass the user’s token through the agent”
This is the first thing people try. Take the user’s JWT, attach it to every tool call the agent makes, and let the downstream service validate it as usual.
It works — until you think about what you’ve done.
You’ve given an AI agent a bearer token with the user’s full permissions. The agent can now make any API call the user is authorized to make. The LLM decides which calls to make. If the agent is tricked by a prompt injection, if it hallucinates an action, if a malicious skill in the tool chain intercepts the token — it has the user’s credentials.
In a traditional system, the user’s browser makes requests and the user can see what’s happening. An agent operates autonomously. It makes sequences of tool calls based on LLM reasoning. You’ve handed it the keys and turned off the dashboard.
OPA doesn’t help here. OPA sees a valid user token and a valid action. It allows the request. The issue isn’t the policy — it’s that you’ve delegated unconstrained authority to a system that reasons probabilistically.
What you actually need is scoped delegation: the user’s identity flows through, but the agent’s permissions are the intersection of the user’s permissions and the agent’s role. The agent acting on behalf of Sarah in sales gets Sarah’s scopes intersected with what the “sales assistant” agent is allowed to do. Not Sarah’s full access. Not the agent’s service account access. The overlap.
Your API gateway can’t compute that intersection because it doesn’t know about agent roles. OPA could compute it — if someone feeds it the agent’s role alongside the user’s identity. But nothing in your current stack does that automatically.
“OPA can handle tool-level policy”
True. You could write Rego policies that govern individual tool calls:
allow {
input.tool == "salesforce.getContact"
input.user.role == "sales"
"crm:read" == input.user.scopes[_]
}
This is valid OPA. If you can get this input to OPA on every tool call, it will enforce it correctly.
But where does this policy get evaluated? In the current agent architecture:
- The user sends a message to the LLM.
- The LLM decides to call a tool.
- The tool call goes… where?
If the tool call goes directly to your backend API, OPA is sitting at the API gateway. It can evaluate the policy — but only if the tool call arrives with the user’s identity and the agent’s role attached. It usually arrives with a shared API key.
If you add middleware to attach identity and role, and route tool calls through your gateway, and write Rego policies for every tool… you’ve built an Agentic Control Plane. You’ve just built it out of OPA and custom glue code instead of using a purpose-built system.
That’s a valid choice. But let’s be honest about the total cost. You need:
- A token exchange service that converts user identity + agent role into a scoped token
- An interception layer that catches every tool call before it reaches backends
- OPA policies for every tool, covering scopes, ABAC rules, and rate limits
- Content scanning (PII detection, prompt injection) — OPA doesn’t do this
- An audit pipeline that correlates user → agent → tool → backend
- Budget controls per user and per agent — OPA doesn’t do this either
The policy engine is 20% of the problem. The other 80% is the plumbing that gets the right data to the policy engine at the right time.
“Okta / Auth0 already handles identity”
They handle user authentication. They verify that Sarah is Sarah. They issue tokens. They manage user directories.
They do not handle agent delegation. There is no standard OAuth flow for “Sarah wants this agent to act on her behalf with a subset of her permissions for the next 10 minutes.” OAuth has scope parameters, but scopes are static — defined at client registration time, not dynamically computed based on which agent is running which task.
You could model agents as OAuth clients and use token exchange (RFC 8693) to get scoped tokens. That’s architecturally correct. But Auth0 doesn’t provide this as a managed flow. You’d need to build the token exchange endpoint, the scope computation logic, and the agent-role registry yourself.
Again: valid. But you’re building the same system with different components.
What’s genuinely missing from existing infrastructure
Here’s what no combination of OPA + service mesh + API gateway + IAM gives you out of the box:
| Capability | Status in existing stack |
|---|---|
| User identity on every tool call | Not automatic — requires custom token propagation |
| Agent-role scoping (user ∩ agent permissions) | Not modeled anywhere |
| Content scanning (PII in tool inputs/outputs) | Not in the stack at all |
| Prompt injection detection on tool arguments | Not in the stack at all |
| Per-user per-agent budget controls | Not in the stack at all |
| Tool-call-level audit trail (user → agent → tool → result) | Requires custom logging pipeline |
| Agent workflow guardrails (max tool calls, max duration) | Not in the stack at all |
The first two are identity problems you could solve with custom plumbing. The rest are domain-specific to AI agent operations and don’t exist in any general-purpose infrastructure tool.
So what should you actually do?
It depends on where you are.
If you have 1-2 internal agents and a mature OPA/mesh stack, you can probably extend what you have. Write the token propagation middleware. Add Rego policies for your tools. Build the audit pipeline. You’ll spend a few engineering sprints on it, and it’ll work for your specific setup. The operational cost is maintaining custom glue code, but if your team knows OPA, that’s manageable.
If you have 5+ agents, multiple teams, or customer-facing agent deployments, the custom glue approach doesn’t scale. Every new agent needs new policies, new token flows, new audit configuration. A purpose-built control plane gives you the interception, identity, policy, content scanning, and audit as a unified layer that applies to every agent automatically.
If you’re going through SOC 2, HIPAA, or any compliance audit and your agents touch customer data, the auditor will ask: “Who initiated this request? What data did the agent access? What permissions did it have?” If your answer involves explaining how you stitched together 4 infrastructure tools with custom middleware, expect follow-up questions. A dedicated governance layer with a coherent audit trail is a simpler story.
I’m not saying throw away your OPA policies or your service mesh. They still protect your service-to-service traffic. They still enforce infrastructure-level policy. The Agentic Control Plane sits at a different layer — between the user, the agent, and the tools — and handles the concerns that are specific to that boundary.
The honest answer
Could you build this yourself? Yes. OPA is a good policy engine. Istio is a good service mesh. You could wire them together with custom middleware and get something that works.
The question is whether you should. The same way you could build an API gateway out of nginx and Lua scripts, but you probably use Kong or Apigee because the integrated solution is faster to operate and easier to audit.
If you’re evaluating whether your existing infrastructure covers AI agent governance, here’s a quick test: pick one agent in your stack and trace a single tool call from the user’s request to the backend response. Can you answer: who asked, what permissions did they have, what data was accessed, was the input scanned for injection, and is there an audit record tying all of that together?
If the answer is yes for all five, you’re in good shape. If you had to say “well, we’d need to add…” for any of them, that’s the gap.
Want help figuring out where your stack has gaps? We do 45-minute architecture reviews — bring your current agent setup and we’ll map exactly where identity, policy, and audit are covered and where they’re not. No slides, just a whiteboard session.
Book an architecture review → · Read the reference architecture → · Try it yourself →