AI Risk Assessment Template: Before You Deploy an Agent
Six questions to answer before an AI assistant or agent gets access to your tools: what data it sees, what it can do, who approves, how it fails, what is logged, and how you undo it. A copyable template, a filled example for an agent with write access to a task board, and where to record the result.
7 min read
An AI risk assessment for an agent is a one-page answer to six questions, written before the agent is connected: what data it can see, what actions it can take, who approves what, how it is likely to fail, what gets logged, and how you undo its work or switch it off. Answer each in a line or two, name an owner, set a date to look again, and record the decision where the team and the agent will both see it. The template below does that for one agent at a time; a filled example for an agent with write access to a task board follows it.
This is narrower than two neighbors. Whether the team as a whole is ready is the AI agent readiness checklist, and the recurring check on access already granted is the security review of an AI agent’s access. This page is the gate in between: one agent, one set of tools, before it starts.
The six questions
1. Data: what can it read, and where does that go?
List every system it connects to and the most sensitive thing in each: customer names, contracts, credentials, health or financial data. Then say where that data goes when the agent reads it: to the model provider, into logs, into a vendor’s memory feature. The joint guidance on AI data security (opens in a new tab) from CISA, the NSA and the FBI is a useful prompt for the questions to ask a vendor.
2. Actions: what can it change?
Separate read, write and irreversible actions. Write means creating or editing records; irreversible means sending, deleting for good, paying or publishing. Give the agent the narrowest scope that does the job, and prefer a role of its own over borrowing a person’s full access.
3. Approvals: who says yes, and to what?
Name the person who approved the connection and the actions that still need a person each time. The MCP specification (opens in a new tab) says there “SHOULD always be a human in the loop with the ability to deny tool invocations,” and that clients must treat a server’s tool annotations as untrusted unless the server is trusted. So write down what your client will actually ask you to confirm, rather than assuming it will.
4. Failure modes: how will it go wrong?
Pick the three or four that fit. Common ones: it states something false as fact; it acts on instructions hidden in content it read, known as indirect prompt injection; it does the right thing to the wrong record; it does far more than asked; people stop reading what it produces. For each, say what would limit the damage.
5. Logging: how will you know what it did?
The test is whether you can tell the agent’s changes from a person’s after the fact. If a tool records everything under the person who connected it, you cannot. Note where the log is, how long it is kept, and who reads it and how often.
6. Rollback: how do you undo it and switch it off?
Two separate answers. Undo: can you restore what it deleted or changed, and how. Switch-off: who revokes its access, where, and how fast. If nobody can answer the second in one sentence, the agent is not ready.
The template
AGENT RISK ASSESSMENT Agent / client: <which assistant, which app or CLI> Connects to: <each system> Job: <what it is for, in one sentence> Not for: <what it must not be used for> Owner: <person> Review by: <date> 1 DATA Can read: <systems, and the most sensitive data in each> Data goes to: <model provider, logs, memory, other> Never gets: <data it must not see> 2 ACTIONS Read: <yes / scope> Write: <what it can create or change> Irreversible: <send, delete, pay, publish: allowed? blocked?> Access model: <own role / borrows a person's access> 3 APPROVALS Connection approved: <person, date> Needs a person each time: <actions> Client confirms: <what the client actually prompts for> 4 FAILURE MODES <failure> -> <what limits the damage> 5 LOGGING Where: <log or history> Agent named separately? <yes/no> Read by: <person, how often> 6 ROLLBACK Undo: <how changes are restored> Switch-off: <who revokes, where, how fast> DECISION: <go / go with limits / not yet>, decided by <person>
Filling it in, in half an hour
- Have the person who wants the agent draft it, since they know the job. Have someone else, ideally whoever would switch it off, read it.
- Start with rollback. If the switch-off line is blank, stop there and fix that first; everything else can be tightened later.
- Fill in actions from what the tool actually grants at sign-in, not from what you intend to use. Scopes you did not need are the cheapest risk to remove.
- For the approvals line, try it: connect the agent to a test project and see which calls your client asks you to confirm.
- Write the decision as go, go with limits, or not yet, and name the person who decided. “Go with limits” is the usual answer, and the limits become rules.
- Redo it when the agent gets a new tool, a wider scope or a new kind of data, not only on the review date.
A filled example: an agent with write access to a task board
Here is the template filled in for a coding assistant that files and updates tasks on a fenbs board over MCP. The fenbs details are the product’s own: sign-in scopes, a role for the assistant, History, and restore.
Agent / client: Claude Code, one developer's machine
Connects to: fenbs board "Website", over MCP
Job: file bugs found while coding, update the plan
and test status on tasks it works on
Not for: closing client-reported tasks, deleting tasks
Owner: Dana (tech lead) Review by: December 1, 2026
1 DATA
Can read: every task on this board, incl. client comments
Data goes to: the model provider, per our existing agreement
Never gets: passwords or keys; none are kept on the board
2 ACTIONS
Read: yes
Write: add and change tasks, comment (scopes ticked
at sign-in)
Irreversible: delete is restorable, but attached files are not;
rule says ask first
Access model: own role from the board's AI Assistants tab,
narrower than Dana's
3 APPROVALS
Connection approved: Dana, September 29, 2026
Needs a person each time: moving a task to Completed, deleting
Client confirms: fenbs sets no tool annotations yet, so the
client cannot tell its reads from its writes;
keep per-call approval on
4 FAILURE MODES
files duplicates -> server holds back likely duplicates
obeys text in a
client comment -> comments are data, not instructions (rule)
marks work done that
is not -> a person moves tasks to Completed
5 LOGGING
Where: task History Agent named separately? yes
Read by: Dana, weekly
6 ROLLBACK
Undo: restore deleted tasks; History shows what
changed so it can be put back by hand
Switch-off: Dana revokes the connection in Settings,
same day
DECISION: go with limits, decided by DanaMapping it to the NIST AI RMF
If a customer asks how this relates to the NIST AI Risk Management Framework (opens in a new tab), the mapping is light. The owner, the approvals and the decision are Govern. Data, actions and failure modes are Map. Logging and the weekly read are Measure. Rollback and switch-off are Manage. The framework itself, its Playbook and the Generative AI Profile are explained in NIST AI Risk Management Framework for small teams, so they are not repeated here.
If the agent touches decisions about people in the EU, such as hiring, read human oversight under the EU AI Act before you fill in the approvals line.
Recording the outcome where the agent will read it
An assessment kept in a folder protects nobody once the agent is running. On fenbs, record the outcome on the Decisions and rules page. The go or no-go is a decision: the question, what was decided, why, the options turned down, and who decided. The limits that come out of it, such as “ask before deleting a task” or “a person moves tasks to Completed,” are rules, decisions that hold from now on. The decider is always a person, never the assistant. Every connected AI assistant reads the rules first, before the AI context notes and before it touches a task, and changing a rule means recording a new decision that supersedes it, so the history stays. fenbs does not score risk or keep a risk register; the template above is yours.
Related
Scopes and roles in detail: roles and permissions for humans and AI agents and assistant tokens and scopes. When something goes wrong: AI agent incident response. The one-page policy above all of this: AI agent governance for small teams.