A registry is only as good as its record. Most agent inventories fail not because nobody made a list, but because the list captured the wrong things — twenty columns of metadata and no answer to the question an incident actually asks: what can this thing touch, and who turns it off?
This post is about the record itself: the agent card, the fields it carries, why the industry is converging on "AI BOM" as the name for part of it, and how the fields line up with what the EU AI Act and ISO/IEC 42001 expect you to have written down. It goes a level deeper than our guide to the AI agent registry, which covers the registry around the record.
"Agent card" means two things. Keep both.
The term arrived twice. In agent-to-agent protocols, an agent card is a machine-readable descriptor an agent publishes so other agents can find it and call it — name, capabilities, endpoints, in a standard shape. In governance, an agent card is the record a registry keeps so humans can hold the agent to account — owner, purpose, risk, reach, controls.
These are not competitors. They are the same object read by two audiences. The protocol card tells software what the agent can do; the governance card tells the enterprise who answers when it does. A mature registry treats the protocol card as an input — harvested, not hand-typed — and the governance card as the system of record built around it.
A protocol card without ownership is capability without accountability. A governance card that no system reads goes stale by the second sprint.
The AI BOM: an old idea arriving on schedule
Software went through this already. After years of supply-chain incidents, the software bill of materials — the SBOM — moved from a nice idea to a procurement requirement.
The AI BOM extends the same logic to AI systems, and the term is showing up in security frameworks and vendor questionnaires for the same reason SBOM did: buyers and regulators want the ingredient list. For an AI system, that list is models, datasets, prompts, tools, APIs and the software dependencies underneath.
For agents, one extension matters more than the rest. An SBOM describes components — what the software is made of. An agent's bill of materials must also describe capabilities — what the agent is wired to call, reach and change. A component list tells you what might be vulnerable; a capability list tells you what a compromise can do. Record both, and weight your attention toward the second.
The record, in three groups
Ten fields make a workable agent card. They divide into three groups, and each group answers a different audience.
Accountability fields answer the governance committee. A named owner (a person, not a team). The business purpose, linked to the approved use case it serves. The risk tier, bound to the obligations that follow from it — where the EU AI Act applies, that is the agent's risk classification, role and obligations.
Capability fields answer the security review — this is the AI BOM proper. The model or models the agent calls, by provider and version. The tools and APIs it may invoke, MCP servers included. Its data reach: the systems of record it reads, and the shorter, sharper list of the ones it writes.
Control fields answer the incident commander. Containment status: does the agent run in an open runtime or inside a contained one? The kill-switch path: the exact steps that stop it, and who is authorized to take them. And the audit-log location: where its actions are recorded, and for how long.
If you must cut, cut from the middle group last and the first group never. An agent with an owner, a purpose and a kill-switch path is governable even when its dependency list is incomplete. The reverse is not true.
What the frameworks expect — qualitatively
Neither the EU AI Act nor ISO/IEC 42001 uses the phrase "agent card." Both assume its contents exist. The mapping is directional — which field earns which evidence — not legal advice.
The EU AI Act's record-keeping provisions (Article 12) require high-risk AI systems to be technically capable of automatically logging events over their lifetime, and the obligations around them expect those logs to be retained and producible. That is the audit-log-location field, made mandatory. The Act's technical-documentation and transparency obligations presume that a system's purpose, its ownership and its risk classification are written down and current — the accountability fields. And human-oversight expectations presume someone can actually intervene, which is a kill-switch path with a name attached.
ISO/IEC 42001 approaches from the management-system side: an organization certifying its AI management system needs to demonstrate it knows which AI systems are in scope, who is responsible for them, and how they are documented through their lifecycle — an inventory with owners, which is the registry itself, with the agent card as its unit of record.
The practical takeaway: you do not build one record for engineering and another for compliance. One record, honestly maintained, feeds both — which is why in Kosmoy each entry in the Agents Registry links to its EU AI Act qualification and feeds the ISO/IEC 42001 and NIST AI RMF evidence bundles, with every change to scope or ownership landing on the audit trail.
Where the record lives
A card is a document; a registry is a system. At small scale the distinction is theoretical — put the fields in a spreadsheet and start. It stops being theoretical the day an agent's tool access changes and the sheet does not.
The record needs to live somewhere that reconciles with runtime: harvested from the platforms where agents actually run, matched against approved use cases, with unmatched agents flagged for review. That is the job of the Agents Master Registry — one record shape for every agent, internal and external, across Azure AI Foundry, AWS Bedrock, Google Vertex AI, Salesforce and ServiceNow.
Start with the card. Graduate to the registry before the cards start lying.
Frequently asked questions
What is an agent card? An agent card is a structured record describing a single AI agent. In agent-to-agent protocols it is a machine-readable descriptor advertising an agent's capabilities to other agents; in governance it is the registry record advertising the agent's owner, purpose, risk tier, model, tool access, data reach and controls to humans. Mature registries maintain both views of the same agent.
What is an AI BOM? An AI BOM — bill of materials — extends the software bill of materials idea to AI systems. Where an SBOM lists the components inside a piece of software, an AI BOM lists what an AI system is made of and wired to: models, datasets, prompts, tools, APIs and dependencies. For agents, the decisive additions are capabilities — what the agent can call, reach and change.
How do agent records support EU AI Act and ISO 42001 compliance? Qualitatively and directly. The EU AI Act's record-keeping provisions assume you can produce logs per system, which requires knowing where each agent's audit trail lives. Its documentation obligations assume purpose, ownership and risk are written down. ISO/IEC 42001 presumes a documented inventory of AI systems with owners. The agent record is where all of that evidence starts.