AI agent risk registers need four stable surfaces, not behaviour rows

At a glance

What this is: This is a framework for AI agent risk registers that maps each agent to four stable surfaces: Identity, Data, Tool, and Model, rather than to changing behaviour rows.

Why it matters: IAM, NHI, and AI governance teams need a register model that survives prompt drift, tool sprawl, and model changes if they want risk scores that remain operationally useful.

Context

Traditional risk registers break when they assume an AI agent’s risk profile is tied to a single observed behaviour. In cloud environments, the same agent can change prompts, gain new MCP connections, and shift the data it can touch without any change to the row that was originally written.

The governance problem is not that agents are unpredictable in general. It is that the stable unit of control is the agent surface, not the individual action. Once identity, data, tool, and model are treated as the durable boundaries, the register can survive non-determinism instead of being rewritten by it.

Key questions

Q: What breaks when AI agent risk registers are built around behaviour rows?

A: Behaviour rows break because the agent’s prompt, tool set, and model can change faster than the register can be rewritten. That makes yesterday’s likelihood and impact ratings stale. A usable register needs stable surfaces, not a single action description, so governance survives prompt drift and MCP expansion.

Q: Why do AI agent risk scores become unreliable after tool or model changes?

A: They become unreliable because the score was often tied to a behaviour that no longer exists in the same form. New tool connections expand the Tool surface, and model upgrades change the Model surface, so the original assumptions behind the score no longer match runtime reality.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: What is the difference between a CMDB entry and an AI agent risk register?

A: A CMDB entry describes what was declared, while an AI agent risk register should describe what is running and what surfaces it can reach. For AI agents, runtime scope matters more than static inventory because behaviour and connectivity change after deployment.

Technical breakdown

Why behaviour rows fail for AI agents

Behaviour-based registers assume that a risk entry remains valid if the agent keeps doing roughly the same thing. That assumption breaks for AI agents because the action path is assembled at inference time, not fixed in advance. A prompt change can alter which data is touched, a new MCP connection can expand tool reach, and a model upgrade can change the downstream effect without changing the row that captured the earlier behaviour. The useful control unit is therefore the surface, not the behaviour. Identity, Data, Tool, and Model are stable enough to govern because they describe what the agent can access, not what it happened to do once.

Practical implication: Build register entries around surfaces and governance scope, not one-off action descriptions.

How runtime-derived AI BOMs support register maintenance

A runtime AI bill of materials captures what is actually running, which model endpoints it calls, and which connections it opens. That matters because declared inventory often misses agents that exist in production before they are formally recorded. Once the inventory is built from runtime observation, each agent can be mapped to the four surfaces and updated selectively. A model upgrade changes the Model surface, a new tool connection changes the Tool surface, and credential scope changes the Identity surface. This keeps the register aligned with the system as deployed, not as originally documented.

Practical implication: Use runtime discovery as the source of truth for register population and surface-level change tracking.

Why Likelihood and Impact need observable inputs

Subjective 1-to-5 scoring is unstable for AI agents because the same agent can look materially different to different analysts. A stronger method is to anchor likelihood and impact to observable deployment properties. Likelihood can be derived from exposure, autonomy, and instrumentation gap. Impact can be expressed through identity blast radius, data sensitivity, tool capability, and model reach. That gives the committee a repeatable score based on measurable inputs rather than intuition. It also makes the register auditable, because the score can be re-derived when the environment changes.

Practical implication: Replace intuition-led ratings with observable inputs that can be re-scored after any material change.

NHI Mgmt Group analysis

Stable agent surfaces are the only durable unit of AI risk governance. Behaviour changes too quickly for a register row keyed to a single action to remain useful. When prompts, tools, and model versions shift independently, Identity, Data, Tool, and Model become the only surfaces that stay governable across the change cycle. The implication is that risk governance must stop pretending behaviour is the control boundary.

