What it does: Every agent must cryptographically prove its identity before another agent processes its messages. Instead of trusting a "role": "orchestrator" field in a JSON body, the receiving agent verifies a credential — a client certificate, a signed JWT, or an API key bound to a specific agent identity in the registry.
Implementation options:
Threat closed: Type 1 (forgery), Type 3 (orchestrator impersonation), Type 6 (queue injection) — all of which require the attacker to claim an identity they do not possess.
What it does: The sending agent signs the message body with its private key. The receiving agent verifies the signature before processing. If any byte of the message body was changed in transit, the signature verification fails and the message is rejected.
Why this is separate from MIT01: Authentication (MIT01) proves the message came from a specific agent at connection time. Signing (MIT02) proves the message content is unchanged — binding the exact content to the sender's identity. A message can be authenticated but still tampered with in transit (by a man-in-the-middle who has channel access) unless the content itself is signed.
Practical implementation: JSON Web Signatures (JWS) or HMAC-based message authentication codes on the message body. The signature covers a canonical serialization of the message content so that field ordering doesn't affect verification.
Threat closed: Type 2 (tampering in transit) — the primary type that MIT01 alone does not address.
Ask your team: when one AI agent sends instructions to another, does the receiving agent verify who sent it — or does it accept any message that arrives? Ask whether an attacker who gets access to your network could send fake instructions to your agents and have them acted on.