Walkthrough: Evaluating the security of the agent-to-agent communication layer.

In the architecture of agentic systems, the communication layer between agents is often treated as an implementation detail, yet it constitutes a critical and expanding attack surface. A common oversight during procurement is evaluating agents as monolithic entities, focusing on input/output security while assuming the inter-agent messaging—whether gRPC, HTTP, or custom protocols—is inherently secure. This walkthrough provides a structured rubric to dissect that specific layer, moving beyond vendor claims of "TLS everywhere" to assess the actual security posture and its operational implications.

The evaluation should be segmented into four primary domains: Transport Security, Authentication & Authorization, Message Integrity & Confidentiality, and Observability & Audit. For each, we must define both technical requirements and vendor demonstration prompts.

### 1. Transport Security
This is the baseline. The requirement must be explicit about versions and configurations.
* **Minimum Rubric Score:**
* TLS 1.2 (with strict cipher suites) or preferably TLS 1.3 mandatory for all inter-agent traffic, including within a host network.
* Certificate management: Support for both public CA and private PKI, with automated rotation.
* No fallback to plaintext or weak protocols.
* **Vendor Demo Checklist:**
* Request a packet capture (or `tcpdump` output) of a live demo, filtered for agent traffic. Verify the protocol.
* Ask to see the configuration where a self-signed or internal CA certificate is provisioned to an agent.
```yaml
# Example: Expected configuration exposure
agent_communication:
tls:
version: "1.3"
cert_path: "/etc/agent/certs/{{ .Env.AGENT_ID }}.crt"
key_path: "/etc/agent/secrets/{{ .Env.AGENT_ID }}.key"
ca_bundle: "/etc/agent/certs/ca.pem"
# Cipher suite specification should be visible
cipher_suites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
```

### 2. Authentication & Authorization
TLS provides server authentication; this layer ensures each agent principal is verified and its actions are constrained.
* **Minimum Rubric Score:**
* Mutual TLS (mTLS) for strong, cryptographically verifiable identity, or a comparable mechanism like SPIFFE/SPIRE.
* A clear, declarative policy model governing which agent can invoke which actions on another agent (e.g., "Agent A can only call the `validate` endpoint on Agent B").
* **Vendor Demo Checklist:**
* Demonstrate a scenario where an agent with invalid or revoked credentials attempts to connect and is rejected at the connection layer, not the application layer.
* Show the policy definition and test a violation: e.g., configure Agent A to be forbidden from calling Agent C's `execute` method, then attempt the call and observe the structured denial.

### 3. Message Integrity & Confidentiality
Even with TLS, messages may be logged or forwarded internally. This assesses end-to-end protection.
* **Minimum Rubric Score:**
* Application-level signing or encryption for high-sensitivity payloads, providing security beyond the transport hop.
* Non-repudiation via per-message signatures tied to the agent's identity.
* **Vendor Demo Checklist:**
* Ask to see the raw body of a message as it appears on the wire *after* TLS decryption. Is sensitive data (PII, keys) still in plaintext, or is it tokenized/encrypted?
* Request a demo of a message replay attack: capture a valid request and replay it. The system should reject it based on a unique message ID or timestamp validation.

### 4. Observability & Audit
Security is not effective if it is not observable.
* **Minimum Rubric Score:**
* All authentication successes/failures, authorization denials, and message validation errors must generate structured, correlated logs.
* Audit trails must cryptographically link actions to specific agent identities, preserving a chain of custody.
* **Vendor Demo Checklist:**
* During a demo, trigger an authorization failure. Immediately inspect the centralized logs (e.g., Elasticsearch, Splunk) to show the generated event includes: timestamp, agent IDs, invoked endpoint, and policy rule that caused denial.
* Request the schema of these audit events to ensure they are sufficient for forensic analysis.

The key during evaluation is to move from specification to demonstration. A vendor's architecture diagram may show all connections as "secure," but the operational burden and residual risk lie in the configurability, default settings, and the granularity of controls provided. This rubric forces a shift from trusting the diagram to verifying the mechanics.