How should security teams build an AI agent risk register that survives changing behaviour?

Why This Matters for Security Teams

An AI agent risk register only stays useful if it tracks what remains stable when the agent changes: identity, data, tool access, and model dependencies. If the register follows prompt tweaks or every new tool hookup, it becomes obsolete before anyone can use it. That is especially dangerous in autonomous systems, where behaviour changes at runtime and access paths are not fully predictable. Current guidance from the NIST AI Risk Management Framework and NHIMG’s OWASP NHI Top 10 both point to the same operating reality: risk management has to be tied to durable surfaces, not transient behaviour.

The practical issue is governance drift. Security teams often create a risk register at pilot stage, then the agent gets a new connector, a broader prompt, or a different model, and the original findings no longer map cleanly to production. That creates blind spots around secrets exposure, tool chaining, and data misuse. In NHIMG’s AI Agents: The New Attack Surface report, 80% of organisations reported agents acting beyond intended scope, which shows how quickly the real risk surface can outrun static documentation. In practice, many security teams discover the register is stale only after an agent has already accessed data or tools it was never meant to touch.

How It Works in Practice

A durable AI agent risk register should be structured around four stable objects: the agent identity, the data classes it can read or write, the tools it can invoke, and the model or models it depends on. Each entry should describe the risk, the control objective, the owner, the evidence source, and the review trigger. That makes the register a production artifact, not a one-time assessment. It also creates a clean path to map the register to policy frameworks like the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework.

• Use a stable inventory key for each agent, not a prompt version number.
• Record every tool and connector as a separate risk-bearing asset.
• Classify data access by sensitivity, direction, and business impact.
• Track model swaps, context-window changes, and retrieval sources as change events.
• Attach control tests to runtime evidence, such as logs, policy decisions, and approvals.

This approach works best when the register is integrated with workload identity, short-lived credentials, and request-time authorization. The register should note whether the agent is using ephemeral access, what breaks if a token leaks, and which policy engine enforces limits at runtime. That aligns well with NIST Cybersecurity Framework 2.0 and the governance function in NIST AI RMF, because it ties risk to ongoing control performance rather than a static sign-off. These controls tend to break down when teams treat the agent like a normal application and ignore runtime tool use, because autonomous behaviour changes the real exposure faster than review cycles can catch up.

Common Variations and Edge Cases

Tighter risk registers often increase maintenance overhead, so organisations have to balance traceability against operational speed. That tradeoff becomes sharper when agents are allowed to self-extend through new plugins, retrieval sources, or delegated sub-agents. There is no universal standard for how granular the register should be yet, but current guidance suggests the register should be detailed enough to explain who can do what, with which data, through which tool, and under which approval path.

Edge cases matter. A customer-facing assistant with read-only retrieval may need a much lighter register than an agent that can write tickets, execute code, or trigger payments. A multi-agent workflow should usually be tracked at both the system level and the individual agent level, because one agent’s safe scope can become another agent’s escalation path. For deeper examples of how agent behaviour shifts after deployment, NHIMG’s Replit AI Tool Database Deletion and Amazon Q AI Coding Agent Compromised illustrate how tool access can turn a local issue into a material production incident.

In practice, the best risk registers are reviewed after connector changes, model changes, and permission changes, not just during annual governance cycles.

Related resources from NHI Mgmt Group

• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams handle AI agent visibility?
• How should security teams monitor AI agent activity without disrupting developers?
• How should security teams build an AI risk repository that actually changes behaviour?