An AI Card is a structured trust artefact that captures what an AI system claims to be doing and what it is observed doing. The concept matters because governance becomes durable only when declarations are paired with runtime evidence and kept in sync over time.
Expanded Definition
An AI Card is a governance record for an AI system that pairs declared intent with observed behaviour. In NHI security terms, it sits between policy, architecture, and runtime evidence, making it easier to ask whether an agent, model, or automated workflow is operating within its stated purpose. Unlike a static model inventory, an AI Card should reflect current tool access, data scope, escalation paths, and any constraints on autonomous action.
Usage in the industry is still evolving. Some teams treat the card as a lightweight assurance summary, while others extend it into an operational control record tied to monitoring, approvals, and incident response. The strongest use cases align with NIST Cybersecurity Framework 2.0 principles by making accountability, observability, and change tracking explicit.
An AI Card is not a model card, and it is not just a documentation page for legal review. It becomes meaningful only when its claims can be compared against live evidence from logs, tool calls, secrets usage, and policy enforcement. The most common misapplication is treating the AI Card as a one-time launch artifact, which occurs when teams fail to update it after prompt changes, new integrations, or expanded agent permissions.
Examples and Use Cases
Implementing AI Cards rigorously often introduces governance overhead, requiring organisations to weigh faster deployment against the cost of maintaining accurate evidence and approvals.
- An internal coding agent has an AI Card listing allowed repositories, secret access boundaries, and escalation conditions, then runtime logs confirm whether those boundaries are respected.
- A customer support assistant documents its approved data sources and response constraints, while monitoring verifies that it does not invoke tools outside its declared scope.
- A workflow agent used for incident triage references an approval trail and a rollback path, helping security teams compare declared behaviour with actual action sequences.
- After a compromise pattern is identified in the DeepSeek breach, teams use AI Cards to map which systems may have inherited contaminated behaviour, overbroad access, or unreviewed training inputs.
- Security architects can align the card with the operational thinking behind NIST Cybersecurity Framework 2.0 by documenting who is responsible for updates, review cadence, and control exceptions.
These examples are useful because they show the same pattern across different AI systems: the card is most valuable when it is tied to measurable controls rather than generic description. For NHI programs, that usually means linking it to identity boundaries, secret exposure risk, and approved tool use. It also helps investigators understand whether a change was authorised or simply drifted into production.
Why It Matters in NHI Security
AI Cards matter because NHI incidents often begin with a mismatch between what a system was supposed to do and what it was actually allowed to do. That mismatch is especially dangerous when agents can reach secrets, APIs, or production tools, because privileged behaviour can scale faster than human oversight. In the State of Secrets in AppSec, GitGuardian and CyberArk report that the average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities.
That gap is exactly why an AI Card should be treated as an operational control, not a paper exercise. It helps expose whether declared constraints still match observed access patterns, especially when teams add new integrations, inherit legacy credentials, or expand an agent’s toolset without revalidation. The same logic applies when an AI system learns from code or telemetry and begins to reproduce sensitive patterns, a concern highlighted in the same research set and reinforced by the LLMjacking report on credential abuse, though the exact attack path depends on the environment.
Organisations typically encounter the need for AI Cards only after an agent oversteps its mandate, at which point the record becomes operationally unavoidable to reconstruct what the system was allowed to do.
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 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic AI governance centers on declared capabilities versus actual tool use. | |
| NIST AI RMF | AI risk management depends on traceable claims, monitoring, and accountability. | |
| NIST CSF 2.0 | GV.RM-02 | Risk management requires evidence that system behaviour matches stated governance controls. |
Document each agent's intended scope, permissions, and runtime checks, then verify behaviour stays within that scope.
