The Agent Card Problem: Why Trusting Another Company's AI Agent Is Riskier Than It Looks

What is the Agent Card problem?

An Agent Card can tell you a fair amount about another company's AI agent: its name, the skills it claims to support, the endpoint you should call, the authentication scheme it expects. What it cannot tell you is whether any of that is accurate, whether the organization behind it is who the card says it is, or whether the agent will still be doing what the card describes six months into the integration.

That gap is where most of the real risk in agent-to-agent communication sits. It isn't a hypothetical edge case. It's the predictable result of building a discovery mechanism and, out of habit, treating it as a trust mechanism.

What A2A actually provides

It's worth being precise here, because A2A does more than a card lookup. The protocol, now governed under the Linux Foundation and backed by organizations including Google, Microsoft, Salesforce and ServiceNow, defines how an agent publishes an Agent Card, how a client authenticates to it, how work is exchanged as structured Tasks with a defined lifecycle (submitted, working, input-required, completed, canceled, failed), how messages within a task carry text, files, or structured data, and how longer-running work can stream updates or push notifications back to the caller. Three transport bindings ship with the specification: JSON-RPC over HTTPS, gRPC, and HTTP+JSON/REST.

That's a reasonably complete interaction protocol, not just a discovery format. The Agent Card itself can also carry a cryptographic signature, an AgentCardSignature using JWS over a canonicalized version of the card, so a client can confirm the document wasn't tampered with and did come from the key that signed it. An authenticated request can also retrieve an "extended" card with more detail than the public one.

None of that is a minor detail, and none of it should be flattened into "the card is just a random claim." A signed card, checked against a key you've actually decided to trust, is a real, verifiable statement that a specific document came from a specific source. What it still isn't is a statement about whether that source is trustworthy, whether the advertised capabilities match runtime behavior, or what happens after authentication succeeds. The protocol gives you strong tools for discovery, message exchange, and proving a document's origin. It does not, and was never meant to, make the authorization decision for you.

Trust, defined precisely

"Trust" gets used loosely enough in security writing that it's worth pinning down before building anything on top of it.

Here, trust means a specific, bounded, revocable decision: that a given identity, independently verified rather than merely claimed, is authorized to perform a specific set of actions, under specific conditions, for a period that is re-evaluated rather than assumed permanent. That decision is made by one accountable party, the integrating enterprise's own security or platform team, encoded as policy, not inferred by a model at runtime and not delegated to the counterparty's own card.

The criteria behind that decision are concrete: does the identity behind this request match a verified, registered identity (not just an authenticated one); does the specific action requested fall within a capability set your policy has explicitly allowed, rather than the full set the card advertises; what is the risk tier of that action (read, write, irreversible); and does current monitoring data give any reason to suspect the agent's behavior has drifted from what was approved.

