An Agent Card is a machine-readable description of an agent’s capabilities, endpoint, and invocation details. In A2A-style systems it helps other agents discover and call the agent at runtime, which makes the card a governance object as much as a technical descriptor.
Expanded Definition
An Agent Card is the structured identity record an agent presents so other systems can discover what it can do, how to reach it, and under what conditions it may be invoked. In practice, it sits at the intersection of API documentation, runtime discovery, and governance. In A2A and similar agent-to-agent ecosystems, the card can describe endpoints, supported tools, authentication expectations, and operational metadata that determines whether an upstream agent is allowed to call it. That makes it more than a convenience layer: it is a control surface for trust.
Definitions vary across vendors because no single standard governs this yet, and implementations may emphasize transport, schema, or policy differently. For governance teams, the useful question is not only “what does the agent do?” but “what evidence does the card expose for safe invocation?” The OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework both reinforce the need to treat machine-readable agent interfaces as risk-bearing assets, not just technical metadata. The most common misapplication is treating an Agent Card as static documentation, which occurs when teams publish capabilities without tying the record to access policy, ownership, and revocation.
Examples and Use Cases
Implementing Agent Cards rigorously often introduces maintenance overhead, requiring organisations to weigh easier discovery and orchestration against tighter change control and review burden.
- A support automation agent publishes a card that declares ticket lookup, status update, and escalation tools, while policy checks confirm the caller is authorized before invocation.
- A finance workflow agent exposes its endpoint through a card, but only after the identity team validates ownership, logging, and token scope against the OWASP NHI Top 10.
- An internal code assistant uses an Agent Card to advertise repository read and commit actions, with the card linked to approval rules informed by the NIST AI Risk Management Framework.
- A partner-facing scheduling agent publishes limited capabilities only, so downstream agents can discover it without exposing privileged functions or secret-bearing endpoints.
- A security operations agent rotates its invocation details when the backend endpoint changes, preventing stale discovery records from sending traffic to retired services.
NHIMG research on the OWASP Agentic Applications Top 10 shows how quickly agent-to-agent exposure becomes a governance issue when runtime descriptions overstate trust or omit constraints.
Why It Matters in NHI Security
An Agent Card becomes security-critical because it can function as the discoverability layer for a non-human identity. If the card is inaccurate, stale, or overly permissive, an agent may be invoked with more authority than intended, or by an untrusted peer that should never have found it. That risk is amplified when the card is used to advertise tool access, because the description can outlive the actual policy behind it. In mature environments, the card should align with ownership, least privilege, secrets handling, and revocation processes, not just service registration.
This matters in the broader NHI landscape because NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs — 2025 Outlook and Predictions. That visibility gap is exactly where misleading agent metadata becomes dangerous, especially when paired with agentic misuse patterns described in the AI LLM hijack breach. Organisations typically encounter the consequence only after an agent is abused, misrouted, or discovered through an exposed interface, at which point Agent Card governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | N/A | Agent Cards expose discoverable agent interfaces and tool access, a core agentic-app risk area. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Agent Cards can surface identity, endpoint, and invocation data that must not outrun governance. |
| NIST AI RMF | The framework requires mapping AI system risk, context, and controls around exposed agent behavior. |
Treat the card as an NHI asset, review its fields, and remove any capability not backed by policy.
