They often treat them as documentation exercises instead of control enablers. A registry should tell you what exists, who owns it, what data it touches, and what level of risk it carries. Model cards should prove the system’s intended use, limitations, and validation evidence.
Why This Matters for Security Teams
AI registries and model cards are often introduced as governance artefacts, then left outside the operational security stack. That is a mistake. A registry should support asset discovery, ownership, data exposure mapping, and risk tiering. A model card should support decision-making about intended use, validation limits, and release approvals. Without those controls, security teams cannot answer basic questions when a model is used in production, repurposed by another team, or connected to tools and data it was never cleared to touch.
This matters because AI failures are rarely isolated to one model file. They spread through training data, prompts, retrieval layers, downstream automation, and API access. The pattern is visible in incidents such as the DeepSeek breach, where governance gaps become operational risk. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward asset, risk, and control ownership rather than documentation for its own sake.
In practice, many security teams encounter model sprawl only after an AI system has already been connected to sensitive data or production workflows, rather than through intentional approval and review.
How It Works in Practice
Effective registries and model cards work as control enablers, not static records. The registry should answer who owns the model, where it runs, what data it uses, what dependencies it relies on, and whether it is a first-party model, a hosted API, or a fine-tuned derivative. The card should evidence intended use, prohibited use, evaluation results, known failure modes, and change history. That is the minimum needed to support risk acceptance, monitoring, and incident response.
Security teams should treat each registry entry as a control point across the AI lifecycle:
- Classify the model by business impact and data sensitivity.
- Link the model to approved datasets, prompts, and retrieval sources.
- Record validation evidence for accuracy, robustness, and safety checks.
- Require named ownership for remediation and periodic re-approval.
- Track whether the model is exposed through APIs, agents, or embedded workflows.
This approach aligns well with the NIST Cybersecurity Framework 2.0 and is reinforced by NHIMG research on how security blind spots emerge when teams cannot see what is connected, who owns it, or how it is governed. The same operational problem appears in The State of Non-Human Identity Security, where visibility gaps and weak lifecycle control drive exposure. For AI systems, those weaknesses translate into untracked model access, stale approvals, and unmanaged tool integrations.
Model cards are also where evidence should live, not just descriptions. That means versioned test results, limitations by environment, and clear statements about whether a model was evaluated for prompt injection, data leakage, or unsafe tool use. These controls tend to break down when AI systems are deployed as shadow services inside product teams because no single owner maintains the registry, the card, and the actual runtime configuration.
Common Variations and Edge Cases
Tighter registry and model card governance often increases approval overhead, requiring organisations to balance speed of deployment against assurance and traceability. That tradeoff is real, especially where teams rely on rapid experimentation or vendor-managed models.
There is no universal standard for how deep a model card must go, but current guidance suggests more scrutiny is needed as the model’s autonomy, data sensitivity, and external exposure increase. A simple internal classifier does not need the same evidence burden as a model that can call tools, retrieve sensitive records, or influence customer decisions. In those cases, model cards should capture agentic behaviour, escalation paths, and any guardrails around actions and outputs.
Edge cases usually appear in three places: vendor models with limited transparency, fine-tuned models whose upstream lineage is unclear, and AI agents that change behaviour based on tools or prompts. In those environments, a registry entry alone is not enough. Security teams need runtime inventory, access logging, and periodic recertification so the documented state matches the deployed state. NHIMG’s research on the State of Secrets in AppSec is also relevant here because AI systems often inherit the same weakness as secrets programs: fragmented ownership, weak visibility, and slow remediation.
Where organisations allow internal teams to clone, fine-tune, or wrap models without central approval, the registry becomes stale almost immediately and model cards stop reflecting the system people are actually using.
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 MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF governs trustworthy AI lifecycle control and accountability. | |
| NIST CSF 2.0 | ID.AM | Asset management is the core purpose of an AI registry. |
| OWASP Agentic AI Top 10 | Agentic systems need controls over tool use, output validation, and escalation. | |
| MITRE ATLAS | ATLAS covers adversarial AI attack paths such as prompt injection and model misuse. | |
| NIST AI 600-1 | GenAI profiles emphasize documentation of intended use and limitations. |
Inventory models, owners, data sources, and dependencies as managed assets with defined accountability.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
