MITIGATION · m-opa
Open Policy Agent — a policy-as-code engine for every tool call an agent makes
An agent can invoke any tool it has access to, constrained only by its own reasoning. If that reasoning is manipulated or the agent's permissions are misconfigured, it will call tools it should not. OPA addresses this by placing a policy decision point between the agent and every tool invocation: a Rego policy evaluates the agent identity, the tool, and the parameter envelope before execution proceeds, and the agent cannot reason or argue past the result.
At a glance
TL;DR
- Every tool call the agent makes is sent to OPA before execution: OPA evaluates a Rego policy against the agent identity, tool name, and parameter envelope, then returns allow or deny; the enforcement point acts on that decision, not on its own judgment.
- Rego policies are data, not code: you can update the policy without redeploying the agent, and you can version, diff, and review it like any other artifact.
- OPA decouples the decision (what is allowed) from the enforcement (where it is checked), the same policy can gate tool calls, admission webhooks, and memory writes from a single authoritative source.
- Decision logs emit one structured record per query; feed them to your SIEM to give T2 and T3 detections a per-call audit trail with agent identity, tool name, parameters, and allow/deny outcome.
How it behaves
What it is
Open Policy Agent is a general-purpose policy engine: instead of embedding authorisation logic inside application code, you express rules as Rego policies, store them as data, and the application queries OPA before taking any sensitive action. OPA evaluates the query against the policy and returns an allow or deny decision. The application acts on that decision; it does not make its own judgment.
For agentic systems, that separation matters because an agent's reasoning is a soft control. A manipulated prompt, an injected tool output, or a misconfigured identity can each cause an agent to reach for a tool it should not have. OPA is a hard control: the enforcement point calls POST /v1/data/<package>/allow with the agent identity, the tool name, and the full parameter envelope, and the tool executes only if the result is true. The policy is data, not code, so it can be updated, versioned, and reviewed without redeploying the agent. Decision logs emit one structured record per query, giving T2 and T3 detections a per-call audit trail.
Detection signals
- Denial rate by agent identity. A rising rate for a specific identity points to prompt injection, a misconfigured role, or an agent probing the policy boundary.
- Policy evaluation latency per query. A sustained increase signals unusually complex inputs or a policy that is performing HTTP data lookups under load, both of which warrant investigation.
Threats it covers
-
WHY IT HELPS Tool Misuse is the execution of tools with parameters or in combinations the operator did not intend to allow. OPA evaluates the full input envelope, including agent identity, tool name, and parameter values, against a declarative policy before each call, refusing any combination the policy does not explicitly permit.
-
WHY IT HELPS Privilege Compromise relies on an agent identity holding more authority than its assigned role warrants. OPA enforces the declared scope of each agent identity at the decision layer, so a compromised identity is bounded to what its policy allows, regardless of what its prompt or memory claims.
Principle coverage
Defence-in-Depth stage: Prevent — and it advances:
- Zero Trust Zero Trust requires that no identity is inherently trusted. OPA enforces that for agents by requiring an explicit, externally-evaluated policy decision before every tool call, so a valid agent identity grants nothing on its own.
- Default / Implicit Deny OPA implements default-deny structurally: a tool call proceeds only when the Rego policy returns true; any other result, including an error or an absent rule, is a refusal.
- Complete Mediation Complete Mediation requires every access to be checked, not only the first. OPA evaluates each tool call as an independent query, so no invocation proceeds on a cached or prior approval.
Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.
Implementation options
Five deployment options covering the core OPA server pattern, Kubernetes admission control, real-time policy sync, managed control plane, and CI/CD policy gates. For most agentic deployments, OPA server as a sidecar is the starting point; OPAL or Styra DAS add operational reach when the policy corpus grows.
OPA server Run OPA in server mode alongside the agent container. The enforcement point posts a JSON input object to the REST API and refuses the tool call if the result is not true. The canonical starting point for agentic tool-call gating.
Why choose it: Run opa run --server on localhost:8181. The enforcement point posts to /v1/data/<package>/allow; decisions complete well under 1 ms for typical Rego policies. Distribute policy updates via bundles to avoid sidecar restarts.
More details:
OPA Gatekeeper Gatekeeper wraps OPA as a Kubernetes admission webhook. ConstraintTemplates define Rego policy; Constraints instantiate them. Every matching resource change is evaluated before the API server persists it. Best when agentic workloads run as Kubernetes resources and you want admission enforcement without managing a separate webhook.
Why choose it: Deploy via the official Gatekeeper Helm chart (v3.22). Define ConstraintTemplate resources with Rego; instantiate with Constraint objects carrying parameters. The audit controller scans existing resources for violations and surfaces them as status conditions, useful for detecting drift in long-running agent deployments.
More details:
OPAL Open Policy Administration Layer monitors policy and data sources for changes and pushes live updates to connected OPA instances without restarts. Best when policy or authorisation data changes frequently enough that bundle polling intervals introduce an unacceptable lag.
Why choose it: Deploy OPAL server watching the policy Git repo; OPAL clients run alongside each OPA instance. A merged PR to the policy repo propagates to all OPA sidecars within seconds via WebSocket push, eliminating the reload cycle where a stale policy could allow a call the new policy would deny. Available as Docker Compose or Kubernetes Helm chart.
More details:
Styra DAS Managed control plane for OPA built by OPA's creators. Provides hosted policy authoring, impact analysis, centralised decision log aggregation, and pre-built policy packs. Best when the policy corpus spans multiple services or teams and self-managed bundle servers exceed available engineering capacity.
Why choose it: Impact analysis is the key differentiator: before rolling out a new tool-call policy, preview which historical queries would have been denied, reducing the risk of false-positive refusals in production. DAS pushes bundle updates to connected OPA instances and collects decision telemetry for compliance dashboards.
More details:
Conftest Command-line tool that tests structured configuration files against Rego policies in CI. Supports Kubernetes manifests, Terraform plans, Dockerfiles, and any JSON/YAML format. Best as a shift-left complement to the runtime OPA sidecar.
Why choose it: Run conftest test in CI against agent configuration files, tool descriptor schemas, and infrastructure-as-code. A Rego rule that denies an overly broad wildcard scope in a tool-call policy catches the misconfiguration at PR time rather than at runtime. Conftest uses the same policy format as OPA, so rules are portable between the CI gate and the runtime sidecar without translation.
More details:
Trade-offs
- OPA decides; it does not enforce. Every deployment must ensure the enforcement point actually acts on a deny result. A misconfigured enforcement point that logs the denial but proceeds produces an audit trail that looks correct while the protection is absent.
- Policy evaluation latency is low for typical Rego (well under 1 ms per decision) but rises sharply when policies perform HTTP external data lookups or evaluate large bundle datasets. Benchmark under realistic load before assuming a latency budget.
- Rego has a learning curve unlike most languages. Its Datalog-derived evaluation model surprises engineers trained on imperative or functional languages. A policy that appears correct but evaluates in an unexpected order is a silent gap. Budget for Rego training and mandatory peer review of all policy files before production deployment.
- Policy authoring is the dominant dev-effort cost: a well-scoped policy covering twenty tool types with per-user ABAC conditions typically takes two to four engineering weeks to write, test, and review. The sidecar infrastructure is hours; the policy corpus is weeks.
When NOT to use
- Do not use OPA when policy changes faster than bundle reload or OPAL push can propagate. If the policy corpus changes multiple times per hour, an in-process rule table with a hot-reload path is operationally simpler.
- Do not deploy OPA as a sidecar in resource-constrained environments where its memory footprint (roughly 50-100 MB resident for a basic instance) is a meaningful fraction of available resources.
- Do not encode application business logic in Rego. OPA is an authorisation decision engine, not a stateful workflow engine. Pricing tiers, multi-step approval workflows, and persistent state belong in application code, not policy files.
Limitations
- OPA only decides; the enforcement point must act. A compromised or misconfigured agent that bypasses the OPA call entirely receives no protection from OPA. Pair with a service mesh (Envoy with the OPA-Envoy plugin) or API gateway layer that enforces the policy at the network level, independent of agent application code.
- Rego policies that check tool names rather than tool capabilities and user-authorisation context produce a surface-level gate: a novel tool name passes while performing the same underlying operation. Policy authoring must target the semantic action, not just the syntactic name.
- Bundle-based policy distribution has an inherent propagation delay (polling interval plus network round-trip). An OPA instance running a stale bundle may allow or deny calls based on outdated policy. OPAL reduces this gap; it does not eliminate it for the brief window between a push and acknowledgment.
- Decision logs record the input and the decision but not the downstream effect. Whether the allowed tool call produced a harmful output is outside OPA's visibility. Pair with m-output-moderation and m-actor-recorder-split for post-decision observability.
Maturity tier reasoning
- Tier 1 fits because OPA is a CNCF Graduated project with documented production deployments at Netflix, Capital One, Atlassian, Goldman Sachs, and others (public ADOPTERS.md). The REST integration pattern, Rego policy language, bundle distribution, and decision logging APIs are stable and versioned.
- Not Tier 2, because the engine itself is not experimental or calibration-dependent. The remaining work for any deployment is policy authoring, which is expected and documented, not a maturity gap in OPA.
- Not Tier 3, because the technology is production-proven at scale across the industry, not research-demonstrated or framework-dependent.
Last verified against upstream docs: 2026-05-30.