EVIDENCE TRAIL
Tool description validation
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The canonical upstream name for the attack vector is "Tool Misuse via Descriptive Exploitation" (OWASP MAS Guide v1.0 §T16, Scenario 3) and "Tool Poisoning" (OWASP Top 10 Agentic 2026 §ASI02). No upstream source prescribes catalog-load-time schema enforcement as the mitigation point by name — that is Helmwart's operational instantiation of the principle.
Last cross-checked against upstream sources: · 8 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP MAS Guide v1.0 — Multi-Agentic System Threat Modeling Guide
§T16 Insecure Inter-Agent Protocol Abuse — Scenario 3
"Scenario 3: Tool Misuse via Descriptive Exploitation – An attacker embeds misleading or overly broad tool descriptions in a shared tool registry. During agent collaboration, another agent accepts and calls the tool under false assumptions, unintentionally leaking sensitive data or triggering privileged API calls."
Supports: Verbatim naming of the attack vector this control directly targets: misleading or overly broad tool descriptions planted in a shared registry that cause downstream agents to call tools under false assumptions. Closest upstream source establishing "descriptive exploitation" as a canonical T16 sub-scenario.
Does not prove: Does not prescribe catalog-load-time validation as the mitigation point. The MAS Guide's T16 mitigations focus on protocol-level sanitization and authentication rather than schema-enforced description bounds.
OWASP MAS Guide v1.0 — Multi-Agentic System Threat Modeling Guide
§T16 Insecure Inter-Agent Protocol Abuse — Mitigation guidance
"Sanitize and validate all protocol-level data, including context payloads and tool metadata, to prevent injection or misinterpretation. Restrict agent-to-agent delegation to tightly scoped functions. Log all inter-agent communications and tool invocations to detect anomalies and support post-incident analysis."
Supports: Explicitly names "tool metadata" as data that must be sanitized and validated to prevent injection or misinterpretation. This is the upstream justification for applying validation at the catalog registration seam rather than only at call time.
Does not prove: Guidance is at the protocol layer ("protocol-level data") and does not specify length bounds, prohibited-pattern regex, or diff-against-prior-version checks — those rule-set details are Helmwart's operational elaboration.
OWASP Top 10 for Agentic Applications 2026 — ASI02 Tool Misuse and Exploitation
§ASI02 Tool Misuse and Exploitation — Example Attack Scenarios, Scenario 1 "Tool Poisoning"
"Tool Poisoning: An attacker compromises the tool interface - such as MCP tool descriptors, schemas, metadata, or routing information - causing the agent to invoke a tool based on falsified or malicious capabilities. This belongs under ASI02 because the attacker manipulates the interface of an otherwise legitimate tool at runtime; only cases where the tool itself is malicious or compromised at the source fall under ASI04 (Supply Chain Vulnerabilities). Unlike input poisoning, which targets natural-language or data inputs, tool poisoning focuses on corrupting the tool layer itself to drive unintended or unsafe agent actions."
Supports: Establishes "MCP tool descriptors, schemas, metadata" as the specific attack surface targeted by tool poisoning, and distinguishes the tool-layer attack from input poisoning. Validates the description field as an in-scope artifact requiring validation at load time.
Does not prove: The ASI02 framing covers all tool-layer manipulation; it does not single out catalog-load-time as the preferred interception point versus runtime. Helmwart applies this principle specifically to the registration seam.
OWASP Top 10 for Agentic Applications 2026 — ASI02 Tool Misuse and Exploitation
§ASI02 — Prevention and Mitigation Guidelines, Mitigation 7 "Semantic and Identity Validation"
"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 — the same seam where description-pattern rules fire — and version pinning as a defense layer. "Fail closed on ambiguous resolution" aligns with Helmwart's review-queue approach for descriptions that fail validation.
Does not prove: Validation here is framed as runtime semantic checking of calls, not pre-registration schema enforcement of description content. The connection to catalog-load-time description bounds is Helmwart's extension.
Model Context Protocol Specification — Tools
MCP Tools specification — Data Types § Tool, security warning on annotations
"clients MUST consider tool annotations to be untrusted unless they come from trusted servers."
Supports: Establishes the trust model: MCP tool annotations (including the description field) are untrusted by default unless originating from a verified server. This is the protocol-level justification for validating descriptions before they enter the agent's tool catalog rather than treating them as authoritative.
Does not prove: The MUST-be-untrusted instruction applies to annotations specifically. The description field is listed separately as "Human-readable description of functionality" without a parallel MUST-validate instruction; Helmwart extends the same logic to the description field.
Anthropic API — Define Tools (Tool Use)
§Specifying client tools — Tool use system prompt
"When you call the Claude API with the tools parameter, the API constructs a special system prompt from the tool definitions, tool configuration, and any user-specified system prompt."
Supports: Confirms that tool descriptions are concatenated directly into the system prompt at API call time. This is the mechanism by which a malicious or overly broad description becomes an injection vector into the model's reasoning context — making description validation before catalog activation a direct prompt-injection mitigation.
Does not prove: The Anthropic documentation describes the description field from a capability angle ("A detailed plaintext description of what the tool does, when it should be used, and how it behaves") and does not warn about adversarial descriptions or recommend pre-validation of third-party tool descriptions.
MITRE ATLAS — AML.M0028 AI Agent Tools Permissions Configuration
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Establishes least-privilege tool permissions configuration as the authoritative MITRE mitigation for controlling what tools an agent may access and how. Description validation sits upstream of permissions enforcement — a tool whose description claims capabilities beyond its actual permissions should be caught at registration.
Does not prove: ATLAS M0028 focuses on permissions/scopes, not on the content of tool description strings. The connection to description-string validation is Helmwart's derived mapping; M0028 does not name description-length bounds or pattern checks.
MITRE ATLAS — AML.M0033 Input and Output Validation for AI Agent Components
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Defines input and output validation as a baseline control for AI agent components. A tool manifest arriving from an external registry is an input to the agent component; applying M0033's validation principle at the catalog-load seam is the natural instantiation of this control for the description field.
Does not prove: M0033 is a general input/output validation control and does not specify tool descriptions, catalog loading, or schema-bound length/pattern enforcement. Public ATLAS pages were unavailable for verbatim excerpt at cross-check date.