Framed that way, the earlier point sharpens into something more useful: an Agent Card contributes evidence to that decision (what's claimed, and whether the claim is signed). It is not the decision itself, and no part of the protocol claims that it is.

A cross-company scenario

Company A runs an internal procurement agent. Company B, a supplier, exposes an external agent through A2A that advertises four skills: search products, check inventory, create quotations, submit purchase requests. The integration looks straightforward, and in a demo it is.

Walk it forward. Company B updates its Agent Card six weeks in, adding a skill nobody at Company A reviewed. The agent starts pulling from a data source it didn't originally touch. Company B's credentials are compromised, but the attacker is simply reusing a valid, authenticated identity, so every request still passes authentication cleanly. Or the agent itself is compromised at the runtime layer, with the card never touched at all.

Then the harder case, the one most write-ups on this topic skip: Company B's agent, mid-task, delegates part of the work to Agent C, a third party Company A has never seen an Agent Card for, never registered, and never evaluated. Company A's original trust decision was about Company B's agent specifically. Nothing in that decision was ever supposed to extend to whatever Agent C turns out to be, but if the integration doesn't explicitly check for that, it extends anyway, by default, the moment Company B's agent decides to delegate.

None of this requires a sophisticated attacker. It's ordinary operational drift, the same kind that already happens between two companies' REST APIs.

What's actually different from an ordinary third-party API

That last comparison deserves a direct answer, because most of the individual failure modes above (credential compromise, scope creep, a stale integration contract) already exist in conventional API partnerships, and a security architect will rightly ask what's specific to agents here.

Three things. First, a traditional API call executes one predefined operation; an agent, once authorized, makes a sequence of its own decisions inside that authorization, so a permission that's slightly too broad doesn't cause one bad call, it causes an open-ended number of bad calls the agent decides to make on its own. Second, the delegation case above has no clean analogue in API integration: a REST API doesn't autonomously decide, at runtime, to forward your request to a completely different vendor you never vetted. An agent can. Third, a conventional API partnership usually goes through a manual vendor-review process before the first integration ships. An Agent Card is designed for the opposite: fast, machine-readable discovery that lets two systems connect without a human necessarily reviewing who's on the other end first. That's a legitimate, useful design goal, not a shortcoming in the protocol, but it does mean the manual review step a traditional integration relies on isn't built in by default, and has to be added back deliberately by whoever's integrating.

A concrete architecture for the trust layer

This is the part that's easy to leave abstract, and worth making specific.

The registry, and who runs it. The Agent Registry is owned and operated by the integrating enterprise, not shared with the counterparty and not a public directory. An external agent isn't queryable through it by default; it's added through an explicit onboarding step where someone (a named security or platform owner, not an automated acceptance) reviews the Agent Card, decides which of its advertised capabilities are actually going to be permitted, and records that decision as policy. The registry stores the approved card, its signature or a hash of its contents, and the capability subset that was actually granted, which is very often narrower than what the card advertises.

Detecting a changed card. On every fetch, or on a scheduled re-fetch for long-lived integrations, the current card's hash (or signature, if present) is compared against the stored version. A mismatch doesn't get silently accepted or silently rejected; it triggers a re-approval workflow, routing back to the same human or process that did the original review, with the specific diff (what capability was added, what endpoint changed) surfaced directly rather than requiring someone to spot it by eye.

Authorization, enforced outside the model. The actual decision of what a given authenticated request is allowed to do is made by a policy enforcement point sitting between your internal systems and the external agent, evaluating the registry's stored, approved capability set, not the live card and not whatever the requesting agent claims about itself in the message. This is deliberate: neither an LLM nor a self-declared document should be the last checkpoint before an irreversible action, because both can be manipulated by content they process. The PEP's decision is deterministic policy evaluation, the same kind you'd apply to any other privileged system.

Runtime behavior, not just the initial handshake. Each external agent identity gets a behavioral baseline (typical request volume, typical capability usage, typical data scope), and requests are compared against it, with material deviation triggering either an alert or a hold pending review, depending on the risk tier of the action. First-time or high-risk actions for a given agent (a new capability being invoked, a larger transaction than any seen before) can be routed through a staged or dry-run execution path before being committed for real, rather than trusted on the first attempt. Rate limits apply per registered identity, not just per API key, so a compromised credential can't be used to exceed the volume the original approval anticipated.

Revocation that doesn't depend on the other side. Credentials issued to an external agent are short-lived by design, so a compromise has a bounded window even with no active response. On top of that, the registry supports an explicit deny-list enforced at the PEP: flagging an identity there blocks it immediately regardless of whether its existing token is still technically valid, and regardless of whether Company B cooperates. Credential rotation happens on a schedule, not only in response to a known incident.

Delegation, handled explicitly instead of by default. The default policy is that delegated trust is not inherited. If Company B's agent forwards work to Agent C, Agent C is a new principal that has to independently clear the same registry and approval pipeline before anything it does is authorized, regardless of what Company B's original Agent Card said. If your integration doesn't have a policy answer to "can this agent delegate, and to whom," the honest default is that it can't, until you've explicitly decided otherwise.

The threat frame, briefly

Stated formally rather than as a loose list: the asset being protected is whatever internal data, tools, or actions become reachable once an external agent is authorized. The trust boundary is the policy enforcement point, not the network edge and not the authentication handshake. The principal is the verified, registered identity behind a request, which is a narrower and more specific thing than "whatever authenticated successfully." Against that frame, the threats worth naming directly are identity spoofing through a fabricated or stolen credential, tampering with the Agent Card itself, privilege escalation through capability drift that goes unreviewed, repudiation from an integration with no real audit trail, information disclosure through a capability grant broader than the actual business need, and denial of service or runaway cost through unchecked delegation or retry behavior.

Before you trust an external agent

Who owns this identity in your registry, and who approved it? Is the card signed, and is that signature checked against a key you've deliberately chosen to trust, not just accepted on first sight? Which capabilities were actually granted in policy, as opposed to merely advertised? What's the enforcement point for that grant, and is it something outside the model's own judgment? What's the mechanism, specifically, for noticing the card has changed, and what happens when it has? What's the actual revocation path, and does it work even if the other side doesn't cooperate? Can this agent delegate, and if so, does the delegate go through the same approval your original agent did?

If any of those don't have a concrete answer, that's the gap, not a theoretical one.

The real mistake

The biggest mistake an enterprise can make with agent-to-agent communication is treating discovery metadata as proof of trust. It's an understandable mistake: the card is well-structured, sometimes signed, and looks exactly like the kind of artifact that should be authoritative. It solves discovery, capability negotiation, and message exchange well. None of this is a claim that A2A is poorly designed; it's a claim about where the protocol's responsibility ends and the integrator's begins. The card was never built to answer "should I trust this," and the fix isn't a better card. It's a registry, a policy layer, and a monitoring loop that treat every external agent as an unproven principal until each of those questions has an actual, specific answer.

The card gets you in the door. Everything past that door still has to be built.

FAQ

Related reading

This sits alongside MCP Security as a companion trust-boundary problem, both inside the broader discipline of Agentic AI Security.