How to Write an AI Agent Model Card for Auditors

Why Traditional Model Cards Fall Short

Traditional ML model cards were designed for static artifacts. They describe training data, intended use, evaluation metrics, and known limitations of a model that produces an output and stops. That format works reasonably well for a classifier or a language model queried in isolation.

AI agents behave differently. An agent does not simply return a prediction. It holds credentials, calls tools, reads and writes data, and sometimes invokes other agents. Its behavior is shaped not only by the underlying model but by the permissions, tool integrations, and runtime policies wrapped around it. A model card that only describes the model itself leaves auditors with no visibility into what the agent is actually allowed to do or has done in production.

This gap is the core reason enterprises struggle during compliance reviews. Auditors ask for evidence of access control, least privilege, and operational oversight. A document built for a static model cannot answer those questions because it was never designed to.

What Auditors Are Actually Looking For

Auditors reviewing AI agent deployments are generally trying to answer a small number of questions: what is this agent authorized to do, who approved that authorization, what controls prevent it from exceeding that authorization, and what evidence exists that those controls actually held during operation?

An agent model card should be structured to answer each of these directly, rather than burying them inside general narrative text. This means separating identity from permissions, separating permissions from tool access, and separating stated policy from operational evidence. When these elements are mixed together, auditors are forced to reconstruct the governance picture themselves, which increases review time and the likelihood of findings.

The model card does not need to contain raw logs or a live feed of agent activity. It needs to clearly state what evidence exists, where it is retained, and how it maps back to the permissions and controls described in the card.

Documenting Agent Identity and Access Scope

Agent identity documentation should go beyond a name or version number. It should describe how the agent is authenticated at runtime, whether it operates under its own identity or inherits permissions from a user or service account, and how that identity is distinguished from other agents operating in the same environment.

Access scope documentation should list, at a level of specificity an auditor can verify, which systems and data the agent can reach. This includes read versus write access, any data classification boundaries, and whether access is time-limited or persistent. Where least-privilege principles are applied, the card should state the specific restrictions in place rather than asserting adherence to the principle in general terms.

Capturing Tool Access and Runtime Behavior

Tool-call permissions are one of the clearest points of divergence from traditional model documentation. An agent model card should enumerate the tools or APIs the agent is permitted to invoke, whether invocation requires approval, and what constraints apply to each tool, such as rate limits or restricted parameters.

Because agent behavior is dynamic, a static document cannot fully capture every tool call or permission change over time. The practical approach is for the model card to describe the governing policy and enforcement mechanism, then reference where operational evidence, such as tool invocation records or permission change history, is retained. This keeps the card accurate as a policy statement while pointing auditors to the systems of record for behavioral evidence.

This distinction between stated policy and operational evidence is important. The model card should not claim to be a complete activity log. It should be the authoritative description of intended behavior, with clear pointers to where actual behavior is recorded.

Practical Guidelines

The following practices help keep an agent model card accurate, specific, and useful during review:

• Write permission and access sections in specific, verifiable language rather than general governance statements.
• Keep the card focused on what the agent is authorized to do, and reference enforcement systems for what it actually did.
• Update the card on every material change to tools, permissions, or runtime policy, not on a fixed annual schedule alone.
• Avoid combining multiple agents into a single card if their permission scopes differ materially.
• Ensure the card identifies who approved the agent's current permission set.

Where Runtime Governance Fits

An agent model card is only as reliable as the systems that enforce and record the behavior it describes. If permissions stated in the card are not actually enforced at runtime, or if tool invocations are not logged, the document becomes a policy statement with no operational backing.

This is the practical link between documentation and runtime governance. Runtime policy enforcement, agent identity management, and audit logging are what generate the evidence an agent model card refers to. Trussed AI provides runtime governance and security controls for enterprise AI agents, including agent identity, permission enforcement, tool approval workflows, and audit logging, which can serve as the underlying evidence source that an agent model card points to rather than restates.