EVIDENCE TRAIL
Open Policy Agent (OPA)
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. OPA is an implementation-specific mitigation: the evidence trail focuses on Rego, decision/enforcement decoupling, and OPA deployment patterns rather than the general policy-engine category (see m-policy-bound-autonomy for the broader pattern evidence).
Last cross-checked against upstream sources: · 9 sources
References
Each entry shows what the source supports and what it does not prove.
Open Policy Agent — official documentation (openpolicyagent.org)
Introduction — core value proposition paragraph
"OPA decouples policy decision-making from policy enforcement. When your software needs to make policy decisions it queries OPA and supplies structured data (e.g., JSON) as input. OPA generates policy decisions by evaluating the query input against policies and data."
Supports: Verbatim statement of OPA's fundamental design: the decision/enforcement split. This is the architectural guarantee the MDX relies on when it states that "the policy is data; you can change it without redeploying the agent."
Does not prove: Does not describe agentic AI tool-call scenarios specifically. The intro targets microservices and infrastructure policy; the agentic application is an extension, not a named use case in this section.
Open Policy Agent — Integration documentation (openpolicyagent.org/docs/latest/integration)
§Integrating OPA — overview paragraph
"Integrating OPA is primarily focused on integrating an application, service, or tool with OPA's policy evaluation interface. This integration results in policy decisions being decoupled from that application, service, or tool."
Supports: Confirms the REST Data API integration pattern used in the MDX deployment section: POST to /v1/data/<path>, response contains the decision in the "result" key. Establishes that decoupling is the integration contract, not an implementation choice.
Does not prove: Does not address how an agent identity (e.g. a SPIFFE ID) should be passed in the input document; that mapping is Helmwart's design, not specified by OPA.
Open Policy Agent — Management: Decision Logs (openpolicyagent.org)
§Decision Logs — introduction
"Decision logs contain events that describe policy queries. Each event includes the policy that was queried, the input to the query, bundle metadata, and other information."
Supports: Confirms the audit primitive the MDX relies on: structured, per-query decision records that can be fed into a SIEM. Substantiates the MDX detection signal "Decision-log anomalies (e.g. spike in allow=false for a tool)."
Does not prove: Does not specify SIEM integration formats or retention requirements. Those are deployment concerns, not OPA specification.
CNCF — Open Policy Agent (OPA) project page
CNCF project page — project description and graduation date
"Open Policy Agent (OPA) is an open source, general-purpose policy engine. … moved to the Graduated maturity level on January 29, 2021."
Supports: Confirms the MDX vendorClaim and maturityTier T1 reasoning: graduated CNCF status as of January 2021. Establishes that OPA is not a vendor-locked commercial product.
Does not prove: CNCF graduation measures ecosystem health and governance maturity, not security correctness. A graduated project can still have implementation flaws in specific deployments.
OWASP Top 10 for Agentic Applications 2026
§ASI02 Tool Misuse and Exploitation — Prevention and Mitigation Guidelines, item 4
"Policy Enforcement Middleware ("Intent Gate"). Treat LLM or planner outputs as untrusted. A pre-execution Policy Enforcement Point (PEP/PDP) validates intent and arguments, enforces schemas and rate limits, issues short-lived credentials, and revokes or audits on drift."
Supports: Directly names a "Policy Enforcement Point (PEP/PDP)" as the correct architectural pattern for tool-call authorisation in agentic systems. OPA is the canonical open-source implementation of this pattern. Substantiates both the T2 coverage claim and the enforcement-decoupling architecture.
Does not prove: Does not name OPA by brand. Any PEP/PDP implementation satisfies this guideline; the Helmwart page selects OPA as one concrete answer.
OWASP Top 10 for Agentic Applications 2026
§ASI03 Identity and Privilege Abuse — Prevention and Mitigation Guidelines, item 3
"Mandate Per-Action Authorization: Re-verify each privileged step with a centralized policy engine that checks external data, stopping Cross-Agent Trust Exploitation and Reflection Loop Elevation."
Supports: Names a "centralized policy engine that checks external data" as the mitigation for privilege abuse in multi-agent chains. This is the T3 (Privilege Compromise) coverage the MDX claims. The per-action, per-step verification matches OPA's synchronous query model.
Does not prove: Does not specify Rego or OPA. "Centralized policy engine" encompasses proprietary and cloud-native alternatives. OPA is Helmwart's T1-maturity selection for this pattern.
OWASP Top 10 for Agentic Applications 2026
§ASI08 Cascading Failures — Prevention and Mitigation Guidelines, items 3–4
"JIT, one-time tool access with runtime checks: Issue short-lived, task-scoped credentials for each agent run and validate every high-impact tool invocation against a policy-as-code rule before executing it. This ensures a compromised or drifting agent cannot trigger chain reactions across other agents or systems. Independent policy enforcement: Separate planning and execution via an external policy engine to prevent corrupt planning from triggering harmful actions."
Supports: Uses "policy-as-code rule" and "external policy engine" as the mechanism preventing cascading compromise across agents. This is the broader blast-radius argument for OPA in a multi-agent topology — the MDX's MAESTRO L3/L6 coverage.
Does not prove: The ASI08 focus is on cascading infrastructure failure, not specifically tool authorisation at L3. The policy-engine reference here is a cross-cutting concern, not an exhaustive description of OPA's role.
MITRE ATLAS AML.M0028 — AI Agent Tools Permissions Configuration
AML.M0028 description
"When deploying tools that will be shared across multiple AI agents, it is important to implement robust policies and controls on permissions for the tools. These controls include applying the principle of least privilege along with delegated access, where the tools receive the permissions, identities, and restrictions of the AI agent calling them."
Supports: Defines least-privilege, per-agent tool permissions as a MITRE-catalogue mitigation. OPA is a direct implementation vehicle: the Rego policy can encode exactly these per-agent-identity permission scopes. Substantiates the MDX T2 claim.
Does not prove: ATLAS does not name OPA. AML.M0028 describes a policy pattern, not a technology. "Directly in the configuration files of the tool" is an alternative approach that does not require OPA at all.
MITRE ATLAS AML.M0019 — Control Access to AI Models and Data in Production
AML.M0019 description
"Require users to verify their identities before accessing a production model. Require authentication for API endpoints and monitor production model queries to ensure compliance with usage policies and to prevent model misuse."
Supports: Establishes authentication and query monitoring as ATLAS-recommended controls for production AI systems. OPA satisfies both: its decision model enforces identity-scoped access, and its decision log provides the query audit trail.
Does not prove: AML.M0019 targets model API access control, not tool-call authorisation within an agent. The MDX applies OPA one layer deeper (the agent-to-tool boundary), which AML.M0019 does not describe.