EVIDENCE TRAIL
Inter-agent message signing
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. OWASP Top 10 Agentic 2026 §ASI07 names "digitally sign messages" as Mitigation 2 verbatim. OWASP Threats & Mitigations v1.1 names "cryptographic message authentication" as the primary T12 countermeasure, and NIST SP 800-207 Tenet 2 establishes the zero-trust principle that every inter-agent exchange must provide source authentication and integrity protection regardless of network location.
Last cross-checked against upstream sources: · 8 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Top 10 for Agentic Applications 2026
§ASI07 Insecure Inter-Agent Communication — Prevention and Mitigation Guidelines, item 2
"Message integrity and semantic protection: Digitally sign messages, hash both payload and context, and validate for hidden or modified natural-language instructions."
Supports: Direct mandate to digitally sign every inter-agent message and hash both payload and context — the core mechanism this control implements. Published in the primary agentic-AI risk catalogue.
Does not prove: Does not specify the signing algorithm or key-management scheme. The mandate is architecture-level; JWS/COSE/SPIFFE are not named here.
OWASP Top 10 for Agentic Applications 2026
§ASI04 Supply Chain Compromise — Prevention and Mitigation Guidelines, item 5 "Inter-agent security"
"Inter-agent security: Enforce mutual auth and attestation via PKI and mTLS; no open registration; sign and verify all inter-agent messages."
Supports: Verbatim instruction to "sign and verify all inter-agent messages" in a second, independent ASI entry. The repetition across ASI04 and ASI07 confirms the control is cross-cutting, not scoped to one threat scenario.
Does not prove: Framed within a supply-chain mitigation section; the signing rationale here is provenance of components rather than runtime message integrity. Adjacent rationale, not identical.
OWASP Agentic AI — Threats & Mitigations v1.1
§Agentic Threat Taxonomy Navigator — T12 Agent Communication Poisoning, Mitigation column
"Deploy cryptographic message authentication, enforce communication validation policies, and monitor inter-agent interactions for anomalies. Require multi-agent consensus verification for mission-critical decision-making processes."
Supports: Establishes "cryptographic message authentication" as the primary listed countermeasure for T12 Agent Communication Poisoning — the highest-priority threat this control addresses (severityReductionSteps: 2).
Does not prove: The phrase "cryptographic message authentication" is broad — it covers HMAC MACs as well as asymmetric signatures. The taxonomy does not require asymmetric signing specifically, or bind signing to the originating agent identity.
OWASP Agentic AI — Threats & Mitigations v1.1
§Agentic Threat Taxonomy Navigator — T16 Insecure Inter-Agent Protocol Abuse, Mitigation column
"To defend against inter-agent protocol abuse, enforce strong authentication between agents. Sanitize and validate all protocol-level data, including context payloads and tool metadata, to prevent injection or misinterpretation. … Encrypt communications to avoid adversary-in-the-middle attacks."
Supports: Names strong agent-to-agent authentication and encrypted communications as the structural defences for T16 — the MCP-response-injection scenario this control partially mitigates.
Does not prove: Does not use the word "signing" or name JWS/COSE. The guidance prioritises encryption and authentication but does not distinguish transport-level (mTLS) from payload-level signing.
OWASP Agentic AI Mitigation Playbook P6 — Securing Multi-Agent Communication
§Playbook 6 Securing Multi-Agent Communication & Trust Mechanisms — Step 1: Secure AI-to-AI Communication Channels (Proactive), first bullet
"Require message authentication & encryption for all inter-agent communications, including propagating messages within MAS."
Supports: Operationalises the T12/T14 mitigations into a concrete proactive step: require message authentication on every inter-agent edge, including messages propagated between agents in a multi-agent system (MAS). This is the playbook-level mandate that Helmwart's control directly implements.
Does not prove: Playbook 6 mitigates Agent Communication Poisoning and Human Attacks on Multi-Agent Systems; it does not cover T30 Insecure A2A Protocol Abuse or T37 cross-chain relay. Those are separate entries not referenced in this playbook.
NIST SP 800-207 — Zero Trust Architecture
§2.1 Tenets of Zero Trust — Tenet 2
"All communication is secured regardless of network location. Network location alone does not imply trust. … All communication should be done in the most secure manner available, protect confidentiality and integrity, and provide source authentication."
Supports: Establishes the zero-trust principle that underpins message signing: inter-agent communication is not trusted by virtue of network position; every exchange must provide source authentication and integrity protection. This is the foundational policy requirement that signing satisfies.
Does not prove: NIST SP 800-207 predates modern agentic AI deployments and does not address agent-to-agent communication protocols (MCP, A2A) or SPIFFE/Sigstore signing specifically. The tenet is technology-agnostic.
RFC 7515 — JSON Web Signature (JWS)
Abstract
"JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification."
Supports: Defines the IETF standard for the primary signing primitive recommended for compact text payloads in this control. JWS Compact Serialisation is the format used by SPIFFE JWT-SVIDs. Provides the interoperability foundation — any compliant library on either side of an agent edge can verify a JWS-signed message.
Does not prove: RFC 7515 is a general-purpose signing specification, not an agentic-AI security document. It does not specify trust models, key-distribution mechanisms, or how signing keys should be bound to agent identities.
RFC 9421 — HTTP Message Signatures
Abstract
"This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier."
Supports: Directly relevant to MCP and A2A, both of which operate over HTTP. RFC 9421 solves the intermediary-hop problem that TLS alone cannot: a signature applied at the origin agent survives forwarding through intermediate agents and can be verified at the final receiver. This is precisely the threat model for multi-hop agentic pipelines.
Does not prove: RFC 9421 is not specific to agentic AI. Adoption in MCP and A2A SDKs is not yet native — implementors must wire it in manually at the application layer.