R-AC-01 Agent Communication & Interoperability DAMAGE 4.1 / Critical

A2A Agent Card Manipulation

A2A Agent Cards (JSON metadata) for discovery can be manipulated or spoofed, causing delegation to imposters or unauthorized endpoints.

The Risk

Agent-to-Agent (A2A) discovery relies on Agent Cards: JSON metadata describing an agent's capabilities, authentication requirements, endpoints, and schema. When Agent A needs to delegate work to Agent B, it discovers Agent B's card from a registry or directory, validates the card, and constructs an API call.

If an Agent Card is manipulated or spoofed, Agent A may delegate to a fraudulent endpoint, send data to an impostor agent, or invoke unintended operations. A manipulated card might point to an attacker-controlled endpoint instead of the legitimate agent's endpoint, claim capabilities the agent does not have, omit authentication requirements causing Agent A to send unencrypted credentials, or falsify schema information causing Agent A to format requests incorrectly or trigger unintended operations.

The attack surface is the agent registry or discovery mechanism. If the registry is compromised or if agent cards are not cryptographically signed, cards can be manipulated. Even if cards are signed, impersonation is possible if the signing key is stolen or if Agent A does not verify signatures.

How It Materializes

A large financial services firm deploys an A2A ecosystem where agents discover and delegate to each other via a central Agent Registry. A payment processing workflow requires several agents: Payment-Intake accepts customer payment requests, AML-Screener screens beneficiaries against sanctions lists, Payment-Router routes transactions through the bank's payment processor, and Compliance-Monitor logs the transaction for audit.

Payment-Intake agent needs to delegate to AML-Screener. It queries the Agent Registry for available "AML Screening" agents. The registry returns a card for "AML-Screener-Prod" with endpoint "https://aml.internal.bank.com/v1" and required authentication "Bearer Token XYZ123".

However, an internal threat actor has compromised the Agent Registry database and modified the AML-Screener card. The card now points to an attacker-controlled server and removes the authentication requirement. The attacker has also modified the card's schema to include an additional field: "save_credentials: true".

Payment-Intake reads the manipulated card and delegates beneficiary screening requests to the attacker's endpoint. The attacker's endpoint returns a fabricated "approved" response (claims all beneficiaries are clean). Over 3 days, Payment-Intake delegates 450 transactions to the attacker's server. The attacker captures beneficiary names, payment amounts, and originating customer information.

When the bank discovers the compromise, it finds that 450 transactions were routed to an external endpoint. The card manipulations were not signed or authenticated; they were simple JSON modifications in the database.

DAMAGE Score Breakdown

Dimension Score Rationale
D - Detectability 3 Delegation to fraudulent endpoints may go undetected if responses appear legitimate. But statistical anomalies (all approvals, unusual endpoint response patterns) can trigger detection.
A - Autonomy Sensitivity 4 High when agents autonomously discover and delegate. Agents do not verify card authenticity before use.
M - Multiplicative Potential 5 Every agent that consumes the manipulated card is affected. Poison spreads to all agents that delegate.
A - Attack Surface 4 Agent Registry and card storage are attack surfaces. Cards in transit and at rest must be protected.
G - Governance Gap 4 Institutions often do not require cryptographic signing or verification of agent cards. Trust is implicit.
E - Enterprise Impact 5 Enables data exfiltration, fraud, and lateral movement. Full impact depends on what data is sent to the fraudulent endpoint.
Composite DAMAGE Score 4.1 Critical. Requires immediate architectural controls. Cannot be accepted.

Agent Impact Profile

How severity changes across the agent architecture spectrum.

Agent Type Impact How This Risk Manifests
Digital Assistant Low Human verifies agent discovery and approves delegation before proceeding.
Digital Apprentice Low-Med Agents are conservative about discovery and escalate when card authenticity is uncertain.
Autonomous Agent High Agents autonomously discover and delegate based on cards without human verification.
Delegating Agent High Delegating agent discovers tools and endpoints via card metadata. Manipulated cards cause delegation to fraudulent tools.
Agent Crew / Pipeline Med-High Crew agents may discover and communicate with other crew members via cards. Manipulated cards fragment crew.
Agent Mesh / Swarm Very High Mesh agents heavily rely on discovery for peer-to-peer coordination. Card manipulation enables massive impersonation attacks.

Regulatory Framework Mapping

Framework Coverage Citation What It Addresses What It Misses
NIST AI RMF 1.0 Partial GOVERN 6.2, MAP 5.1 Risk documentation and communication. Agent identity verification and card authentication.
NIST CSF 2.0 Partial ID.AM-1, PR.AU-2 Asset identification and authorization controls. A2A card authentication and integrity.
EU AI Act Minimal Articles 10, 26 Documentation and human oversight. Agent discovery and card integrity.
MAS AIRG Minimal Third-Party Risk Third-party risk management. Agent registry security and card integrity.
Zero Trust (NIST SP 800-207) Partial Identity Verification, Least Privilege Never trust, always verify. Application to agent identity and discovery.

Why This Matters in Regulated Industries

In finance, agent interactions must be auditable and verifiable. If agents delegate to fraudulent endpoints without verification, the institution has lost control of its delegation decisions. Regulators will ask: "How do you know the agent you delegated to is the agent you intended to delegate to?"

Agent card manipulation is particularly dangerous because it is invisible to humans. The human operator sees Payment-Intake delegating to "AML-Screener" (as reported in the card name), but the actual endpoint is fraudulent. The audit trail shows the agent name, not the endpoint, creating a compliance illusion.

Controls & Mitigations

Design-Time Controls

  • Implement cryptographic signing of all agent cards. Cards must be signed by a certificate authority (CA) that the discovering agent trusts. Use Component 2 (Cryptographic Identity) to establish agent identity and sign cards.
  • Establish an agent registry with access controls. Only authorized agents or operators can publish or modify cards. Registry must support version control and audit logging of all card changes.
  • Require agents to verify card signatures before using them. Implement a validation function that checks card signature, verifies issuer identity, and validates certificate chain before delegation.
  • Use Component 3 (JIT Authorization Broker) to validate agent identity at delegation time. Broker can verify that the agent being delegated to matches the expected identity before allowing delegation to proceed.

Runtime Controls

  • Implement agent authentication before every delegation. Each agent must authenticate to the target agent before sending sensitive data. Missing authentication is treated as indication of a compromised card.
  • Monitor delegation patterns for anomalies. If an agent suddenly starts delegating to a new endpoint, flag for investigation. Statistical analysis of endpoint addresses and response patterns can detect fraudulent endpoints.
  • Implement response validation: when an agent receives a response from a delegated agent, validate the response against expected schema and characteristics.
  • Maintain agent endpoint whitelist: agents should only delegate to pre-approved endpoints. New endpoints require human approval before agents can delegate to them.

Detection & Response

  • Monitor the agent registry for unauthorized card changes. Alert on any card modifications, especially changes to endpoint URLs or authentication requirements.
  • Conduct regular audits of active agent delegations. Sample delegation records and verify that the target endpoint matches the agent's published card and that responses are consistent with expected behavior.
  • Implement logging of card retrieval and validation. Log every time an agent retrieves a card from the registry, validates it, and decides to delegate.
  • Use Component 10 (Kill Switch) to halt agents that delegate to unauthenticated or anomalous endpoints, with automatic escalation to security operations.

Related Risks

Address This Risk in Your Institution

A2A Agent Card Manipulation requires architectural controls that go beyond what existing frameworks provide. Our advisory engagements are purpose-built for banks, insurers, and financial institutions subject to prudential oversight.

Schedule a Briefing