"Why is an inter-agent message channel a trust boundary, and how does the blast radius differ from single-agent security?"	"In single-agent security (B2-B5), the trust boundaries are user↔agent and agent↔tool; an injected agent exfiltrates with ITS OWN credentials; blast radius = the agent's task. In a multi-agent mesh, EVERY peer relationship is a trust boundary. An orchestrator delegating to 3 executors runs 3 trust relationships; a supervisor reviewing a sub-agent is a 4th. Each edge is a boundary an attacker can cross by FORGING a message, and each is a channel a compromised agent can use to ESCALATE. Blast radius is MESH-WIDE because the graph is connected and trust is implicit. B1 rated this the worst blast radius on the surface map."	c2b::b6::recall
"Name the three attacks on the inter-agent channel and the canonical reference for each."	"(1) TRUST ESCALATION — a compromised low-trust agent forges an orchestrator message; a high-trust agent executes it (multi-agent confused deputy). Canonical ref: Microsoft Failure Mode Taxonomy v2.0 #3. (2) CASCADE — one poisoned output propagates as downstream agents consume it as fact; fan-out amplifies. Canonical ref: OWASP ASI06 (Cascading Hallucination). (3) REPLAY — a captured, validly-signed message re-injected out of context. Root cause across all three: the recipient trusts the message's 'from' field without cryptographic verification — the channel authenticates nothing."	c2b::b6::recall
"What is Microsoft Failure Mode Taxonomy v2.0 #3 (Inter-Agent Trust Escalation), and why is it the canonical framing?"	"It is the failure where an attacker (or a compromised agent) FORGES a message between agents to ESCALATE PRIVILEGES beyond what the forger is authorized to do. The pattern: a low-trust agent (read-only) is compromised; it forges a message claiming to be from the orchestrator ('approve_deployment'); the high-trust agent trusts the orchestrator (correctly) but cannot verify the sender (incorrectly) and executes. It is canonical because it is EMPIRICAL (drawn from a year of red-teaming real agentic systems) and names the structural cause explicitly: inter-agent messages are trusted based on CONTENT, not authenticated sender identity."	c2b::b6::recall
"Explain the trust-escalation attack as a multi-agent confused deputy. Who is the deputy?"	"The high-trust DEPLOY agent is the confused deputy — it holds production-write authority. The forged orchestrator message is the ABUSE of that authority. The deploy agent cannot distinguish the forgery from a real orchestrator message because the channel does not authenticate senders; the 'from' field is just an unverified field. A READ-ONLY agent has triggered a PRODUCTION WRITE = privilege escalation. This is the SAME confused-deputy pattern as B4's tool security (the tool was the deputy there), except here the deputy is another agent. The fix is the same: authenticate the request, do not trust a self-declared field."	c2b::b6::recall
"What is a replay attack on the inter-agent channel, and why does a signature-only defense fail to prevent it?"	"A replay captures a LEGITIMATE, correctly-signed message and re-injects it LATER, OUT OF CONTEXT. The orchestrator sends approve_deployment for task 42; the deployment runs; the attacker captures the signed message and replays it — the signature VERIFIES (genuinely signed by orchestrator), the content is benign in original context, but the context changed. A SECOND deployment runs, never authorized. Signature-only fails because the message WAS authentic — the problem is it was NOT FRESH. Fix: replay protection (nonce + timestamp window + task binding) — the three together; drop any one and a path opens."	c2b::b6::recall
"State the four properties of the signed-message contract."	"(1) AUTHENTICITY — signed by a key only the claimed sender holds; recipient verifies (HMAC or asymmetric). (2) INTEGRITY — signature covers header + payload; any tampering invalidates it. (3) FRESHNESS — timestamp + nonce; reject outside a freshness window, reject seen nonces. (4) BINDING — task_id in the signed payload; an approval for task 42 cannot replay against task 43. This is the SAME contract TLS, JWT, and mTLS enforce. Novelty is applying it to the inter-agent channel, which most meshes leave entirely unprotected."	c2b::b6::recall
"When do you use HMAC vs asymmetric signatures for inter-agent messages?"	"HMAC (symmetric, shared secret): fast, simple, right when sender and recipient are in ONE trust domain (e.g. orchestrator + in-process executors). This is DD-16 ZeroClaw's model. Limitation: requires a pre-shared secret per pair, does not scale to cross-domain meshes. ASYMMETRIC (Ed25519/ECDSA, public/private): slower but scales to N recipients without N shared secrets, supports non-repudiation; right for cross-domain meshes (orchestrator run by platform team, executor run by product team). RULE: HMAC within a trust domain, asymmetric ACROSS trust domains. Mirrors mTLS precedent (shared CA inside cluster, SPIFFE/SPIRE across clusters — B5)."	c2b::b6::recall
"What is the durable-key gap in DD-16 ZeroClaw, and how does B6 close it?"	"GAP (Course 1): ZeroClaw's HMAC signing keys are EPHEMERAL — in-memory only, not persisted. A message signed in session 1 CANNOT be verified in session 2 (key is gone); a restart invalidates every signature; and a poisoned message persisted to memory (B3 sleeper, ASI04) retrieved later cannot be verified. B6 CLOSES it with DURABLE, ROTATED keys: (1) PERSISTENCE — keys live in the B5 vault (harness accesses, not agent); survive restarts; (2) ROTATION — every 24h + on compromise, old keys retained 7d for verification then destroyed; (3) KEY IDs — key_id header (JWT kid pattern); (4) asymmetric option for cross-domain. Durable keys turn in-session receipts into a defense that survives session boundaries — where the sleeper and cascade operate."	c2b::b6::recall
"List the five gates in the inter-agent message verification flow, and which attack each defeats."	"(1) RECIPIENT (to == me) — misrouting. (2) TASK BINDING (task_id == current task) — cross-task replay. (3) FRESHNESS (abs(now-ts) ≤ window) — stale/old-message replay. (4) NONCE (not in seen-nonce cache) — within-window replay. (5) SIGNATURE (HMAC verifies, key_id known) — forgery / impersonation. Five gates, SERIES, all must pass. Drop any one and a path opens: drop timestamps → replay indefinitely; drop nonces → replay within window; drop task binding → replay across tasks. Same defense-in-depth discipline as B2's five-layer injection defense and B5's scope check."	c2b::b6::recall
"What is compartmentalization in a multi-agent mesh, and where is the boundary enforced?"	"Agents are partitioned into TRUST COMPARTMENTS (low/med/high — e.g. research=read-only, code=staging-write, deploy=prod-write). Levels assigned by ORCHESTRATOR POLICY, not self-declared. Every cross-compartment request is mediated, authorized, and audited by the orchestrator — it does NOT go agent-to-agent. LOAD-BEARING PRINCIPLE: the boundary is enforced in the ORCHESTRATOR (deterministic, auditable), NOT in the agents — because an agent cannot be trusted to enforce its own trust level (a compromised agent claims whatever level gets its message through). Same principle as B4's tool gate and B5's scope check: the deterministic component holds the policy because the model-in-the-loop component can be coerced."	c2b::b6::recall
"Map OWASP ASI06 and ASI07 to the inter-agent channel."	"ASI06 (Cascading Hallucination): one agent's poisoned/hallucinated output consumed as FACT by downstream agents propagates through the mesh; the inter-agent channel is the PROPAGATION MEDIUM. Defense: signed messages + output verification at every edge. ASI07 (Insecure Output Handling): an agent's output consumed by a downstream agent WITHOUT sanitization — peer output treated as a TRUSTED INSTRUCTION rather than UNTRUSTED DATA. The inter-agent analogue of B2's input classification. Pattern across both: peer outputs are trusted by default when they should be treated as untrusted data that is VERIFIED before it is acted on."	c2b::b6::recall
"What are the three blast-radius caps, and why are they 'blunt on purpose'?"	"(1) CASCADE-DEPTH cap — no chain of agent-to-agent delegations longer than N (e.g. 3). (2) FAN-OUT cap — no single agent delegates to more than M peers. (3) SESSION ACTION BUDGET — no more than K state-changing actions per session. They are circuit breakers: when a cascade starts it hits a HARD LIMIT and stops rather than propagating through the entire mesh. They are BLUNT ON PURPOSE because a cascade is, by definition, a propagation you did NOT anticipate — the defense against unanticipated propagation is a structural limit that does not depend on anticipating the specific attack. B8 (observability) detects the cascade; the cap STOPS it."	c2b::b6::recall
"What is session-level intent tracking, and why is it deterministic rather than heuristic?"	"The orchestrator records the AUTHORIZED INTENT of the session at start (e.g. 'research topic X, summarize; do NOT deploy'). Every agent message is checked: does its intent match the session's authorized intent? A research agent emitting 'deploy' intents is OUT OF POLICY regardless of whether its message is signed — the orchestrator rejects it. It is DETERMINISTIC because the policy ('this session's intent is research; deploy intents are denied') is a COMPILED BOOLEAN — the agent cannot talk its way past it. This is the B2.3 resolution (determinism on the trust boundary) applied to the inter-agent channel. Same principle as B5's scope check: model cannot coerce a compiled gate."	c2b::b6::recall
"Why must signing keys live in the vault the harness accesses (B5), not in the agent process?"	"If the agent can READ its own signing key, it can be COERCED into signing arbitrary messages (the confused deputy again — an injected agent signs whatever the attacker directs). This is B5's credential isolation applied to SIGNING KEYS: the harness signs on the agent's behalf; the key lives in the vault; the agent NEVER sees it. The agent cannot forge what it cannot sign. This closes the path where a compromised agent uses its own legitimate signing key to produce validly-signed malicious messages — which would defeat the entire signed-message defense (the signature would verify)."	c2b::b6::analysis
"A signed-message defense omits the task_id binding (the message carries a timestamp + nonce + signature, but no task_id). Describe the replay attack this enables."	"Without task binding, an attacker captures a validly-signed approval message for task 42 (signature valid, timestamp fresh, nonce fresh). They wait until a DIFFERENT task — task 43 — is active, and replay the captured message. The nonce has not been seen in the task-43 session (the nonce cache is per-session or bounded), the timestamp is within the window if replayed quickly, and the signature verifies. The high-trust agent reads 'approve_deployment' and executes for task 43 — an approval for 42 replayed against 43. Task binding closes this: the task_id is IN the signed payload, and the recipient checks it matches the CURRENT task, so the task-42 message is rejected in the task-43 context."	c2b::b6::analysis
"Why does the nonce cache need a TTL equal to (or greater than) the freshness window, and what happens if the TTL is shorter?"	"The nonce cache must track seen nonces for at LEAST as long as a message could be accepted by the freshness check. If the TTL is SHORTER than the freshness window, a nonce expires from the cache while the message is still 'fresh' by timestamp — so an attacker can replay the message after the nonce expires but before the timestamp window closes, and the freshness gate passes while the nonce gate (incorrectly) reports it as unseen. The nonce cache TTL must be ≥ freshness window so that any message the freshness gate would accept has a nonce still in the cache (and thus correctly rejected on replay). Bounded LRU with TTL = freshness window is the standard pattern."	c2b::b6::analysis
"A mesh uses HMAC with ephemeral in-memory keys shared between orchestrator and executors. A B3-style sleeper attack poisons a memory entry in session 1 and retrieves it in session 2. Why does the signed-message defense fail here, and what is the fix?"	"The ephemeral key from session 1 is GONE by session 2 (process restarted, memory cleared). So the signed message persisted with the poisoned memory entry CANNOT be verified — the verify() call fails at the signature/key lookup gate ('unknown key_id: rotated out'). The recipient then either (a) rejects the legitimate-but-old message (availability failure), or (b) more dangerously, the implementation falls back to accepting unverified messages and the sleeper activates. FIX: durable, rotated keys in the B5 vault with key IDs and a verification-retention window (e.g. retain old keys 7 days). Now the session-1 message verifies in session 2 (key is still in the verify window) — and if it was tampered (the poison), the signature INVALIDATES and the recipient correctly rejects it. Durable keys are what make signatures survive the session boundary where the sleeper operates."	c2b::b6::analysis
"Your mesh has an orchestrator run by the platform team and an executor run by a product team. They refuse to share a symmetric secret across team boundaries. What signature scheme do you use, and how is key distribution handled?"	"ASYMMETRIC (Ed25519). Each trust compartment (or each agent/operator) has its own keypair. The orchestrator's compartment signs with its PRIVATE key; the executor verifies with the orchestrator's PUBLIC key. Public keys are distributed OUT-OF-BAND (a key directory, a JWKS endpoint, or a SPIFFE/SPIRE trust bundle — B5's workload identity). No shared secret crosses the team boundary. The signature also provides NON-REPUDIATION (the platform team can prove which key signed a message, useful for audit). This mirrors the mTLS/SPIFFE precedent: service-to-service auth inside a cluster can use a shared CA, but cross-cluster / cross-team needs the PKI model."	c2b::b6::analysis
"Why is a cascade (ASI06) harder to stop than a single hallucination, and why does fan-out make it worse?"	"A single hallucination is a LOCALIZED error the user corrects — it stops at one output. A cascade is a CONTAMINATED REASONING CHAIN: agent A's false output → B treats as fact → C treats as fact ('two sources agree') → action. Each hop ADDS CONFANDE because the output appears to come from multiple sources, and the original error is buried under layers of plausible derivation — by the time the action is taken, the foundation is untraceable. FAN-OUT makes it worse: an orchestrator delegating to 10 executors poisons ALL 10 from one bad output, and peer-to-peer meshes have worse fan-out (each peer reaches every other). Defense is not to catch each cascade (that is B8); it is to PREVENT PROPAGATION (signed messages + output verification) and CAP it (blast-radius limits) so a propagating chain hits a hard limit."	c2b::b6::analysis
"Design the orchestrator's cross-compartment policy check that runs when a low-trust agent's output needs to drive a high-trust agent's action."	"The orchestrator mediates; the request does NOT go agent-to-agent. The check: (1) Is the high-trust task INDEPENDENTLY AUTHORIZED (i.e., the deploy was authorized by a signed orchestrator delegation, not by the research agent's request)? If no → DENY. (2) Is the low-trust agent's output being passed as DATA (a finding, a summary) or as an INSTRUCTION ('deploy now')? It must be DATA — an instruction from a lower-trust principal to a higher-trust one is out of policy. (3) Rate-limit and LOG the crossing — a burst of low→high crossings trips an alert (feeds B8). The crossing is an AUDIT EVENT. The policy is enforced in the orchestrator (deterministic) because the agents can be coerced. Result: a low-trust agent can INFORM a high-trust task but cannot DIRECT it."	c2b::b6::analysis
"Construct the full defense-in-depth stack for the inter-agent channel, in order of enforcement, and which attack each layer defeats."	"(1) SIGNED MESSAGES (HMAC/asymmetric, recipient verifies) → defeats forgery/impersonation. (2) REPLAY PROTECTION (nonces + timestamp window + task binding) → defeats replay of captured messages. (3) COMPARTMENTALIZATION (trust compartments, orchestrator-enforced crossings) → defeats a low-trust agent directing a high-trust agent. (4) SESSION INTENT TRACKING (authorized intent at session start, every message checked) → defeats out-of-policy intents (research agent emitting deploy). (5) PER-ACTION AUTHORIZATION (B5 scope check at moment of action) → defeats privilege creep within a session. (6) BLAST-RADIUS CAPS (cascade depth, fan-out, action budget) → defeats mesh-wide propagation. Each addresses a DIFFERENT failure; a signed+fresh+in-policy message from a compromised high-trust agent is still bounded by layer 6. No single layer closes every path — the channel has more paths than any other surface."	c2b::b6::analysis
"Why is B6 the module where 'the agent is the threat' stops being hypothetical, and how does that change the defensive posture?"	"In B2-B5, the threat model was: an external attacker reaches the agent (via injection/poisoning) and the agent misuses ITS OWN authority. The defensive posture was protect-the-agent. In B6, the threat model is: one agent IN the mesh is compromised and now sits INSIDE the trust fabric — it can forge messages to higher-trust agents, cascade poison through peers, and replay captured approvals. The attacker is the agent itself, from a vantage point inside the mesh. This changes the posture from protect-the-agent to PROTECT-THE-CHANNEL and PROTECT-THE-BOUNDARY: the question is no longer 'can the attacker reach the agent' (B2) but 'can a compromised agent forge a message that makes a HIGHER-trust agent do something it should not.' In most deployed meshes the answer is yes, because messages are unauthenticated. B6's entire job is to make the answer no."	c2b::b6::analysis