EVIDENCE TRAIL
Policy-bound autonomy
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The "autonomy envelope" framing is Helmwart's normalised label — upstream sources variously describe it as "dynamic policy," "per-action authorization," "strict tool access control," and "least model privilege." The closest wording match for a runtime policy engine enforcing agent action scope is OWASP Top 10 Agentic 2026 §ASI03 Mitigation 3.
Last cross-checked against upstream sources: · 7 sources
References
Each entry shows what the source supports and what it does not prove.
Open Policy Agent — Official Documentation
Introduction — "What is OPA?"
"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 description of the runtime policy-evaluation model this control instantiates. The decoupling of decision-making from enforcement is exactly the seam at which policy-bound autonomy inserts the OPA (or Cedar) call before tool execution. "Policies and data" maps directly to the declarative Rego ruleset that defines the agent's autonomy envelope.
Does not prove: OPA documentation is general-purpose and does not mention AI agents or autonomy envelopes specifically. The agentic application layer — wiring the tool-execution seam to OPA — is Helmwart's design pattern, not OPA's own framing.
NIST SP 800-207 — Zero Trust Architecture
§2.1 Tenets of Zero Trust — Tenet 4
"Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes. … Policy is the set of access rules based on attributes that an organization assigns to a subject, data asset, or application."
Supports: Establishes policy-driven, per-request access decisions as a foundational ZTA tenet. The phrase "dynamic policy" applied to each resource request is the conceptual ancestor of runtime autonomy-envelope evaluation. The MDX content cites this section explicitly.
Does not prove: Does not mention AI agents, language models, or agentic systems. The "subject" in ZTA is a human user or device, not an AI agent. Helmwart extends the ZTA model to the agent action layer.
NIST SP 800-207 — Zero Trust Architecture
§3 Logical Components of Zero Trust Architecture — PE and PEP component descriptions
"Policy engine (PE): This component is responsible for the ultimate decision to grant access to a resource for a given subject. The PE uses enterprise policy as well as input from external sources (e.g., CDM systems, threat intelligence services) as input to a trust algorithm to grant, deny, or revoke access to the resource. … Policy enforcement point (PEP): This system is responsible for enabling, monitoring, and eventually terminating connections between a subject and an enterprise resource."
Supports: The PE/PEP split maps directly to OPA's architecture: the policy engine (PE) evaluates the Rego policy; the tool-execution seam acts as the PEP, allowing or blocking the action based on the engine's decision. Confirms the architectural model the MDX describes.
Does not prove: NIST defines PE/PEP for network and resource access, not for AI tool calls. Helmwart analogises the pattern; the document does not describe agentic action spaces.
OWASP Top 10 for Agentic Applications 2026
§ASI03 Identity and Privilege Abuse — Prevention and Mitigation Guideline 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: Verbatim call for a "centralized policy engine" to re-verify each privileged step — the closest upstream wording match for the runtime policy-evaluation pattern this control implements. "Per-action" matches the tool-execution-seam placement described in the MDX.
Does not prove: ASI03's framing is about privilege escalation and identity abuse, not about declarative autonomy envelopes. Helmwart generalises the "per-action policy engine" pattern beyond privilege-escalation scenarios to all out-of-envelope actions.
OWASP Top 10 for Agentic Applications 2026
§ASI10 Rogue Agents — Prevention and Mitigation Guideline 2
"Isolation & Boundaries: Assign Trust Zones with strict inter-zone communication rules and deploy restricted execution environments (e.g., container sandboxes) with API scopes based on least privilege."
Supports: Names "restricted execution environments … with API scopes based on least privilege" as a rogue-agent countermeasure. The API-scope restriction is an implementation-level expression of the autonomy envelope this control formalises into a declarative policy.
Does not prove: ASI10's primary focus is containment of behaviorally-deviant agents after divergence begins; policy-bound autonomy is a proactive prevention layer applied before execution. The two controls are complementary, not identical.
OWASP Agentic AI — Threats & Mitigations v1.1
Playbook 3: Securing AI Tool Execution & Preventing Unauthorized Actions Across Supply Chains — Step 1 (Proactive)
"Implement strict tool access control policies and limit which tools agents can execute. … Implement granular RBAC & ABAC to ensure AI only has permissions necessary for its role."
Supports: Verbatim pairing of "strict tool access control policies" with "granular RBAC & ABAC" as the proactive layer for containing tool misuse and privilege compromise (T2, T3). Both bullets describe exactly the policy-engine-enforced action-space restriction this control implements.
Does not prove: Playbook 3 describes the control class (RBAC/ABAC policies); it does not specify OPA or Cedar as the engine, nor does it describe the autonomy-envelope abstraction or the Rego policy-authoring investment required.
OWASP AI Exchange — LEAST MODEL PRIVILEGE
§1.3 Controls to limit the effects of unwanted behaviour — #LEAST MODEL PRIVILEGE
"Minimize what a model can do (trigger actions or access data), to prevent harm in case the model is manipulated, or makes a mistake by itself."
Supports: Concise upstream statement of the principle: the model's action and data-access space should be minimised. This is the principle that the autonomy-envelope policy operationalises into a machine-evaluable ruleset.
Does not prove: The AI Exchange control is principle-level guidance; it does not prescribe a runtime policy engine, OPA/Cedar, or the tool-execution seam as the enforcement point. Implementation specifics are Helmwart's.