What should a model card say about security? Common mistakes

A model card should say what the model is for, what it is not for, how it was evaluated, what data shaped it, which version it describes and where to report a security problem. The common mistakes are treating it as marketing, leaving out limits and failing to update it when the model changes.

What is a model card?

The idea comes from a 2018 paper by Margaret Mitchell and colleagues, "Model Cards for Model Reporting". They proposed brief documents shipped with trained models that report benchmarked performance across groups relevant to the application, state the intended use context and describe how the evaluation was done. Security teams have since borrowed the format for a broader purpose: telling buyers and users what the model is and where it can fail.

Mistake 1: writing it as a brochure

A card that lists only strengths gives a reader nothing to plan around. OWASP's guidance on misinformation recommends clearly communicating risks and limitations to users and stating the intended field of use and reliability limits. Put known weaknesses and out-of-scope uses in the card, near the top.

Mistake 2: no version, no date

A model changes: new weights, new fine-tuning, a new system prompt, a new retrieval source. A card without a version and date cannot be matched to the model someone is running. Tie each card to a specific version and keep older cards available.

Mistake 3: evaluation without method

Numbers with no description of test data, conditions or metrics cannot be checked. Mitchell and colleagues emphasise describing how the evaluation was done. Include what you tested, what you did not, and what changed since the last test. For security, include which misuse tests you ran, in general terms, without publishing working attack content.

Mistake 4: silence about data

Readers need to know the kinds of data used for training and fine-tuning, and whether customer data is used. Where you cannot disclose details, say so and say why. NIST's Generative AI Profile, NIST-AI-600-1, released in July 2024, helps organisations identify risks specific to generative AI and is a useful prompt list for what to disclose.

Mistake 5: no path to report a problem

If someone finds a way to make the model leak data or take an unsafe action, where do they go? Publish a contact, an expected response time and a statement of how you will handle reports. A card with no contact invites public disclosure.

Mistake 6: leaving out the surrounding system

Many security failures come from the system around the model: tools it can call, data it retrieves, permissions it holds. OWASP's excessive agency guidance names excessive functionality, permissions and autonomy as root causes. A card for a model used as an agent should list the tools and permissions in the reference deployment, and recommend limits.

Mistake 7: using a card as a certification

A card is a statement by the publisher. It is not an audit and not a guarantee. Say that plainly, and do not borrow the language of a standard or certificate you do not hold.

What can buyers do with a card?

Read it for limits, ask for the version they will use, compare the stated use with their own, and request evidence for any claim that matters. If a card is missing, treat that as information.

What to do

1. Add intended use, out-of-scope use and known limitations at the top of each card.
2. Tie each card to a version and date, and keep a changelog.
3. Describe evaluation data, method and metrics, plus the misuse tests you ran.
4. State data practices, including customer data, as far as you can.
5. Publish a security contact and response expectations.
6. For agents, list tools, permissions and recommended limits.
7. Review the card whenever the model, prompt or retrieval sources change.

Quick check

Sources

• Mitchell et al., Model Cards for Model Reporting
• OWASP LLM09 Misinformation
• OWASP LLM06 Excessive Agency
• NIST AI Risk Management Framework

Last reviewed: 18 October 2026.