A7 Agent card forgery

The mesh (A5, A6) added a fourth agent that you own. A7 crosses the boundary you don't. In Google's A2A protocol, agents discover each other by fetching an Agent Card a descriptor of who a partner is and what it can do and then delegate work to it. That card crosses an organizational trust boundary, so both its self declared capabilities and its skill text are untrusted until proven otherwise. VulnBank onboards a fraud screening partner exactly this way.

What the buttons do: click VULN and every console below shows the attack succeeding on the vulnerable build; click FIXED and the same consoles show it blocked on the hardened build. It switches in place nothing reloads, so you can flip back and forth and compare the exact same step exploited vs. defended.

the seamBoundary ❾ the org you don't own

Everything up to now happened inside one company's trust domain. Federation moves the boundary outward: you are now trusting an agent that runs on someone else's infrastructure, described by a document they wrote. An Agent Card asserts two separate things who the partner is (identity) and what it can do (capabilities) and A7 attacks the first. If onboarding trusts a card because it merely names a reputable issuer, then naming is all forgery requires.

the payloadName drop an issuer

An attacker publishes a card that merely names a trusted issuer and self grants a db_admin capability. This is a cousin of A4's rogue registry, but the trust anchor is different: not an internal operator token, a cross org signature. On VULN the card is imported verbatim and the "partner" dumps the customer table. On FIXED the card is rejected at the door because it isn't signed by a key we actually hold:

[attacker] federate forged card: ok=True (caps=['account_read','db_admin'])
[FraudCheckPartner] tool run_sql('SELECT * FROM users')
                    -> SQL_RESULT(rows=3): {u1001:{...ssn...}, u2002:{...}, u9999:{...}}

[attacker] federate forged card:
   ok=False (DENIED: agent card for 'FraudCheckPartner' failed signature check)
RESULT: card never onboarded — the partner does not exist in the mesh

the fixVerify the signature, not the name

Identity across an org boundary must be cryptographic. The card is accepted only if it carries a valid signature from an issuer whose key you actually hold knowing the issuer's name proves nothing:

if self.policy.verify_agent_cards:
    if not signature_valid(card, trusted_issuer_keys):
        return Denied(f"agent card for '{card.name}' failed signature check")
# a name is a claim; a signature over a key you hold is proof

threat modelA7, seen from above

deep diveTwo claims in one card and why they need separate proofs

The single most useful idea in the federation layer is that an Agent Card bundles two assertions that demand two different kinds of proof, and treating them as one is the whole bug class:

A7 without A8 is a locked door with the keys taped to the frame: you carefully verify who is knocking, then hand them whatever they say they're allowed to take. The federation boundary is only safe when both proofs are demanded authenticate the identity, then authorize the capability, separately.

in the wildWhere A7's seam lives in real frameworks