EVIDENCE TRAIL
Pre-execution validation — gate tool calls on schema and policy
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The title "pre-execution validation" is Helmwart's normalised label — OWASP Agentic AI v1.1 §T2 and OWASP Top 10 Agentic 2026 §ASI02 both use the phrase "pre-execution validation" and "pre-execution Policy Enforcement Point" verbatim; Helmwart's two-pass (schema + policy) model extends this into an explicit implementation pattern. Note: the MDX frontmatter incorrectly cites LLM07 (System Prompt Leakage) for parameter-side controls — LLM07 does not address tool parameter validation; LLM06 (Excessive Agency) is the correct OWASP LLM Top 10 reference and is what the MDX body text cites.
Last cross-checked against upstream sources: · 8 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Agentic AI — Threats & Mitigations v1.1
§T2 Tool Misuse — Mitigation column (threat-taxonomy table, page 16)
"Enforce strict tool access verification or pre-execution validation, implement tool rate-limiting and monitor tool usage patterns, validate agent instructions, and set clear operational boundaries to detect and prevent misuse."
Supports: Direct upstream source for this control's title and scope. Uses the phrase "pre-execution validation" verbatim as a named mitigation for T2 Tool Misuse — the same phrase Helmwart normalises into this control's title.
Does not prove: Does not distinguish schema validation (type/range/enum) from policy validation (business-rule combinations). Helmwart's two-pass model extends the upstream guidance.
OWASP Top 10 for Agentic Applications 2026
§ASI02 Tool Misuse and Exploitation — Prevention and Mitigation Guideline 4 "Policy Enforcement Middleware ('Intent Gate')"
"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: Names a pre-execution Policy Enforcement Point that "validates intent and arguments, enforces schemas" — directly matching this control's two-pass (schema + policy) model. Uses "pre-execution" and "enforces schemas" verbatim.
Does not prove: Frames the gate as an "Intent Gate" / PEP/PDP middleware pattern; Helmwart expresses the same concept as in-process validation middleware. Operational shape is equivalent.
OWASP Top 10 for Agentic Applications 2026
§ASI02 Tool Misuse and Exploitation — Prevention and Mitigation Guideline 7 "Semantic and Identity Validation ('Semantic Firewalls')"
"Semantic and Identity Validation ("Semantic Firewalls"). Enforce fully qualified tool names and version pins to avoid tool alias collisions or typo squatted tools; validate the intended semantics of tool calls (e.g., query type or category) rather than relying on syntax alone. Fail closed on ambiguous resolution and prompt for user disambiguation."
Supports: Names semantic validation of tool calls beyond syntactic schema checks — supporting the policy-validation pass. "Fail closed on ambiguous resolution" aligns with the fail-secure posture this control inherits.
Does not prove: Focuses on tool-name/alias ambiguity rather than parameter-level schema and business-rule validation. Addresses a narrower case than Helmwart's full two-pass gate.
OWASP LLM Top 10 v2025 — LLM06: Excessive Agency
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Upstream risk entry that defines excessive agency as the threat class this control mitigates. Recommends input sanitisation and building tools with granular (rather than open-ended) functionality — the permission-side complement to parameter validation. Note: the MDX frontmatter's independentEvidence field incorrectly cites LLM07 (System Prompt Leakage) for parameter-side controls; LLM07 does not address tool parameter validation. LLM06 is the correct reference and is what the MDX body text cites.
Does not prove: Does not prescribe schema or policy validation specifically; parameter-level enforcement is named here as part of a broader capability-scoping recommendation, not as a standalone gate.
MITRE ATLAS AML.M0030 — Restrict AI Agent Tool Invocation on Untrusted Data
AML.M0030 — description field (ATLAS.yaml, mitre-atlas/atlas-data repository)
"Untrusted data can contain prompt injections that invoke an AI agent's tools, potentially causing confidentiality, integrity or availability violations. It is recommended that tool invocation be restricted or limited when untrusted data enters the LLM's context. The degree to which tool invocation is restricted may depend on the potential consequences of the action. Consider blocking the automatic invocation of tools or requiring user confirmation once untrusted data enters the LLM's context. For high consequence actions, consider always requiring user confirmation."
Supports: Establishes the principle of restricting/blocking automatic tool invocation as a first-class ATLAS mitigation. The "block automatic invocation" posture is the fallback that the pre-exec gate enables when validation fails.
Does not prove: Focuses on restricting invocation triggered by untrusted data (prompt-injection vector), not on validating parameter values against schema bounds. Orthogonal to the schema-validation pass; both controls are needed.
MITRE ATLAS AML.M0028 — AI Agent Tools Permissions Configuration
AML.M0028 — description field (ATLAS.yaml, mitre-atlas/atlas-data repository)
"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: Describes per-tool permission profiles and delegated-access controls that the policy-validation pass enforces at runtime. The "restrictions of the AI agent calling them" framing maps directly to the agent-scoped policy check in this control.
Does not prove: Describes configuration of permissions, not runtime parameter validation. Pre-exec validation is the enforcement mechanism for the policies AML.M0028 says should be configured.
JSON Schema — Specification 2020-12 (draft-bhutton-json-schema-01)
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Community-governed specification that defines the vocabulary used to declare tool-call schemas (types, ranges, enumerations, regex patterns). This is the primitive the schema-validation pass validates against. The current stable version is 2020-12 (IETF draft-bhutton-json-schema-01); it is working toward formal IETF standardisation but is not yet an RFC.
Does not prove: Specification only — does not prescribe when or how validation should be applied in an agentic context. Implementation choice (Zod, Pydantic, etc.) is not specified.
Anthropic Tool Use Documentation — Strict Tool Use
Tool use overview page — Tip callout "Guarantee schema conformance with strict tool use"
"Guarantee schema conformance with strict tool use. Add strict: true to your tool definitions to ensure Claude's tool calls always match your schema exactly."
Supports: Confirms that Anthropic's SDK has a first-party mechanism for enforcing schema conformance on tool calls, making the schema-validation pass implementable without external tooling.
Does not prove: The SDK-level strict mode covers schema conformance only; policy validation (business-rule combinations) still requires application-layer implementation. Does not address the second pass.