An AI agent risk register is a maintained record that lists the specific risks posed by an organization's deployed agents, rates each one's likelihood and impact on a qualitative scale, names an accountable owner, and links each entry to the control that mitigates it. It differs from a generic AI risk policy document by being concrete: every entry traces back to a real agent or agent category, a real access path, and a real control — not an abstract statement about AI risk in general.

Why a Generic AI Risk Statement Is Not a Register

Many organizations already have a paragraph in a broader risk framework that says something like "AI systems introduce risk of data exposure and misuse." That statement is true and also useless for operational purposes, because it does not tell anyone which agent, which access path, or which control is relevant. A risk register earns its value from specificity: "Agent X has write access to the customer database and lacks output-content guardrails" is a register entry you can act on. "AI introduces risk" is not.

The register should be built outward from the agent inventory, not from a generic industry risk taxonomy applied top-down. Start with what actually exists — real agents, real connections, real data access — and identify risk from there.

The Procedure

1. Define risk categories. Owner: whoever owns the register overall, typically a compliance or security function. Establish a small, fixed set of categories that every entry will be classified under, so the register stays comparable across entries rather than becoming an unstructured list. A workable starting set: identity and credential risk, over-broad access risk, content and data-exposure risk, cost and availability risk, and third-party or supply-chain risk (covering connected MCP servers and external agent platforms).

2. Walk the inventory and identify concrete risk instances. Owner: platform engineering and security, working from the inventory together. For each agent or logical group of similar agents, identify which categories apply and what the specific exposure is. An agent with shared, unrotated credentials is an identity-and-credential risk entry. An agent connected to an unvetted MCP server is a third-party risk entry. This step is the one that turns the register from theoretical to concrete, and it should reference the actual agent name or category, not a hypothetical.

3. Rate likelihood and impact qualitatively. Owner: the risk owner for that entry, reviewed by security. Use a low/medium/high scale for both likelihood and impact, with a one-sentence rationale for each rating rather than an invented numeric score. A rating of "high impact" should be justified by what the agent can actually reach — production financial data, customer PII — not by a generic sense that "AI risk is high." Resist the temptation to multiply likelihood and impact into a single composite number; a qualitative combination (e.g., a simple risk-level matrix) is more honest about the actual precision of the underlying judgment.

4. Link each entry to a control. Owner: platform engineering. Every register entry needs a reference to the control that mitigates it — a specific guardrail, a connection policy, a credential rotation schedule — and a status: enforced, partially enforced, or planned with a date. An entry with no linked control, or a control listed as "planned" with no date, is a gap masquerading as a documented mitigation.

5. Assign an owner per entry. Owner: whoever owns the register overall. Every entry needs a named accountable person, distinct from the register's overall owner, who is responsible for that specific risk closing or staying adequately controlled. A register where every entry is owned by the same person at the top is a register where nothing gets prioritized differently from anything else.

6. Set a review cadence. Owner: whoever owns the register overall. Higher-severity entries need more frequent review than lower-severity ones. A register reviewed once a year at the same time as an unrelated compliance cycle will not catch a new agent's risk until the next cycle happens to roll around, potentially months after the exposure existed.

7. Reconcile against the current inventory on every review. Owner: platform engineering. Before reviewing existing entries, check whether new agents have entered the inventory since the last review and whether any registered agent's access has changed enough to alter its risk rating. A register that only revisits its existing entries and never checks for new ones will systematically miss the newest, least-reviewed agents — which are often the riskiest, precisely because they have not yet been through a full review cycle.

Where This Fails in Practice

Entries are generic instead of specific. A register full of entries like "risk of AI misuse" with no named agent, no specific access path, and no linked control provides the appearance of risk management without any of the substance. Every entry should be traceable to something concrete in the inventory.

Ratings are invented numbers dressed up as precision. Assigning a numeric score like "risk score: 7.3" implies a level of measurement precision that rarely exists for agent risk today. A qualitative rating with a written rationale is more honest and, in practice, more useful for prioritization than a false-precision number nobody can defend under questioning.

Controls are listed as planned indefinitely. An entry that has said "mitigation planned" for three consecutive review cycles with no date and no progress is not a mitigated risk — it is an unmitigated one with a comforting label. Every "planned" status needs a deadline, and a register owner should escalate entries that blow past their planned date repeatedly.

The register drifts from the inventory. If new agents are not automatically flagged for register review, the register becomes a static snapshot of whatever the fleet looked like at its last full update, silently growing less accurate as the fleet changes. Tying register reconciliation to inventory changes, rather than to a fixed calendar date alone, keeps this from happening.

Mapping Threat Models to Register Categories

Step 1 above sets broad categories; step 2 asks you to fill them with real instances, and the fastest way to do that thoroughly is to draw on the specific threat models your organization has already documented rather than reasoning from scratch for every entry. If a threat model for indirect prompt injection already exists for agents that retrieve external content, the register entry for content-and-data-exposure risk on those agents should reference it directly rather than restating a generic version of the same concern. Similarly, an entry covering agent scope creep — an agent discovering and using capability nobody explicitly granted — belongs under over-broad access risk for any agent with open-ended reasoning over a wide action space, distinct from an entry about a credential that was deliberately over-provisioned at onboarding. Treating existing threat models as source material for register entries, rather than duplicating the analysis, keeps the register internally consistent with the rest of the security documentation instead of drifting into its own vocabulary.

Common Questions

Should the register include risks that have no realistic near-term fix? Yes. A risk with no available near-term control is still a risk, and omitting it from the register because there is nothing to do about it yet just hides the exposure from the people who need to know about it, including anyone deciding whether to expand that agent's access further in the meantime. Record it with a status of "accepted" or "no control available," rather than leaving it out entirely — an explicit acceptance is a decision someone made; a silent omission is not.

How does a risk register differ from an incident log? An incident log records things that have already happened — an actual guardrail violation, an actual credential compromise. A risk register records things that could happen, rated for likelihood and impact, whether or not they ever have. The two should inform each other: a category of risk that keeps generating incidents probably has its likelihood rating understated in the register, and that pattern is itself worth acting on.

Who should have access to the register? The register typically needs to be visible to security, platform engineering, and compliance at minimum, and increasingly to a board-level audience in summary form. Restricting visibility too tightly defeats the purpose — a risk that only the person who wrote the entry ever looks at again is not being actively managed, it is being filed.

What Good Looks Like

  • Every entry references a specific agent or agent category from the current inventory, not a generic statement about AI risk.
  • Likelihood and impact are rated qualitatively with a written rationale, not an invented composite score.
  • Every entry has a linked control with a real status and, if not yet enforced, a dated remediation plan.
  • Review cadence scales with severity, and new agents trigger a review of their risk profile rather than waiting for the next scheduled cycle.
  • The register can be handed to an auditor or a board reviewer as-is, without additional reconstruction, and every claim in it traces back to something verifiable in the inventory or the audit trail.

For how this register fits into a broader program, see what AI agent governance means in practice and an AI governance maturity model, which frames a risk register as one of the artefacts a maturing program produces on the way to full enforcement.