AI Agent Risk Register Template

An AI agent risk register is a living record of what can go wrong in an agent workflow, who owns each risk, which controls reduce it, what evidence supports the assessment, and who can accept what remains.

The register turns broad concerns such as “prompt injection” or “bad output” into scenarios that a team can control and review. Each row should describe one cause, one agent behavior or failure, and one possible harm inside a defined workflow and environment.

TL;DR

Build an AI agent risk register in seven steps:

1. Define the agent, workflow, environment, users, authority, and release under review.
2. Write one cause-event-impact scenario per row.
3. Name affected people, assets, systems, rights, and business outcomes.
4. Assess inherent risk before relying on planned controls.
5. Link existing controls to owners and current operating evidence.
6. Assess residual risk, select a treatment, and record the authorized decision.
7. Set review dates and event-based triggers so the register changes with the agent.

Use one row for one risk scenario. Do not combine data exposure, harmful output, excessive authority, and weak monitoring in a single row because they may need different owners, controls, and decisions.

Download the AI Agent Risk Register Template

Download the AI agent risk register template as CSV. It includes 33 fields and two example rows. Replace the example scales, owners, dates, controls, and evidence references with your organization's approved definitions.

The template is educational material, not legal, compliance, security, privacy, audit, or risk advice. Adapt it to your obligations, risk appetite, systems, affected people, and decision process.

Treat every imported field as data, not a spreadsheet formula. Do not paste untrusted ticket, prompt, log, or external-report text directly into the CSV. Before import, reject or neutralize values that begin with =, +, -, @, a tab, or a carriage return, then test the result in the target spreadsheet application. CSV quoting alone does not prevent formula execution.

AI Agent Risk Register Fields

The downloadable template uses these fields:

Field	What to record
Risk ID	Stable identifier that does not change when the wording changes.
Agent ID	The governed agent identity, not only its display name.
Workflow	One task path with a defined trigger and outcome.
Environment	Development, test, pilot, production, or another approved environment.
Initiating principal	Authenticated user, service, schedule, or agent that starts the workflow.
Delegation source	Policy, role, capability, approval, or scoped grant that authorizes action for the principal.
Trace context	Session, task, request, or run reference used to correlate activity without treating it as an authority grant.
Effective authority scope	Data, tools, operations, targets, time, volume, and delegation actually available.
Approval limits	Actions, thresholds, or conditions that require an authorized human decision.
Risk category	The primary category used for reporting and review routing.
Risk scenario	A cause-event-impact statement that another person can test.
Trigger or cause	The condition that could start the harmful path.
Affected parties or assets	People, groups, data, systems, rights, funds, operations, or reputation exposed to harm.
Possible impact	The concrete harm if the scenario occurs.
Control IDs	Stable IDs for separate control records linked to this risk.
Existing controls	Controls operating now, listed in the same order as their IDs.
Control owners	One accountable owner per control ID, in the same order.
Evidence references	Current operating evidence for each control ID, in the same order.
Control verification status	Dated operating result for each control ID, in the same order.
Inherent likelihood	Likelihood rating before relying on the listed controls.
Inherent impact	Impact rating before relying on the listed controls.
Inherent score	Exposure before relying on the listed controls.
Residual likelihood	Likelihood rating after verified controls operate.
Residual impact	Impact rating after verified controls operate.
Residual score	Exposure after verified controls operate.
Treatment	Avoid, reduce, transfer, or accept under approved policy.
Status	Open, treating, accepted, monitoring, blocked, closed, or another governed state.
Risk owner	Person accountable for the risk decision and treatment result.
Acceptance authority	Person or body allowed to accept the residual risk.
Review date	Next scheduled review.
Review trigger	Events that reopen the row before that date.
Last updated	Date of the latest evidence-based change.
Notes	Assumptions, uncertainty, dependencies, and linked records that do not fit elsewhere.

The register should reference source records instead of copying secrets, personal data, raw prompts, unrestricted traces, attacker-controlled text, or sensitive incident material into a broadly shared spreadsheet.

Write a Testable Risk Scenario

Use this structure:

If [condition or trigger], the agent may [specific action or failure],
which could [concrete impact] to [affected people, assets, systems, or rights].

Weak entry:

Hallucination risk

Useful entry:

If retrieved product policy is stale, the support agent may approve a return
outside the current terms, which could create customer harm, financial loss,
and inconsistent treatment across support cases.

The useful entry names a trigger, action, outcome, and affected scope. That gives the team something to prevent, detect, test, monitor, and respond to.

