2938 Members
Join Permit's SlackBanks, insurers, and enterprise AI teams are already shipping copilots and autonomous agents into production. MCP adoption is moving fast, and teams are wiring agents directly into internal APIs, ticketing systems, SQL backends, and payment rails right now. The uncomfortable part: many of these deployments are still enforced by OPA policies designed for deterministic microservices, not delegated, multi-hop agent workflows.
That mismatch is already showing up in production: over-broad tool access, weak delegation traces, and "who actually authorized this call?" incidents during audit.
If you already run OPA, the answer is not to replace your stack. The answer is to evolve how you use OPA: richer input context, ephemeral agent identity, real-time policy data sync via OPAL, and enforcement at multiple layers — gateway, API, and data. OPA remains the policy decision point. The model remains the planner. Keep those concerns separate.
You are probably sending OPA inputs that look like this today:
{
"subject": "svc:payments-api",
"action": "read",
"resource": "account:1234"
}
That shape works for stable service callers. It breaks for agents.
A single "answer the customer" task can trigger 10+ downstream tool calls. Agents spawn sub-agents. Authority is delegated from a human principal. Callers are ephemeral. Tool sets are dynamic. If your OPA input still only includes {subject, action, resource}, your policy cannot reason about delegation boundaries or multi-hop scope.
For agent tool calls, you need to send something closer to:
{
"actor": {
"id": "agent:case-resolver:run-7f3a",
"role": "support_agent",
"tenant": "acme-co"
},
"user": {
"id": "user:banker-4421"
},
"action": {
"type": "tool.invoke",
"tool": "crm.get_customer_profile",
"tenant": "acme-co"
},
"delegation_chain": [
{
"from": {"type": "user", "id": "user:banker-4421"},
"to": {"type": "agent", "id": "agent:case-resolver:run-7f3a"},
"scope": ["crm.get_customer_profile", "tickets.read"],
"tenant": "acme-co",
"expires_at": "2026-05-24T18:30:00Z"
}
],
"parent_agent": {
"id": "agent:supervisor:run-111",
"tool_scope": ["crm.get_customer_profile", "tickets.read"],
"tenant": "acme-co"
},
"workflow": {
"id": "wf-90812",
"task": "resolve_customer_case"
}
}
That is the migration story for OPA users: you are not abandoning policy-as-code; you are upgrading the policy context so OPA can evaluate delegated authority correctly.
Agentic identity is not just a service account with a new name. It is a composite, short-lived identity bound to user delegation, workflow context, tenant scope, and expiry. If that identity context is missing from input, OPA cannot enforce least privilege — it can only see half the picture.
For agents, Zero Standing Permissions should be your default. No persistent agent credentials. No long-lived wildcard tokens. Every action must carry short-lived, delegation-scoped context, and OPA must evaluate that context on each hop.
This is familiar territory if you already run deny-by-default policies. The extension is direct:
This is where OPAL becomes operationally important. When user entitlements change mid-workflow, the very next OPA decision must reflect the change immediately. In distributed agent systems with multiple PDP instances, periodic bundle pulls are too slow for revocation-sensitive workloads — OPAL pushes policy and data updates in real time across every instance.
The concrete examples make the stakes clear. In a banking copilot, the agent must only access accounts the banker is currently entitled to view, not every account the underlying service integration can technically reach. In a travel automation flow, a booking agent may spawn flight, hotel, and payment sub-agents, but the payment sub-agent must get tighter scope than the parent, never broader. In support over MCP, tool calls must stay tenant-bound even when the model is prompted to look up accounts in another tenant.
You need a deterministic PDP to constrain a non-deterministic planner. That is exactly OPA's job.
Policy-as-code with Rego. Agent authorization requires real logic: delegation chain validation, set intersections, parent-child scope limits, tenant invariants, expiry checks. Rego expresses and tests all of this as versioned, auditable code. Prompt guardrails do not give you deterministic policy semantics or an independent audit trail.
Deterministic enforcement around non-deterministic LLM behavior. LLMs can propose any action sequence. OPA makes binary, reproducible decisions on each proposed action with clear policy semantics. The model stays creative; the PDP stays firm.
Decoupled authorization. OPA sits outside the agent runtime. You can change policy without redeploying orchestrators or tools. You can audit decisions and their inputs independently, which is what compliance reviews for enterprise AI will increasingly require.
Low-latency local execution. Tool call loops are sensitive to per-call overhead. An OPA sidecar or embedded PDP keeps authorization checks fast enough for iterative agent workflows without adding round-trip latency to every step.
Composability across layers. The same OPA engine can enforce at gateway, API, and data layers simultaneously. That gives you coherent policy semantics end-to-end rather than disconnected controls stitched together at each layer.
OPAL is the production complement to OPA in distributed agent deployments. Agent workflows span multiple services and often multiple PDP instances. When a user's access is revoked, every PDP must reflect that change before the next hop executes. OPAL provides the real-time sync layer — pushing policy and policy-data updates to all PDP instances the moment state changes. Without it, revocation in a multi-hop agent workflow is eventually consistent at best.
package agent.authz
import rego.v1
# Input shape:
# input.actor.id -> ephemeral agent id
# input.actor.role -> agent role (maps to allowed tools in data.role_tools)
# input.actor.tenant -> tenant bound to this agent run
# input.user.id -> delegating human principal
# input.action.tool -> requested tool name
# input.action.tenant -> tenant of requested operation
# input.delegation_chain -> ordered array of delegation hops
# input.parent_agent -> optional parent agent with tool_scope + tenant
default allow := false
allow if {
tenant_boundary_respected
delegation_chain_valid_and_user_anchored
tool_in_agent_role_scope
tool_in_user_delegated_scope
child_not_exceeding_parent_scope
}
# Tenant boundary must hold across actor, action, and all chain hops
tenant_boundary_respected if {
input.actor.tenant == input.action.tenant
every hop in input.delegation_chain { hop.tenant == input.action.tenant }
not has_parent_agent
} else if {
input.actor.tenant == input.action.tenant
input.parent_agent.tenant == input.action.tenant
every hop in input.delegation_chain { hop.tenant == input.action.tenant }
}
# Chain must start at the user and end at the current agent, with no expired hops
delegation_chain_valid_and_user_anchored if {
count(input.delegation_chain) > 0
first := input.delegation_chain[0]
first.from.type == "user"
first.from.id == input.user.id
last := input.delegation_chain[count(input.delegation_chain) - 1]
last.to.type == "agent"
last.to.id == input.actor.id
now := time.now_ns()
every hop in input.delegation_chain {
time.parse_rfc3339_ns(hop.expires_at) > now
}
every i in numbers.range(0, count(input.delegation_chain) - 2) {
input.delegation_chain[i].to.id == input.delegation_chain[i + 1].from.id
}
}
tool_in_agent_role_scope if {
input.action.tool in data.role_tools[input.actor.role]
}
tool_in_user_delegated_scope if {
input.action.tool in data.user_tool_perms[input.user.id][input.action.tenant]
}
# Child agent cannot exceed what the parent was permitted to do
child_not_exceeding_parent_scope if { not has_parent_agent }
else if { input.action.tool in input.parent_agent.tool_scope }
has_parent_agent if { input.parent_agent.id != "" }
The core principle this encodes: effective permission = intersection of agent role scope, user delegation scope, chain validity, and parent constraints. Each rule is independently testable; you can opa test against known-good and known-bad delegation scenarios before deploying.
Treat OPA as a composable enforcement fabric, not a single gate. The request lifecycle in a properly controlled agentic stack looks like this:
User → Agent Orchestrator → MCP Gateway → API/Service → Database, with OPAL Sync feeding all PDP instances in real time.
OPA check #1 at MCP Gateway (coarse scope). Before any tool execution, evaluate whether this agent run may invoke this tool class at all. Input includes agent id, user id, tenant, workflow id, and requested tool. Deny broad categories outright: payments.* is blocked unless explicitly permitted at this layer.
OPA check #2 at dedicated PDP (fine-grained delegation). Evaluate full chain validity, parent/child scope, user entitlement intersection, and tenant consistency — the Rego above. This is where delegation context is fully interrogated.
OPA check #3 at API/service layer (endpoint-level). Tool permission is not equivalent to unrestricted API permission. Even after tool authorization, enforce endpoint and resource policy for the resulting API call.
OPA check #4 at data layer (row/column via partial evaluation). Apply row filters, column masking, and tenant isolation in SQL paths. OPA partial evaluation turns policy rules into query constraints — so data access stays bounded to the delegating user's entitlements even if upstream checks are misconfigured.
OPAL sync across all PDP instances. Every layer above runs an OPA instance; every instance must converge on policy and entitlement data in real time. If a banker loses access mid-session, the next gateway, API, and data check all deny — immediately, not after cache expiry.
This architecture is more resilient than single-layer "AI guardrails" precisely because a gap at one layer does not become total compromise — the next layer still evaluates and can deny.
If you want to keep OPA and OPAL as your policy core but reduce the operational burden of running distributed enforcement infrastructure, Permit.io is built to sit on top of that stack for agentic deployments.
Managed OPA + OPAL PDPs. Hosted PDP infrastructure with real-time OPAL sync, so you get distributed, low-latency enforcement without running all control-plane plumbing yourself. The OPA semantics stay the same; the infrastructure management disappears.
Policy Editor. Security and compliance teams need to modify agent authorization rules without owning the Rego pipeline. Permit.io's policy editor provides a visual low-code interface that writes and updates policies grounded in OPA, so operators can change what agents are allowed to do without a code deploy.
Agent Interrogation. Debugging agentic authorization in production means being able to ask the PDP a direct question: What can this agent do right now, for this user, in this workflow? This is the operational layer for incident response, compliance attestation, and pre-deployment validation — not just after-the-fact log review.
Agentic Identity Minting. Permit.io provides first-class primitives for creating ephemeral agent identity tokens that carry delegation context, user scope, tenant boundary, and policy-enforced expiry. These are not JWTs with extra claims bolted on; they are purpose-built identity objects that OPA can evaluate with the full input schema above.
MCP Gateway. For MCP-based stacks, Permit.io's MCP Gateway sits at the protocol boundary between agents and tool servers — enforcing authorization before tool execution rather than relying on application-layer checks that may be inconsistently applied.
Downstream enforcement. Permit.io extends policy enforcement into API and data layers, completing the defense-in-depth chain. Most AI security products stop at the gateway or the prompt; downstream row/column enforcement is where the actual sensitive data lives.
The framing that matters: this is not "replace OPA." It is "operate OPA and OPAL for agentic deployments with fewer moving parts and better ergonomics for operators who are not Rego authors."
Stay on Rego. Agent authorization is still authorization — the complexity comes from richer context, not from the need for a new paradigm. What changes is the input schema and the policy modules you write against it, not the toolchain. Your existing opa test and opa check workflows apply directly.
You can get started there, but it is not sufficient for production. Gateway checks are coarse by design and cannot see downstream data access patterns. Agent systems are multi-hop and stateful; endpoint and data-layer checks catch overreach and tenant boundary violations that gateway controls are structurally blind to.
Short enough that replay and drift risk are bounded to minutes, not hours. In practice, tie expiry to workflow or task duration with explicit renewal rules, and require re-evaluation at each tool call rather than once per session. If a workflow normally takes five minutes, a twenty-minute expiry is reasonable; a twenty-four-hour one is not.
With OPAL sync, the next authorization decision reflects the updated entitlements before the next hop executes. Without real-time sync, you are relying on cache expiry — which is too slow for regulated contexts where immediate revocation is a compliance requirement, not a preference.
Only for tightly bounded, user-independent infrastructure operations. For any workflow that acts on behalf of a specific user, a service account hides accountability, usually violates least privilege, and breaks every downstream attempt to apply per-user data constraints. If your agent is a delegated actor, its identity must carry that delegation.
Add a new agent.authz package alongside your existing policies and evolve the input schema at the orchestrator and gateway boundary. Start with deny-by-default and explicit allowlists for high-risk tools, then layer in delegation chain validation and parent-scope rules as identity minting matures. You do not need to migrate existing microservice policies to the agent schema — they coexist.
No. Read-only still means potentially sensitive reads across tenants, accounts, and regulated data fields. Most real authorization incidents are unauthorized reads, not writes — and tenant isolation failures in read paths are exactly what row/column enforcement at the data layer prevents. Apply delegation constraints from day one.
Passionate and result-driven DevOps Engineer with hands-on experience in designing, implementing, and maintaining cloud infrastructure, with expertise spanning Kubernetes, CI/CD pipelines, and GitOps methodologies.
