MITIGATION · m-message-signing
Inter-agent message signing — end-to-end integrity for A2A and MCP
An inter-agent message travels through channels and intermediate agents the receiver did not originate. If nothing binds the message cryptographically to its source, any intermediate hop can substitute or inject content that the receiving agent will treat as authoritative. Message signing closes that gap: the source agent signs each message payload with its private key, and the receiver verifies the signature against a distributed trust bundle before the content reaches the reasoning layer.
At a glance
TL;DR
- Each inter-agent message is signed by the source agent with its private key and verified by the receiver against a distributed trust bundle before the payload reaches the reasoning layer. Any modification in transit produces a signature mismatch and the message is rejected.
- mTLS proves the transport channel is authentic; it does not prove content integrity across intermediate forwarding hops. Payload-level signing covers the full forwarding path, including through orchestrating agents that relay the message onward.
- Neither MCP (which uses OAuth 2.1 bearer tokens at the transport layer) nor Google A2A mandates payload-level signing in current specifications. Both delegate signing to integrators, making application-layer signing the current gap this control closes.
- Four production-canonical primitives cover the main deployment contexts: RFC 7515 JWS for compact text payloads, RFC 9052 COSE for binary payloads, SPIFFE JWT-SVID when SPIRE manages workload identity, and RFC 9421 HTTP Message Signatures when messages traverse proxies that rewrite headers.
How it behaves
What it is
An inter-agent message is a unit of content that an agent produces and one or more peers consume. In a multi-agent system, that message may pass through a routing layer, an intermediate orchestrating agent, or a protocol gateway before it reaches the agent that acts on it. Nothing in the forwarding path guarantees that the content the receiver sees is what the source produced. An attacker who can influence any intermediate hop, or who can inject into the channel, can substitute content that the receiving agent will treat as a legitimate instruction.
Message signing addresses this by binding the payload cryptographically to the originating agent's identity. The source agent signs the message with its private key before sending. The receiver verifies the signature against a distributed trust bundle before the payload reaches the reasoning layer. Any modification in transit, whether by a man-in-the-middle, a compromised intermediate agent, or a protocol-level injection, produces a signature mismatch and the message is rejected.
The signing primitive is independent of the transport layer. mTLS proves the transport channel is authentic; it does not prove the content is authentic after the message leaves that channel and is forwarded by an intermediate agent. Payload-level signing provides that guarantee across the full forwarding path, including through every intermediate hop. Four production-canonical standards cover the main deployment contexts: RFC 7515 JWS for compact text payloads, RFC 9052 COSE for binary payloads, SPIFFE JWT-SVID when workload identity is already managed by SPIRE, and RFC 9421 HTTP Message Signatures when messages traverse HTTP proxies that may rewrite headers.
Neither MCP (which uses OAuth 2.1 bearer tokens at the transport layer) nor the Google A2A protocol mandates payload-level signing in current specifications. Both delegate signing to integrators, making application-layer signing the gap this control closes.
Detection signals
- Signature-verification failure rate per peer edge. A spike indicates tampering, a key rotation that was not propagated, or an attacker probing the channel.
- Clock-skew rejections. Rejections that exceed the configured validity window are a replay-attack signal; a sudden rise on a specific edge warrants investigation.
Threats it covers
-
WHY IT HELPS Identity spoofing relies on a receiver having no way to verify that a message genuinely came from the claimed peer. Signing binds each message to the signing key of the originating agent, so a peer cannot impersonate a trusted agent without possessing its private key.
-
WHY IT HELPS Agent Communication Poisoning depends on an attacker being able to introduce or modify messages in the inter-agent channel without detection. A tampered message fails signature verification at the receiver and is rejected before it reaches the reasoning layer.
-
WHY IT HELPS Coordinated privilege escalation through multi-agent impersonation requires fabricating messages that appear to come from a trusted principal. When every inter-agent message carries a signature bound to the originating agent's key, fabrication requires key compromise, which is detectable through trust-bundle and certificate-rotation monitoring.
-
WHY IT HELPS Insecure Inter-Agent Protocol Abuse includes an MCP-response-injection path in which a malicious MCP response is passed to the agent as if it were a legitimate server reply. Payload-level signatures on MCP messages make injected responses verifiably invalid.
-
WHY IT HELPS Insecure A2A protocol abuse depends on injecting or substituting messages inside the A2A channel without the receiver detecting it. Signing every A2A message to the originating agent's key means a tampered or injected message fails verification before it can influence the receiver's reasoning.
-
WHY IT HELPS Cross-chain bridge relay messages signed by the originating agent cannot be substituted in transit by a relay-layer attacker, because the receiving chain validates the signature before accepting the cross-chain instruction.
-
WHY IT HELPS Cross-client interference via shared MCP server is partially mitigated when client requests carry per-client signatures. A message relayed from one client session cannot be attributed to another without possession of the originating client's signing key.
Principle coverage
Defence-in-Depth stage: Prevent — and it advances:
- Zero Trust Zero Trust holds that no identity is inherently trusted. Message signing enforces that principle at the content layer: a valid transport channel does not grant trust to the payload it carried; the receiver requires a cryptographic signature bound to the originating agent's key before the message is admitted to the reasoning layer.
- Agent-as-principal Identity Agent identity requires that each workload be cryptographically distinguishable and that its credentials cannot be forged. Message signing extends that requirement from connection establishment to every message in flight: the signature binds each payload to the producing agent's key, so the receiving agent can verify both who sent the message and that no intermediary altered it.
Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.
Implementation options
Four production-canonical signing primitives, each suited to a different deployment context. Choose by what is already deployed: JWT-SVID when SPIRE manages workload identity, JWS or COSE for greenfield integrations, HTTP Message Signatures when messages traverse proxies that rewrite headers.
RFC 7515 JWS IETF Proposed Standard. Compact header.payload.signature structure with broad library support across every language runtime. Supports HMAC-SHA256, RS256, ES256, and EdDSA.
Why choose it: Best for text-payload A2A and MCP messages in greenfield deployments without an existing workload-identity infrastructure. Use RS256 or ES256 for asymmetric signing; HMAC-SHA256 is symmetric and requires shared-secret management that does not scale across a multi-agent mesh. Every major language runtime has at least one production-grade JWS library, making integration cost low.
More details:
RFC 9052 COSE IETF Internet Standard STD 96. Binary equivalent of JWS using CBOR serialisation. COSE_Sign1 and COSE_Sign structures map directly to per-agent payloads without base64 overhead.
Why choose it: Best when inter-agent messages are binary-encoded (CBOR, protobuf, or similar) or when base64 overhead is a concern at high message frequency. STD 96 status indicates higher specification stability than RFC 7515. COSE is the native signing format for CBOR-based protocols and is used in FIDO2/WebAuthn, IoT attestation, and the IETF RATS architecture, making it the natural choice when the deployment also involves hardware attestation.
More details:
SPIFFE JWT-SVID Published SPIFFE specification. Restricts JWT to nine algorithm choices. The sub claim is the signing agent's SPIFFE ID; the aud claim is the receiving agent's SPIFFE ID. Verification chains to the SPIRE-distributed trust bundle.
Why choose it: Best when SPIFFE workload identity is already deployed. JWT-SVID is the natural signing format in that context and requires no additional key management infrastructure. The sub and aud claims encode the full agent identity (spiffe://trust-domain/agent-path) and the intended recipient, so the signature validates both content integrity and routing intent. Short-lived SVIDs (default 1 hour) bound the key-compromise blast radius automatically without additional rotation tooling.
More details:
RFC 9421 HTTP Message Signatures IETF Proposed Standard (February 2024). Signs selected HTTP component fields (method, authority, body digest) into a Signature-Base. The signature survives intermediary header mutations.
Why choose it: Best when inter-agent messages traverse HTTP proxies or API gateways that may add, remove, or rewrite headers. JWS payload signing does not protect against header manipulation in transit. RFC 9421 signs a canonicalised Signature-Base derived from the selected component fields, so the signature is stable across intermediary rewrites of non-signed headers. Use when the deployment includes an API gateway between agents.
More details:
Trade-offs
- JWT sign-and-verify is sub-millisecond at typical inter-agent message frequencies. Latency is not a meaningful constraint for any of the four primary options.
- The first integration carries the majority of the setup cost: key management, trust bundle distribution, and rotation procedure. Adding subsequent peers is cheap once the infrastructure is in place. SPIFFE JWT-SVID eliminates most of this cost if SPIRE is already deployed.
- Clock skew between agents breaks signature validity windows. Tune the acceptable window with care: too tight breaks legitimate traffic on normal clock drift, too loose permits replay attacks. Typical production windows are 5 to 10 minutes for agent-to-agent calls; tighten to 1 to 2 minutes where replay risk is high.
- Neither MCP nor Google A2A mandates payload-level signing in current specifications. The signing layer must be added by integrators at the application level.
When NOT to use
- Payload-level signing adds negligible latency for text payloads but becomes an operational burden for very-high-frequency internal bus messages at tens of thousands per second within a single-trust-domain cluster, where the key-distribution and rotation overhead outweighs the marginal security gain over mTLS alone.
- In purely cluster-internal, single-trust-domain deployments where the service mesh already provides mTLS with workload attestation, payload-level signing is often redundant. Document the decision and rely on mesh-level authentication rather than adding application-layer signing.
Limitations
- Signing proves authenticity of origin, not truthfulness of content. A correctly signed message from a compromised agent is verifiably from that agent and still may contain adversarial content. Pair with m-consensus-verify for high-impact decisions.
- Key compromise is catastrophic and silent. Use short-lived tokens (SPIFFE SVIDs default to 1-hour lifetimes) and the SPIRE attestation pipeline so re-issuance requires workload re-attestation rather than a manual rotation.
- Sigstore cosign sign-blob is not practical for per-message signing. The bundle-per-message approach (OIDC token fetch, Fulcio certificate, Rekor inclusion) is impractical at message frequency and is suitable only for batched audit snapshots, not inline inter-agent message flow.
Maturity tier reasoning
- Tier 2 because JWS, COSE, SPIFFE JWT-SVID, and RFC 9421 HTTP Message Signatures are individually production-mature in non-agentic deployments. What keeps the agentic application from Tier 1 is the absence of a settled inter-agent protocol standard that mandates signing: MCP and A2A are still defining their own approaches.
- Expected to upgrade to Tier 1 once the MCP and A2A signing extensions ship and major agent framework libraries include built-in signing support.
Last verified against upstream docs: 2026-05-30.