AI Risk Register Template: What to Track and How

Traditional IT risk registers, as described in NIST SP 800-30, are structured around asset, threat, vulnerability, likelihood, and impact fields. This structure works well for static systems but does not natively account for model behavior, autonomy, or tool invocation. An AI agent does not just process data; it makes decisions, calls tools, and acts within a scope of granted permissions. When a risk register treats "the AI system" as a single asset, it collapses distinct failure modes, such as a model producing an incorrect output versus an agent invoking a tool outside its intended scope, into one undifferentiated entry. NIST's AI Risk Management Framework addresses this by organizing risk management around four functions: Govern, Map, Measure, and Manage. The Map function in particular calls for context-specific risk identification rather than generic AI risk labels, which supports building a register with categories tailored to how agents actually behave in production rather than how models behave in isolation.

Several recognized frameworks describe risk categories that traditional IT taxonomies do not capture. The OWASP Top 10 for LLM Applications names Excessive Agency, describing harm that arises when an agent is granted more functionality, permissions, or autonomy than its task requires. It also names Insecure Plugin Design and prompt injection, both relevant to tool-call and integration risk that has no equivalent in conventional software risk categories. MITRE ATLAS catalogs adversary tactics specific to AI systems, including model evasion and data poisoning, distinct from the threat techniques in frameworks like MITRE ATT&CK. NIST's Generative AI Profile (NIST AI 600-1) adds risks such as confabulation, data privacy exposure, and value chain risk arising from third-party models or components. Together these sources point to a working set of agent-specific categories a register should track explicitly: tool-call misuse, permission escalation, excessive agency, identity or credential misuse, and adversarial manipulation, each treated as its own entry rather than folded into a general "AI risk" bucket.

A register built for agent governance should separate entries into at least three layers: model-level risks such as hallucination or confabulation, agent-level risks such as decision scope or autonomous action beyond intended task boundaries, and tool or integration-level risks such as trust boundary violations between a client, server, and external tool. The Model Context Protocol, published by Anthropic in November 2024 as an open standard for connecting models to external tools and data sources, illustrates why this separation matters. MCP's architecture introduces distinct trust boundaries between the model, the MCP server, and the external tool or API it exposes. A register that tracks "the AI system" as one line cannot represent a risk that originates specifically at the server-to-tool boundary, such as an MCP server exposing more tool functionality than the agent's task requires. Mapping register entries to these boundaries individually keeps the risk taxonomy aligned with where a failure or misuse would actually occur.

A risk register that exists only as a static document disconnected from operational controls does not close the gap between policy and enforcement. Each entry should carry an identifier that corresponds to a runtime monitoring or policy enforcement point, so that when a violation is detected in production, such as an agent attempting a tool call outside its granted scope, it can be traced back to a documented risk rather than treated as an isolated incident. This is the practical difference between a compliance artifact and an operational governance tool. Runtime governance capabilities, including policy enforcement, agent identity and permission management, tool approval workflows, and audit logging, are the mechanisms that make this linkage functional. Trussed AI provides runtime governance and security for enterprise AI agents, including agent identity, permissions, and tool approval enforcement that can be mapped to register entries defined using the structure above, so that identified risks correspond to active monitoring rather than remaining as unreferenced rows in a spreadsheet.