Open Policy Agent

Expanded Definition

Open Policy Agent, or OPA, is a policy engine that evaluates structured inputs against policy rules and returns a decision that software can enforce. It is commonly used to centralise authorisation logic so that applications, APIs, Kubernetes controls, and infrastructure workflows do not each implement their own access rules. That separation improves consistency, but it also means the policy layer becomes a high-value control point that must be governed, tested, and protected like production code.

In security operations, OPA is best understood as a decision component rather than an identity system or an access management product. It does not authenticate users, issue credentials, or replace privileged access controls. Instead, it consumes context such as user attributes, workload identity, request metadata, or environmental conditions and evaluates those inputs against policy. This is why OPA often sits alongside NIST Cybersecurity Framework 2.0 concepts around access control and governance. The most common misapplication is treating OPA as a complete security solution, which occurs when teams use it without version control, policy review, or safeguards against overly broad rules.

Examples and Use Cases

Implementing OPA rigorously often introduces policy-management overhead, requiring organisations to weigh centralised control against the cost of maintaining clear, testable rules.

• API authorisation: a service checks whether a request should be allowed based on tenant, role, request path, and time of day, with policy defined separately from application code.
• Kubernetes admission control: deployment requests are evaluated before they are admitted, helping block insecure image sources, privileged containers, or missing labels.
• CI/CD guardrails: build and deployment pipelines use policy checks to prevent releases that violate environment segregation or change-approval requirements.
• Cloud governance: infrastructure requests are assessed against rules for encryption, network exposure, and approved regions, supporting consistent enforcement across teams.
• Agentic workflows: an AI agent can be constrained through policy so that tool calls, data access, and escalation paths are approved only when the context meets defined thresholds, which aligns with the direction of the OWASP Agentic AI Top 10.

Because OPA is policy-as-code, teams can also test and review policy changes using the same discipline applied to application code. This becomes especially important where policy decisions affect NHI, service accounts, or agent actions that can move quickly across environments.

Why It Matters for Security Teams

OPA matters because authorisation failures are often logic failures, not just identity failures. If policies are ambiguous, stale, or inconsistently deployed, security teams may believe access is controlled when the actual decision path is permissive. That creates risk in multi-team environments where application owners, platform teams, and security teams all influence the same policy boundary. In AI-adjacent use cases, the policy layer may also govern which tools an agent can invoke, what data it can retrieve, and when escalation is permitted, which makes policy integrity part of runtime safety rather than a back-office control.

For governance work, OPA aligns naturally with policy review, separation of duties, and change traceability. Its role is also relevant to broader AI risk management because policy enforcement is one of the practical ways to constrain unintended system behaviour, a theme reflected in the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework. Organisations typically encounter policy drift, unexpected privilege expansion, or unsafe agent behaviour only after an incident review, at which point OPA becomes operationally unavoidable to correct.

Related resources from NHI Mgmt Group

• Who should own approval policy for autonomous agent actions, IAM or application teams?
• How should organisations enforce AI policy compliance across employee and agent use?
• What breaks when policy says one thing and the agent executes another?
• Why do agent workflows need more than static policy enforcement?