"front"	"back"	"tags"
"What is A2A, and how does it relate to B6's inter-agent trust model?"	"A2A (Agent2Agent) is the open wire protocol (JSON-RPC 2.0 over HTTP, optional SSE streaming) for agent-to-agent communication, announced by Google in April 2025. B6 built the inter-agent trust model in the abstract — the message channel as a trust boundary, HMAC-signed messages, replay protection, blast-radius caps — but left the protocol unspecified ('the message channel' was a placeholder). A2A is the concrete protocol that placeholder now names. Every B6 attack (trust escalation, cascade, replay) now targets a concrete A2A artifact: the forged orchestrator message is a forged message/send JSON-RPC call; the unauthenticated peer is an unverified Agent Card; the replay is a captured tasks/pushNotification/set."	c2b::sddb13::recall
"What is the load-bearing distinction about A2A's security posture?"	"A2A is a TRANSPORT AND COORDINATION protocol, not a security protocol. It defines HOW agents talk; it does not by itself guarantee WHO is talking, whether the message is INTACT, or whether the message is FRESH. The authentication of the caller, integrity of the JSON-RPC payload, freshness of the request, and authorization of the delegated action are the IMPLEMENTER's responsibility, layered on top. The Agent Card's `authentication` field declares what scheme the agent expects (OAuth2, API key, mTLS); it does not perform the authentication. The places implementers skimp — payload signing, delegation-depth limits, Agent Card integrity, push-notification endpoint auth — are exactly where the attacker enters."	c2b::sddb13::analysis
"What are the four core A2A protocol artifacts, and how does the attacker read each?"	"(1) AGENT CARD — JSON at /.well-known/agent.json; to the attacker, PUBLISHED RECONNAISSANCE: skills[] = capability surface, url = attack endpoint, authentication = which scheme is absent. Substitutable via DNS/server compromise. (2) TASK — stateful work object with lifecycle states; a HIJACKABLE STATE MACHINE: cancel = DoS, input-required = any caller steers, pollable = data disclosure. (3) MESSAGE — role + parts[]; an UNVALIDATED CONTENT CARRIER (no 'data, not instruction' syntax in natural language). (4) ARTIFACT — structured output; a MULTI-HOP INJECTION VEHICLE (signature proves immediate sender, not taint source). The JSON-RPC methods (message/send, tasks/get, tasks/cancel, tasks/pushNotification/set) are the attack endpoints the Agent Card advertised."	c2b::sddb13::analysis
"What is the Agent Card integrity problem, and what is the fix?"	"The Agent Card is fetched over HTTPS, which guarantees TRANSPORT integrity — integrity between the TLS endpoints, not between the application endpoints. If an attacker compromises the originating server, the DNS, or (in some client libraries) a caching layer, they substitute a malicious Agent Card whose `url` points to the attacker. The orchestrator, believing it is talking to the legitimate agent, dispatches to the attacker — the A2A equivalent of a DNS rebind. This works because most client libraries trust the `url` field without independently verifying it. FIXES: sign the Agent Card with the agent's long-term key or a trusted registry; allowlist the `url` at the orchestrator; obtain cards from a registry, not by bare fetch."	c2b::sddb13::application
"Describe the push-notification hijack attack and its fixes."	"SETUP: `tasks/pushNotification/set` lets a caller register a webhook for asynchronous task updates; the agent POSTs results to the webhook when the task completes. ATTACK: if task IDs are enumerable (sequential, timestamp-derived) and registration is not bound to the original caller, the attacker re-registers the webhook to their own URL for the victim's task. The agent sends the completed results to attacker.com/exfil; the victim never receives them. This is DATA EXFILTRATION AT PROTOCOL GRANULARITY — the attacker never touches the task's content, only redirects where its results are delivered. FIXES: (1) random 128-bit task IDs (no enumeration), (2) caller-bound registration (only original caller can set a webhook), (3) webhook URL allowlist, (4) signed challenge the victim verifies, (5) nonce + timestamp on the registration call."	c2b::sddb13::analysis
"What is delegation-chain over-propagation, and what is the fix?"	"OVER-PROPAGATION: the orchestrator passes its FULL credential to the research agent (because it is easier than minting a downscoped one), the research agent passes it to the search agent, the search agent is compromised — the search agent now holds the orchestrator's full credential and can call ANY A2A agent the orchestrator could, not just the search it was asked to perform. This is A-S-I-zero-three excessive agency and B6 trust-escalation operating across a delegation chain. FIX: CAPABILITY TOKENS (Macaroons, Sparkle delegation tokens, custom JWTs) — each hop mints a strictly weaker token: method=message/send, Task=T1, depth=N. The token attenuates at each hop. The leaf's token authorizes only what the chain explicitly permitted; the leaf's compromise cannot exceed the task it was minted for."	c2b::sddb13::analysis
"What are the four core A2A threats, and how does each map to its B6 control and A2A-specific fix?"	"(1) IMPERSONATION — target: Agent Card (substituted/forged) + stolen credential; B6: assumed you knew who you talked to; A2A fix: sign the card, url allowlist, audience-bound tokens (aud checked). (2) TASK HIJACKING — target: Task lifecycle (cancel, input, races); B6: did NOT address task state machines (NEW surface); A2A fix: caller-bound authz on state-mutating calls, random task IDs, transition proofs. (3) TAMPERING — target: JSON-RPC payload at proxy/middleware/MITM; B6: HMAC/asymmetric signatures; A2A fix: application-layer signatures over canonical-JSON body, verified after TLS termination. (4) REPLAY — target: captured message/send or webhook registration; B6: nonces + timestamps + freshness window; A2A fix: nonce + timestamp in the JSON-RPC envelope, recipient rejects stale/seen-nonce. B6 named the attacks; A2A names the artifacts; every fix is B5/B6 applied at the boundary."	c2b::sddb13::analysis
"What is the precise relationship between MCP and A2A, and why is the boundary an attack surface?"	"MCP is agent-to-tool; A2A is agent-to-agent. They are COMPLEMENTARY, not competing — they compose in a real system: an agent uses MCP to call a tool (database, API, filesystem) and A2A to call another agent. The boundary is an attack surface because an agent registered as an MCP 'tool' (a remote agent behind an MCP interface) inherits MCP's WEAKER trust model (in-process, framework-level, shared-runtime assumptions) while exercising A2A's RICHER capability surface. The discipline: identify in the agent SBOM (SDD-B07) which 'tools' are actually remote agents, and apply A2A-grade authorization regardless of the registration protocol. MCP's in-process trust assumptions do not survive a network boundary."	c2b::sddb13::analysis
"Why is 'we use HTTPS, so the messages are authentic' an anti-pattern, and what is the cure?"	"Transport security (HTTPS) guarantees integrity between the TLS ENDPOINTS, not between the APPLICATION endpoints. If the agent terminates TLS at a load balancer and processes the JSON-RPC internally over an unauthenticated bus, or a middleware (logging proxy) rewrites the payload, the integrity the protocol seemed to guarantee is gone. 'We have TLS' feels sufficient, which is exactly why most A2A implementations omit payload signing. CURE: application-layer payload signatures — HMAC or asymmetric signatures over the canonical-JSON-serialized JSON-RPC body — verified at the receiving agent's application layer, with canonical serialization to prevent signature-valid-but-semantically-different attacks."	c2b::sddb13::application
"Why are enumerable Task IDs an anti-pattern, and what is the cure?"	"Sequential or timestamp-derived Task IDs let an attacker poll `tasks/get` across a range and read every Task's Messages and Artifacts — DATA DISCLOSURE at protocol granularity. An attacker enumerates T1, T2, T3, ... and reads the content of every task on the agent. This is especially damaging because Artifacts often contain sensitive structured outputs the original caller expected to be private. CURE: cryptographically random Task IDs (128 bits minimum, so enumeration is infeasible) AND caller-bound authorization on every `tasks/get` so only the task's original caller (or an explicitly delegated reader) can retrieve its state."	c2b::sddb13::application
"Compare the four multi-agent orchestration topologies for cascade blast radius."	"(1) ORCHESTRATOR-WORKER — bounded to the compromised worker's scope, UNLESS the orchestrator passed its full credential to each worker (over-propagation). Orchestrator compromise = entire mesh lost. (2) PEER-TO-PEER (mesh) — WORST blast radius: every peer is a trust boundary for every other; a compromise of any node propagates to every peer through successive A2A calls. B6's mesh-wide warning was written for this. (3) HIERARCHICAL — depth-dependent: a compromised leaf is bounded to its branch; a compromised mid-level supervisor affects its entire subtree; a compromised root is everything. (4) MARKET-BASED (auction) — the SELECTION of the winning bidder is the attack surface: spoofed bids, manipulated selection, undercut legitimate bidders. Fix: bidder auth, signed bids, selection audit."	c2b::sddb13::analysis
"What is the input-required trap, and how does it realize B6's trust-escalation attack in A2A?"	"When a Task enters `input-required`, the agent is asking for more information. The protocol allows ANY caller to respond — and if the caller is not re-authenticated against the task's original principal, an attacker supplies the 'additional input' and steers the task. The input is incorporated; the task proceeds under the original caller's authority. This is the A2A form of B6's trust-escalation attack: a low-privilege attacker injects content into a high-privilege task without ever holding the original caller's credential. FIX: caller-bound authorization on input-required responses — only the task's original caller (or an explicitly delegated agent) may supply input, and every input-submission must be re-authorized against the task's principal, not just the sender's role."	c2b::sddb13::application
"Why does an A2A message signature prove the immediate sender but not the taint source, and what is the implication?"	"B6's signature control proves WHO sent a message — the immediate sender. In a multi-hop A2A chain (orchestrator → research → extraction), the extraction agent signs the Artifact; the research agent signs its message to the orchestrator. Both signatures are valid. But neither signature carries the TAINT of the original injection. If the extraction agent was compromised and injected an indirect instruction into its Artifact, that instruction reaches the orchestrator with the research agent's (trusted) signature — not the extraction agent's (compromised) one. Provenance degrades at each hop. IMPLICATION: the B6 signature alone is insufficient for multi-hop chains. The fix is provenance headers that survive forwarding — every A2A message carries a `delegation-chain` listing every agent it passed through, and the recipient re-signs the chain rather than the content alone."	c2b::sddb13::analysis
"What are capability tokens, and how do they bound cascade propagation in A2A?"	"A capability token (Macaroon, Sparkle delegation token, or custom JWT) is a delegation credential that attests: the original principal was Alice; this token authorizes method X on Task Y; it was minted by agent Z at time T; it expires at T+window; it is valid for at most N further delegations. Every hop attenuates the token — the `max-depth` decreases at each hop, the scope narrows. The leaf agent's token, presented to an external tool, authorizes ONLY what the chain explicitly permitted. A leaf agent's token is worthless outside the task it was minted for. This bounds cascade propagation because even a fully-compromised leaf cannot exceed the task's scope. This is B5's scoped credential and B6's blast-radius cap, applied inter-agent — and A2A makes it enforceable because the Task ID is a natural scope boundary."	c2b::sddb13::analysis
"What three disciplines reduce the Agent Card publishing risk without breaking discovery?"	"(1) PUBLISH THE MINIMUM — the Agent Card is a public document. Skill descriptions should be high-level ('summarizes legal documents'), not detailed ('calls the Westlaw API at <endpoint> with <credential-scope>'). The `url` field is necessary; an `internal-endpoints` field is not. (2) SIGN THE AGENT CARD — the card should be signed by the agent's long-term key or by a trusted registry. The signature lets a caller detect substitution. Without it, a DNS-spoofed or server-compromised card substitution is invisible. (3) TREAT THE SKILLS ARRAY AS CONTENT YOU ARE RESPONSIBLE FOR — skill descriptions are natural-language strings; if an orchestrator concatenates them into a routing prompt (common in early A2A implementations), a malicious skill description is a PROMPT INJECTION delivered through your card into their orchestrator. Write skill descriptions that are inert when concatenated — no imperative verbs, no instructions, just capability names."	c2b::sddb13::application
"How does the migration from Crew-style in-process delegation to A2A-across-network change the trust posture?"	"Crew (and similar frameworks) define inter-agent communication in code — a Crew of Agents with explicit task assignments and delegation rules. It is a FRAMEWORK-LEVEL protocol, not a WIRE protocol: it assumes the agents are co-deployed and share a runtime. Crew's in-process delegation has NO network attack surface — the delegations are function calls within a process. The moment the same delegation crosses an A2A boundary, EVERY attack in this deep-dive applies: the function-call argument becomes a JSON-RPC payload (tampering target), the in-process trust becomes network trust (impersonation target), the shared runtime assumption becomes a distributed-system assumption (replay target). The migration from Crew-in-process to A2A-across-network is a TRUST-POSTURE DOWNGRADE that teams often miss because the framework abstractions look identical. The discipline: when you move any Crew delegation across a network, re-evaluate every trust assumption the in-process model made for free."	c2b::sddb13::analysis
"What is an audience-bound token, and why does it matter in A2A?"	"An audience-bound token is an OAuth2/JWT whose `aud` (audience) claim identifies the SPECIFIC agent the token was minted for. A2A's authentication gap #1: many agents verify that a token is valid and issued by the expected authority but do NOT verify that the token was minted for THIS agent. A token stolen from a different A2A consumer, or a token leaked into a log, is accepted. This enables cross-agent token replay — an attacker who steals a token from agent A uses it to authenticate to agent B, which trusts the issuer but never checked the audience. FIX: every A2A agent MUST check the `aud` claim against its own identifier and reject any token whose audience does not match. This is B5's scoped-credential model applied at the inter-agent boundary."	c2b::sddb13::application
"Why is the market-based (auction) topology's cascade risk different from the others, and what is the fix?"	"In orchestrator-worker, peer-to-peer, and hierarchical topologies, the cascade risk is about AUTHORITY PROPAGATION — how far a compromised agent's credential travels. In market-based (auction / contract-net), the cascade risk is about SELECTION INTEGRITY — the attacker does not need to compromise a node; they need to win the bid. An attacker who can spoof bids (impersonation), manipulate the selection criteria (injecting content into the announcing agent's evaluation prompt), or undercut legitimate bidders wins tasks they should not and then executes them with the announcing agent's trust. The selection step itself is the attack surface. FIX: bidder authentication (signed bids proving identity), bid integrity (signatures over bid content), and selection-process transparency (the announcing agent logs WHY it chose the winner, for audit)."	c2b::sddb13::analysis
"Why is A2A's `authentication` field in the Agent Card declarative and not verified, and what is the implication?"	"The Agent Card's `authentication` field declares which scheme the agent EXPECTS (OAuth2, API key, mTLS). Nothing in the protocol verifies that the agent ACTUALLY ENFORCES the scheme it declares. An attacker who publishes a malicious Agent Card can declare `authentication: { schemes: ['OAuth2'] }` and then accept whatever credential is offered — or none at all. The caller, reading the card, believes it knows the trust posture ('this agent requires OAuth2, so it is well-protected'); the card is a CLAIM, not a guarantee. IMPLICATION: the declarative field is reconnaissance for the attacker (it tells them which scheme to attack) AND a false-assurance trap for the caller (it suggests a posture that may not hold). FIX: obtain Agent Cards from a trusted registry that verifies enforcement, or verify the card's signature against the agent's long-term key, and independently test that the agent rejects unauthenticated calls."	c2b::sddb13::analysis
"What is lost provenance in a delegation chain, and why is it dangerous?"	"In a three-hop A2A chain (orchestrator → research → extraction), the extraction agent returns an Artifact to the research agent, who folds it into its response, who summarizes it to the orchestrator. At each hop, the PROVENANCE — where did this content come from? — degrades. By the time the content reaches the orchestrator, it has been processed by two intermediate agents and its origin is opaque. An attacker who compromises the extraction agent injects content that reaches the orchestrator with the RESEARCH agent's (trusted) signature, not the extraction agent's (compromised) one. The B6 signature control proves the immediate sender; it does not preserve provenance across the chain. DANGEROUS because the orchestrator's trust decision is based on the wrong sender's reputation. FIX: provenance headers that survive forwarding — every A2A message carries a `delegation-chain` field listing every agent it passed through, and the recipient re-signs the chain (not just the content) so the full history is verifiable at every hop."	c2b::sddb13::analysis