What it does: All inter-agent communication is encrypted in transit using TLS 1.2 or later. Passive eavesdroppers who can read network traffic see only ciphertext. Transport-level tampering is also detected (TLS includes a MAC on each record).
Mutual TLS vs. one-way TLS: One-way TLS (the default in most HTTPS) authenticates the server to the client. Mutual TLS (mTLS) authenticates both sides — the server verifies the client certificate as well. For inter-agent communication, mTLS is strongly preferred because it provides both encryption (MIT03) and identity authentication (MIT01) in a single mechanism.
The "internal network" correction: TLS is often omitted on internal channels with the reasoning that the internal network is trusted. This assumption is incorrect in cloud environments where internal network segments may be shared with other tenants or accessible to compromised internal services. The rule should be: TLS everywhere, regardless of network topology.
Threat closed: Type 5 (eavesdropping). Also provides transport-level integrity that limits Type 2 (tampering) to attackers who can terminate the TLS connection, not merely observe network traffic.
What it does: Every inter-agent message is validated against a strict schema before the receiving agent acts on it. Validation includes: message structure (required fields present, no unexpected fields), field types and value ranges, action names (whitelist of valid operations), and parameter values (within expected bounds).
Defense in depth against forgery and injection: Even if an attacker successfully forges a message that passes authentication checks (e.g., because a legitimate agent was compromised and is now sending attacker-controlled content), schema validation limits the damage by rejecting instructions that fall outside the expected operation set. An agent that validates input cannot be instructed to run arbitrary actions that weren't anticipated in its schema.
Example validation check: A deployment agent's schema says the "target" field must be one of ["staging", "canary", "dev"]. A tampered message that sets "target": "production" is rejected before it reaches the deployment logic — even if the message passed signature verification.
Ask your team: when agents pass instructions between each other, are those messages checked for tampering — or just assumed to be intact? Ask whether a message that had its destination or action changed in transit would still be accepted and acted on.