Keep intentional attacks and unintentional failures in scope. An agent can cause the same external harm after malicious prompt injection, stale context, a tool bug, an unavailable approval service, an ambiguous request, or a valid but unsafe sequence of actions. Separate the rows when the causes or controls differ.

AI Agent Risk Categories

A category list helps teams search and report across the register, but it should not limit discovery. Use categories such as:

• Purpose, scope, and prohibited use
• Identity, authentication, and delegated authority
• Context, instructions, retrieval, and policy conflict
• Data access, privacy, retention, and disclosure
• Skills, tools, credentials, and external actions
• Memory, state, and cross-session effects
• Human approval, review capacity, and escalation
• Multi-agent delegation and cascading behavior
• Security, prompt injection, and supply chain
• Reliability, correctness, recovery, and availability
• Cost, rate, resource, and denial-of-wallet exposure
• Legal, contractual, workforce, safety, and rights impact
• Monitoring, evidence, incident response, and retirement

Review the complete workflow, not only the model. The NIST AI RMF Core says teams should map risk across AI system components, assess likelihood and magnitude of impacts, track identified and emergent risks, and document treatment. Agent workflows add changing context, delegated authority, tool execution, Memory, and handoffs to that system view.

Use AI agent threat modeling to find attack and failure paths. Move each material scenario into the register so it receives an owner, treatment, evidence, residual-risk decision, and review trigger.

Assess Inherent and Residual Risk

Inherent risk is the exposure before relying on the controls listed in the row. Residual risk is the exposure after those controls operate as designed and produce current evidence.

A simple method uses likelihood and impact scales from 1 to 5. Define each number before anyone scores a row. For example, impact definitions may consider harm to people, data exposure, financial loss, service interruption, legal duties, and reversibility. Likelihood definitions should state the period, exposure, and evidence used.

Multiplying likelihood by impact can help sort rows, but the result is an ordinal prioritization aid, not a precise probability or loss estimate. Do not let two medium numbers hide a non-waivable requirement, severe plausible harm, high uncertainty, or an impact that policy says must block release.

For each rating, record:

• Scale definitions and version
• Evidence and observation period
• Assumptions and missing data
• Confidence or uncertainty
• Reviewer and review date
• Any severity rule that overrides the numeric score

The NIST AI RMF is voluntary and organizes this work around Govern, Map, Measure, and Manage. NIST states that risk management should continue across the system lifecycle, which means a production score must change when actual behavior contradicts the assumptions used before release.

Link Controls to Operating Evidence

Do not lower residual risk because a control appears in a design or policy. Verify that the control exists in the reviewed environment and works against the scenario.

Useful evidence can include:

• Identity and authorization configuration
• Tool allowlists and argument validation
• Approval records bound to exact actions
• Published context and Skill version references
• Context routing and delivery records
• Test cases, repeated results, and failure traces
• Monitoring rules, alerts, and response exercises
• Downstream transaction or system records
• Incident, recovery, and access-review records

Label evidence by what it proves. A context server record can prove what it compiled and issued. An authenticated host record can support a claim that content entered a session. Neither proves that the model consumed the content or followed it. A successful final output does not prove that an approval, authorization, or other control worked.

Give each control a stable ID, its own owner, its own evidence reference, and a dated verification status. When one risk row links several controls, keep those fields in the same order or link to a separate control register with that structure. Do not lower residual risk when only part of the control set has operating evidence.

The risk owner is accountable for the treatment result, while each control owner maintains the mechanism that reduces likelihood or impact. One person may hold both roles, but the register should not assume that relationship.

Choose and Approve the Treatment

Use one of four treatment decisions:

Treatment	Meaning
Avoid	Remove the action, data, tool, user group, environment, or workflow that creates the risk.
Reduce	Add or improve controls that lower likelihood or impact.
Transfer	Shift an agreed financial or operational consequence through a valid arrangement without claiming the underlying harm disappeared.
Accept	An authorized person accepts the measured residual risk within approved appetite and duties.

Acceptance is a decision, not an empty treatment plan. Record the acceptance authority, evidence reviewed, scope, reason, expiry, monitoring, and conditions that force a new decision. Do not use acceptance to waive law, contract, a non-waivable policy control, risk above approved appetite, or missing evidence needed to understand a material exposure.

High-impact scenarios should block deployment when the team cannot bound authority, enforce required approval, protect secrets, monitor material outcomes, trace material actions, or stop the agent and revoke its access. Use the AI agent deployment checklist to connect those blockers to a specific release.

Example AI Agent Risk Register Row Summaries

These condensed summaries make the cause, controls, evidence, and decision easy to scan. The downloadable CSV contains the complete 33-field rows, including environment, approval limits, category, trigger, affected assets, impact, acceptance authority, review date, update date, and notes.

