The Chief Risk Officer's Guide to AI Agents

Risk functions are asked to challenge agent deployments before the organization has a settled way to think about them, often with an engineering team on one side and a business sponsor on the other. This guide gives chief risk officers the taxonomy question, the appetite structure, the challenge questions that matter, and the aggregation view that no single deployment assessment provides.

Does agent risk need a new taxonomy?

Usually not. Agent risk expresses itself through categories the function already has:

Existing category	How agents express it	New failure modes to add
Operational	Wrong actions in processes	Probabilistic behavior; drift after deployment
Conduct	Poor customer outcomes at scale	Confident wrong answers; unfair patterns
Information security	New access paths and identities	Prompt injection; tool compromise
Third-party	Dependence on providers	Model deprecation; unannounced behavior change
Compliance and legal	Automated decisions, disclosure	Explainability gaps; records
Strategic	Competitive and business model	Concentration on a provider

Adding agent-specific failure modes and controls within existing categories keeps risk reporting coherent and avoids a parallel governance structure nobody reads. The AI risk explained for executives piece maps the categories to owners.

How should appetite be expressed?

In terms that can be enforced and tested. The second line's most valuable contribution is often translating a general appetite statement into:

• Autonomy ceilings per consequence tier: which action classes may run without a person, and the evidence required.
• Error tolerances per output destination: internal reviewed, internal unreviewed, customer-facing, action-taking.
• Data rules: which classes may reach which models under which contracts.
• Limits: spend, rate, and step limits per agent.
• Prohibitions that hold regardless of evidence.

The how to set AI risk appetite guide gives the drafting method; the test is whether an engineer could implement it and an auditor could check it.

What should second-line challenge cover?

Before deployment, not after. The questions that find real problems:

1. What can this agent do, and is that the minimum for its job? Over-broad permissions are the most common finding.
2. What could it do if compromised or simply wrong? This is the actual exposure, regardless of testing quality.
3. How was the evaluation set built, and does it represent production inputs? A set built from easy cases proves nothing.
4. What happens on each failure mode? Drift, injection, stale data, loops.
5. Who reviews what, and will they actually do it? Review that exists on paper but not in the workflow is not a control.
6. How is it detected and stopped? Monitoring, alerts, and a tested kill switch.
7. Does the proposed autonomy sit within appetite?

The questions executives should ask about AI agents guide extends this list for the first line.

Why does aggregation matter more than individual assessments?

Because the individually low-risk agents share dependencies. Twenty agents each assessed as low tier may all run on one model provider, through one connector, over one data source, reviewed by one small team. A model update, a connector failure, or a data change then degrades twenty processes at once, and no single assessment predicted it.

Risk should track shared dependencies as concentrations: by model and provider, by connector and data source, by platform component, and by reviewer pool. This is the view the second line is uniquely positioned to provide, and it is usually absent from first-line reporting.

What scenarios should be run?

• Correlated model change: a provider updates a model and several agents degrade simultaneously. Detection time is the question.
• Compromise: prompt injection reaches an agent with broad permissions; what could be done before detection?
• Upstream data corruption: a field changes and dependent agents act on wrong inputs.
• Vendor outage or exit: how long to switch, and what is unavailable meanwhile?
• Public incident: a customer-facing failure reaching regulators and media at once; test the response, not just the control.

Test detection and response, not only prevention, because probabilistic systems will produce failures the controls did not anticipate. The AI agent failure modes for executives piece catalogs the modes.

What should risk reporting contain?

Inventory by tier with changes; autonomy changes made and the evidence cited; evaluation and drift indicators for material agents; incidents with detection times; concentration by model, provider, connector, and reviewer pool; scenario results; and appetite breaches with remediation. Consistent format so the trend is visible. The AI risk register guide gives a starting artifact.

What should chief risk officers ask?

• Is agent risk in our taxonomy, or in a separate document nobody reads?
• Is our appetite enforceable, and could an auditor test it?
• Which shared dependencies create concentration across our agents?
• How quickly would we detect a provider model change degrading several agents?
• Has second-line challenge changed any deployment before go-live this year?

How can FISTA Solutions help risk functions?

FISTA Solutions builds AI agents with permissions, gates, evaluation, and monitoring that second-line challenge can test, and works with risk leaders through its AI enablement practice to translate appetite into enforceable ceilings, build the aggregation view, and run failure scenarios before deployment. Since 2017, FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

To build an aggregation view of your agent estate, talk to FISTA on WhatsApp, or read AI risk management for the framework.