Runtime-derived inventory is a prerequisite, not a nice-to-have. A register cannot govern what it cannot see, and AI agents are particularly prone to existing in production before they are fully captured in CMDB-style inventory. Runtime AI BOMs give the committee the factual basis for scope, ownership, and surface mapping. That shifts governance from declared intent to observed deployment reality.

Observable scoring beats subjective scoring for AI agents. Likelihood and impact only become defensible when they are built from measurable exposure, autonomy, instrumentation gap, identity blast radius, data sensitivity, tool capability, and model reach. That is a programme design issue, not just a scoring preference. The practical conclusion is that AI risk committees need repeatable inputs they can re-evaluate after every material change.

Runtime telemetry is the governance control that keeps the register alive. A monthly review based on configuration alone cannot show whether an agent has drifted beyond its intended scope or accumulated dormant permissions. The useful register is one that consumes behavioural deviation, permission entropy, and cross-agent correlation as first-class governance signals. That makes the register an operational instrument, not an administrative record.

Agent risk governance now has a named design pattern: surface-based register architecture. The article’s four surfaces are more than a documentation aid, because they define the stable topology on which AI risk decisions can actually be maintained. This is the right abstraction for committees that need continuity across prompt updates, MCP expansion, and model refreshes. Practitioners should treat that architecture as the baseline for AI governance design.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Surface-based register architecture: AI agent governance works better when Identity, Data, Tool, and Model are treated as stable control surfaces rather than as snapshots of behaviour. That shifts the programme from trying to preserve a single “correct” risk row to maintaining the boundaries that actually survive runtime change.

The next governance question is not whether an agent is risky in the abstract, but whether the programme can observe scope drift as it happens. For leaders running AI agents inside existing IAM and GRC processes, the practical test is whether register maintenance can keep pace with tool expansion, model updates, and access changes without reclassification by guesswork.

For practitioners

• Map each AI agent to four stable surfaces Record Identity, Data, Tool, and Model columns for every production agent so changes can be updated by surface instead of rewriting behavioural entries.
• Build the register from runtime discovery Use observed processes, model endpoints, connections, and API patterns as the starting inventory rather than relying on declared CMDB entries.
• Replace subjective risk ratings with observable inputs Score likelihood using exposure, autonomy, and instrumentation gap, then score impact using identity blast radius, data sensitivity, tool capability, and model reach.
• Treat runtime KRIs as register evidence Track behavioural baseline deviation, permission entropy, and cross-agent correlation so monthly reviews reflect actual agent drift and scope expansion.

Key takeaways

• Behaviour-based risk registers age too quickly for AI agents because prompt, tool, and model changes can invalidate the original entry.
• The four stable surfaces of Identity, Data, Tool, and Model give security leaders a more durable unit for register design and review.
• Runtime discovery and telemetry turn the register into a governance control that can be updated, scored, and audited from observed state.

Key terms

• Agent Surface: The full set of places where an AI agent can be configured, triggered, and allowed to act. In practice this includes SaaS platforms, cloud runtimes, and endpoints. The term matters because governance fails when teams only see one part of the path and miss how the agent behaves across the rest.
• Runtime AI Bill of Materials: A Runtime AI Bill of Materials is a live inventory of the models, prompts, tools, data sources, policies, and dependencies an AI system uses while it is operating. It records what is actually active at execution time, helping security and governance teams trace behavior, assess exposure, and support incident response.
• Permission Entropy: The gap between what an AI agent is allowed to do and what it actually uses. A widening gap usually means dormant access is accumulating, which increases the attack surface without improving the agent’s function. For autonomous or semi-autonomous agents, that gap becomes a governance signal, not just an operational detail.
• Behavioural Baseline Deviation: A runtime measure of how far an AI agent’s current actions diverge from its normal observed patterns. It is useful because behavioural change can signal prompt drift, tool expansion, or coercion even when the configuration looks unchanged. The metric only works when telemetry is available across the relevant surfaces.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or AI governance programme, it is worth exploring.