Example 1: Unsafe external action

Risk ID: AR-001
Agent and workflow: Support agent, send support reply
Initiating principal and delegation: Authenticated support user,
support role grant support-role-grant-447
Trace context: session-support-983
Effective authority: Read assigned case, draft reply, send approved reply;
no account changes and human approval required before send
Scenario: If a crafted ticket causes the agent to send an unauthorized
account-change link, a customer could lose control of an account.
Inherent risk: Likelihood 4, impact 5
Control IDs: CTRL-101, CTRL-102, CTRL-103
Existing controls: Approved-link allowlist, approval-bound send gateway,
no account-change tool
Control owners: Security platform, support platform, support operations
Evidence: ALLOWLIST-TEST-42, APPROVAL-TEST-88, TOOL-INVENTORY-31
Verification: Each control verified on 2026-09-10
Residual risk: Likelihood 1, impact 5
Treatment and status: Reduce, monitoring
Risk owner: Customer Support Director
Review trigger: Tool change, approval failure, or related incident

Example 2: Stale agent context

Risk ID: AR-002
Agent and workflow: Coding agent, dependency update
Initiating principal and delegation: Authenticated engineer,
repository capability grant repo-capability-grant-918
Trace context: task-repo-771
Effective authority: Read assigned repository and propose a branch change;
no merge or deploy, with human review and protected-branch checks
Scenario: If stale repository policy reaches the coding agent, it may create
a change that violates the current release process.
Inherent risk: Likelihood 3, impact 4
Control IDs: CTRL-204, CTRL-205, CTRL-206
Existing controls: Published Knowledge delivered through an Always route,
branch protection, required review
Control owners: Agent context, developer platform, engineering review
Evidence: CTX-DELIVERY-884, BRANCH-TEST-21, REVIEW-TEST-09
Verification: Each control verified on 2026-09-10
Residual risk: Likelihood 1, impact 4
Treatment and status: Reduce, open
Risk owner: Engineering Director
Review trigger: Policy change, route change, or failed delivery check

These numbers are examples, not recommended ratings. Use the definitions and evidence approved by your organization.

Run the Register as a Living Process

Set a regular review cadence based on risk, then reopen a row immediately when its assumptions may no longer hold.

Useful review triggers include:

• Purpose, owner, users, or affected people change
• A model, prompt, Knowledge item, Skill, Memory rule, or retrieved source changes
• Data access, tool authority, credentials, or approval rules change
• Autonomy, schedule, volume, environment, or deployment scope expands
• An agent delegates to a new agent or integration
• A control fails, an exception expires, or evidence becomes stale
• Monitoring finds a new path, trend, impact, or cost pattern
• An incident, near miss, complaint, appeal, or external report reveals a risk
• Law, contract, policy, threat intelligence, or risk appetite changes

The UK government’s AI Risk Management Toolkit provides a multidisciplinary workbook for teams designing, procuring, operating, or delivering AI products. Its release is a useful reminder that the register belongs in ongoing delivery work, not only in a security review before launch.

Assign one role to maintain register quality across the portfolio. That role should check for duplicate scenarios, orphaned owners, expired acceptance, unsupported scores, stale evidence, overdue treatment, inconsistent categories, and agents that operate without current rows.

How the Risk Register Fits With Other Records

The register should connect related work without replacing it:

Record	What it contributes
Agent inventory	Which agents and workflows exist, who owns them, and where they run.
Threat model	Attack paths, failure paths, trust boundaries, and candidate scenarios.
Risk register	Prioritized scenarios, owners, treatments, evidence, residual risk, and review.
Governance checklist	Evidence that required governance work exists for a defined scope.
Security assessment	Findings from review and testing of the current design and implementation.
Deployment record	The release configuration, approval, rollout limits, and recovery plan.
Incident record	What happened, the impact, response, evidence, and corrective action.

The AI agent risk management guide explains the broader program around inventory, assessment, controls, monitoring, and acceptance. This template is the operating record inside that program.

How Alignbase Supports Context-Related Risk Rows

Alignbase is the Agent Operations Platform. It governs and distributes context for supported agents. Teams can version and publish Knowledge and Skills, maintain versioned agent Memory, set independent Always routes, and inspect point-in-time evidence of the context the server compiled and issued.

Those records can support risk rows about missing policy, stale instructions, unauthorized context, unreviewed Skill changes, inconsistent context across agents, and weak delivery evidence. They do not replace identity, authorization, tool controls, testing, risk acceptance, monitoring, or incident response.

Review the Alignbase blog for related guides on agent governance, security assessment, testing, audit, and lifecycle management.