Open Policy Agent
Open Policy Agent is a general-purpose policy engine and Rego policy language for moving authorization and other policy decisions out of ad hoc service code and into reviewable policy-as-code.
Definition
Open Policy Agent, usually shortened to OPA, is an open source, general-purpose policy engine. The Cloud Native Computing Foundation lists OPA as a graduated project and records its path from CNCF acceptance on March 29, 2018, to incubation on April 2, 2019, and graduation on January 29, 2021.
OPA's governance value is separation. Instead of burying rules inside every service or agent tool, a system can ask OPA a structured question and receive a decision. That makes policy reviewable, testable, versioned, and auditable, but it still requires enforcement.
For AI agents, OPA is useful at the tool boundary. A model may propose sending email, changing a repository, exporting records, or calling a cloud API. The application still decides whether this user, agent, tool, resource, and context are allowed.
How It Works
OPA policies are written in Rego, a declarative language built for policy evaluation over structured data such as API requests, configuration, and infrastructure-as-code files. Rego rules inspect input, policy data, and other documents, then produce decisions that the calling system can enforce.
The common architecture is a policy enforcement point asking a policy decision point. The enforcement point intercepts an action. OPA evaluates the request against loaded policy and data, then returns an answer. Depending on the policy, that answer can be a boolean such as allow or deny, or a structured object with reasons, obligations, filters, or decision metadata.
OPA also supports operational practice. Its documentation describes Rego policy tests and bundles that package policy and data for distribution. Those features matter because policy-as-code only helps if policy is tested and delivered through controlled change.
Agent Context
Agent platforms often put language interpretation upstream of real authority. A prompt produces a planned tool call; the surrounding software turns that plan into a side effect. OPA belongs after interpretation and before side effect, where the request has been converted into explicit fields.
A useful agent authorization input might include the human principal, agent identity, tenant, tool, action, resource, requested fields, purpose, approval state, risk tier, and session constraints. OPA can then evaluate rules such as draft-but-do-not-send email, read metadata but not payment details, or require approval for production configuration changes.
This pattern belongs beside AuthZEN Authorization API and Cedar Authorization Policy Language. AuthZEN standardizes a PDP/PEP exchange. Cedar is another policy language and evaluation engine. OPA is a general-purpose engine with Rego and broad integrations.
Governance and Safety
OPA can make agent permissions legible, but it cannot guarantee safety by itself. It does not know whether a prompt was malicious, a retrieved document was poisoned, a tool description was misleading, or a reviewer understood the action. It evaluates the policy question it receives.
The weak point is the input contract. If the tool broker calls a destructive action "read," omits the resource, or lets the agent bypass the broker, the policy engine cannot repair the design. A strong deployment treats the input schema, tool registry, identity binding, and enforcement path as security boundaries.
A governed system should preserve policy bundle version, input schema version, principal, agent identity, action, resource, decision, reason code, approval record, and enforcement result. The audit question is not just "what did OPA decide?" It is also "was that decision enforced before the side effect?"
Defense Pattern
- Put enforcement at the boundary. Check policy where tools, APIs, databases, and external side effects are actually invoked.
- Define a strict input schema. Make principal, agent, action, resource, tenant, purpose, approval, and risk fields explicit.
- Version policy and data. Treat Rego files and policy data bundles as reviewed production artifacts.
- Test denial paths. Write cases for prompt-injection, tool-confusion, overbroad delegation, stale approvals, and alternate tools.
- Fail closed for high-risk actions. Ambiguous or incomplete policy input should block or route to human review, not silently permit.
- Log the enforcement result. Preserve the OPA decision and the downstream fact that the action was allowed, blocked, or escalated.
Source Discipline
Claims about OPA should cite the official OPA documentation, the Open Policy Agent GitHub repository, or the CNCF project page. Use OPA's policy-language documentation for Rego claims, policy-testing documentation for tests, and bundle documentation for packaging and distribution. Do not collapse OPA into Cedar, AuthZEN, Kubernetes admission control, API gateway configuration, or every system that calls itself policy-as-code.
Spiralist Reading
Spiralism reads OPA as an interpreter for institutional limits. The agent speaks in flexible language, but the organization must still answer in harder fields: who is acting, through what agent, on which resource, under what authority, and with what record left behind.
Open Questions
- Which agent fields are mandatory before a policy decision can be trusted?
- Should every tool call be checked, or only calls above a risk threshold?
- How should denied agent actions be explained without leaking sensitive policy details?
- What evidence proves that a policy decision was enforced before the side effect?
Related Pages
- Cedar Authorization Policy Language
- AuthZEN Authorization API
- AI Agent Identity
- Confused Deputy Problem
- Capability-Based Security
- AI Agent Sandboxing
- AI Audit Trails
- OAuth Resource Indicators
- Sender-Constrained Tokens
- Model Context Protocol
- Tool Use and Function Calling
- Secure AI System Development
Sources
- Open Policy Agent, Documentation, reviewed June 25, 2026.
- Open Policy Agent, Policy Language, reviewed June 25, 2026.
- Open Policy Agent, Policy Testing, reviewed June 25, 2026.
- Open Policy Agent, Bundles, reviewed June 25, 2026.
- Cloud Native Computing Foundation, Open Policy Agent (OPA) project page, reviewed June 25, 2026.
- open-policy-agent maintainers, Open Policy Agent GitHub repository, reviewed June 25, 2026.