AI agent risk assessment is a structured review that scores a proposed agent — before it is granted access — on how much damage it could do and how well that damage is contained. Rate it on data sensitivity, action reversibility, autonomy level, blast radius, oversight, and auditability, then decide what to allow and what to gate.
Most teams decide what an agent may touch by asking whether it works. That is the wrong question to ask first. An agent that drafts renewal emails flawlessly and an agent that sends them are the same quality of work and two entirely different risks, and the difference is not in the model — it is in what happens when the agent is wrong. Quality tells you whether to keep the agent. Risk tells you what access to grant it, and those are separate decisions made in a separate order.
The problem is that risk usually gets assessed informally, in a hallway, by whoever is nervous — or not at all, because the agent demoed well and the meeting moved on. A hallway is not a record, and “it seemed fine” does not survive the first incident. What a business or security owner needs is a repeatable review they can run on any proposed agent, that produces the same score for the same facts regardless of who runs it, and that ends in a concrete decision: this scope is approved, this action is gated, this data is off-limits.
This post is that template. The six dimensions below apply to any agent from any vendor — they are a way of thinking about consequence, not a product feature. Where the assessment points to a control you actually need, it names the ones an Insulin agent gives you, because a risk you have scored but cannot contain is just a documented fear.
What is AI agent risk assessment?
AI agent risk assessment is the structured review you run on a proposed agent before granting it access, to decide how much authority it has earned and where a human must stay in the loop. It scores the agent on the damage it could cause and how well that damage is bounded, and it produces a decision, not a feeling.
The framing that keeps it useful is that you are scoring a proposal, not auditing something already loose in your systems. At assessment time the agent has no access yet; you are deciding what to grant. That order matters, because every control is cheap to impose before access exists and expensive to claw back after. Deciding the deal-desk agent may never touch HR records is a one-line scope at setup. Discovering it read them last quarter is an incident.
Two rules keep the review honest, and both are easy to skip under demo pressure:
- Assess the worst plausible action, not the intended one. You are not scoring what the agent is for; you are scoring what it could do with the access you are about to grant. The renewal-drafting agent is a sending agent the moment you give it the outbox — score it as one, even if the plan says it only drafts.
- Score the facts, not the vendor’s assurances. “It has guardrails” is not a risk score. Rate the concrete, checkable properties below, and treat a claim you cannot verify as an unmitigated risk until it is proven — the same discipline a good security questionnaire applies to a platform.
The six dimensions of agent risk
Risk is not one number. An agent can be low on five dimensions and catastrophic on the sixth, so score each on its own — a simple low / medium / high per dimension is enough — and let the highest one set the caution level. A single high-risk dimension is not averaged away by five low ones; it is the reason the agent gets gated.
The six dimensions, in the order it helps to think about them:
- Data sensitivity — how bad the information the agent can reach would be to leak or corrupt.
- Action reversibility — whether a mistake can be undone, or is permanent the moment it happens.
- Autonomy level — how far the agent runs on its own before a human sees the result.
- Blast radius — how many records, people, or systems one run can affect.
- Oversight and approval — whether a human can stop a consequential action before it lands.
- Auditability — whether you can reconstruct, after the fact, exactly what the agent did.
The first four measure how much damage is possible. The last two measure how well that damage is contained. A high score on the first four is not disqualifying if the last two are strong — a high-blast-radius action that a human must approve and that leaves a full record is a managed risk. The dangerous shape is the reverse: high consequence, low oversight, no audit trail.
Data sensitivity: what it can reach
Data sensitivity measures the worst outcome if the information the agent can read or write were leaked, exposed to the wrong person, or corrupted. Score it by the most sensitive thing in reach, not the average — an agent connected to ten harmless systems and one containing customer PII is a high-sensitivity agent.
The check is simple to state and easy to get wrong: list every integration the agent is proposed to have, and for each, name the most sensitive record it exposes. Do not score the intended query (“it only looks up order status”); score the access (“it can read the entire orders table, which includes billing addresses”). The access is the risk; the intended query is a hope.
The way you lower this risk is to narrow reach, and reach is a property of the agent, not the person running it. An Insulin agent is configured with an allowlist of the integrations it may use, and scope is the boundary — it cannot reach data outside its granted set. So a high data-sensitivity score is not a reason to reject the agent; it is a reason to grant it fewer, narrower integrations and re-score. Give the support agent read access to the ticketing system and nothing that touches finance, and the sensitivity you were worried about is simply not in reach.
Action reversibility: undo or permanent
Action reversibility measures whether a wrong action can be walked back. Reading a record is fully reversible — the record is unchanged. Sending an email to a customer is not — it is in their inbox the instant it sends, and no amount of correction un-sends it. Score every action the agent can take on this axis, because it is the single strongest predictor of how much a mistake costs.
The useful sort is a two-column list. On one side, the reversible actions: reads, drafts, internal notes, plans, anything that changes nothing a person outside the room will see. On the other, the irreversible ones: sends, external writes, payments, deletions, status changes that trigger downstream automation. The reversible column can run freely; the irreversible column is where your controls belong.
This is exactly the boundary an approval gate is built for. With an Insulin agent, tool execution can be held for approval — nothing runs until a person approves it — so the reversible steps proceed unattended while the irreversible ones wait for a human. That means action reversibility maps directly to a setting: score an action irreversible, and route it through approval; score it reversible, and let it run. The act-versus-ask line and the reversibility line are the same line.
Autonomy and blast radius: how far, how wide
Autonomy level measures how far the agent runs before a human sees anything; blast radius measures how much one run can affect. They are distinct — an agent can be highly autonomous over a tiny scope, or tightly supervised over a huge one — and the combination is what sets the danger.
Autonomy is a spectrum, and it is worth placing the agent on it explicitly. A chat agent that acts one approved step at a time sits at the low-autonomy end: a person is present for every consequential move. A scheduled job that runs unattended overnight sits at the high-autonomy end, because by the time anyone looks, the work is done. Neither is wrong, but they demand different caution — the overnight job’s actions should be the ones you have already decided are safe to run without a watcher, precisely because no one is watching.
Blast radius is about scale. An agent that can update one record when asked has a small blast radius. An agent that can run a bulk operation across a whole table has a large one, and a single wrong instruction there is a large wrong outcome. Lower it the same way you lower sensitivity — through scope — and by keeping the highest-blast-radius actions inside the approval gate, so a bulk change is a human decision even when the single-record version is not. High autonomy times high blast radius is the combination that most deserves a gate; score them together.
Oversight and auditability: the two that contain the rest
Oversight measures whether a human can stop a consequential action before it happens; auditability measures whether you can reconstruct exactly what the agent did after it happens. These are the two dimensions that turn a high-consequence agent into a managed one, and an agent that scores well on the first four but poorly on these two is more dangerous than the reverse.
Oversight is the before control. The question to score is precise: for each irreversible, high-blast-radius action, can a person see the intended action and approve or reject it before it lands? With an Insulin agent, sensitive tool calls pause for explicit approval, and a multi-step task presents its plan for you to approve or reject before any step runs — so oversight is not a promise to review logs later, it is a gate the action cannot pass without a human. The related question of who is even allowed to change the agent’s instructions is role-based access, a separate control that governs people rather than actions.
Auditability is the after control, and it is the one most often missing. The question to score: can you reconstruct, for any run, what the agent was asked, what it decided, which tools it called, and what those calls returned? Insulin jobs carry a full run history — each run records what happened — which is the audit trail an assessment depends on. Without it, every other score is unverifiable: you cannot confirm the agent stayed in scope, cannot prove it escalated when it should have, and cannot answer “what did it do?” when someone asks. Score auditability first among these two, because it is what makes every other claim checkable.
The reusable risk-assessment table
Run this table on any proposed agent before you grant it a single integration. Score each dimension low / medium / high on the facts, apply the mitigation, and re-score. The decision rule is at the bottom.
| Dimension | What to check | How to lower the risk |
|---|---|---|
| Data sensitivity | For every proposed integration, the most sensitive record it exposes — score by the worst one, not the average | Narrow the agent’s integration allowlist so sensitive systems are simply out of reach; grant read where write is not needed |
| Action reversibility | Which actions are permanent the moment they run — sends, external writes, deletions, payments — versus reads and drafts that change nothing | Route every irreversible action through human approval; let reversible steps run unattended |
| Autonomy level | How far the agent runs before a human sees the result — a supervised chat step versus an unattended overnight run | For high-autonomy runs, pre-restrict actions to ones already decided safe without a watcher; keep consequential steps in chat where a person is present |
| Blast radius / scope | How many records, people, or systems one run can affect — a single record versus a bulk operation across a table | Scope the agent to the narrowest data and operations its job needs; keep bulk and high-impact actions behind approval |
| Oversight and approval | Whether a human can see and stop each irreversible, high-impact action before it lands | Require explicit approval on sensitive tool calls and plan approval on multi-step tasks, so the action cannot pass without a person |
| Auditability | Whether you can reconstruct, per run, what was asked, decided, called, and returned | Use an agent whose runs carry a full history, so scope, escalation, and outcomes are all verifiable after the fact |
The decision rule: the agent’s caution level is set by its highest dimension after mitigation, never the average. If any dimension remains high once you have applied every control available, do not grant that access — narrow the scope, add the gate, or keep that action a human’s job — and re-score. An agent moves from “assessed” to “approved” only when nothing on the table is still high, and the assessment itself is the record you keep for when someone asks why the access was granted.
Frequently asked questions
What is AI agent risk assessment? It is a structured review you run on a proposed agent before granting it access, scoring how much damage it could do and how well that damage is contained. Rate data sensitivity, action reversibility, autonomy, blast radius, oversight, and auditability, then decide what to allow and what to gate.
When should you assess an AI agent’s risk? Before granting any access. At assessment time the agent has no reach yet and you are deciding what to grant. Every control is cheap to impose before access exists and expensive to claw back after, so the review happens first, not after an incident.
Which risk dimension matters most for an AI agent? No single one — score all six separately and let the highest set the caution level. A high score on one dimension is not averaged away by the others; it is the reason the agent gets gated. Auditability and oversight are the two that contain the rest.
How do you lower an AI agent’s risk score? Narrow the agent’s integration allowlist so sensitive data is out of reach, route irreversible actions through human approval, and use an agent whose runs carry a full history so every score is verifiable. Then re-score against the tightened setup.
What makes an agent’s risk auditable? A full run history. If you can reconstruct, for any run, what the agent was asked, what it decided, which tools it called, and what they returned, then scope and escalation are verifiable after the fact. Without that record, every other risk score is unprovable.
Takeaways
- Assess risk before quality decides access. Whether the agent works tells you to keep it; how much damage it could do tells you what to grant it — a separate decision in a separate order.
- Score the worst plausible action, not the intended one. An agent given the outbox is a sending agent even if the plan says it only drafts.
- Rate all six dimensions separately and let the highest set the caution level. One high-risk dimension is the reason to gate, not a number to average away.
- The first four dimensions measure possible damage; oversight and auditability contain it. High consequence with strong approval and a full run history is a managed risk — the reverse is the dangerous shape.
- Lower risk with the controls you already have: a narrow integration allowlist puts sensitive data out of reach, approval gates every irreversible action, and a full run history makes every score verifiable.
- An agent is “approved” only when nothing on the table is still high after mitigation — and the assessment is the record you keep for when someone asks why.
Ready to run this on a real agent? See how an Insulin agent is scoped, approved, and grounded, how jobs record every run for a verifiable audit trail, or get a demo.
Sources
Primary sources for the platform rules cited above. Last verified August 20, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger Insulin docs: Agents — Agents are scoped to an allowlist of integrations, and sensitive tool calls pause for human approval before execution.
- Suger Insulin docs: Jobs — Jobs run on a schedule or an event trigger and keep a full run history of what each run did.
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.