Agentic Cyber

Agentic AI Risk Management: A Six-Step Programme Built on the NIST AI RMF

By Mara Voss · November 6, 2026

Category: defensive-architecture-security-controls

Agentic AI Risk Management: A Six-Step Programme Built on the NIST AI RMF

A six-step agentic AI risk management programme from inventory to incident response, tied to the NIST AI RMF and the Playbook, with the option many teams forget: avoid the agent.

Key takeaways

  1. The problem Agent risk shifts whenever a tool, data source or user group changes, so one-off assessments go stale within weeks.

  2. Core insight NIST's response options include avoiding a risk, which agent programmes rarely choose even when a smaller design would remove it.

  3. Practical outcome You get six steps with deliverables, a thirty-sixty-ninety day start and a five-line quarterly report shape.

An agent that books travel and an agent that merges code are different risks, but many programmes record both under one line labelled "AI". Managing agentic risk is ordinary risk work with three adjustments. The thing you rate is an agent with tools. Your best evidence is behaviour observed while it runs. And the rating expires whenever a tool, a data source or a user group changes.

What follows is a programme small enough for a few people to launch, built as six questions that it must be able to answer. It follows the NIST AI Risk Management Framework (released 26 January 2023) and its Generative AI Profile, NIST-AI-600-1 (26 July 2024), which NIST presents as voluntary (NIST AI RMF). ISO/IEC 42001 sits alongside as a certifiable management system. Treat the text as technical guidance and not as legal or compliance advice.

Why not a single assessment

Risk for an agent is a product of its tools, its data and its users, and all three keep moving. One new MCP server, one new document source or one team adopting the agent changes the answer. A report written once ages in weeks. A programme makes re-rating routine and puts a named person behind each agent.

Question one: which agents exist?

Build the census first: every agent in production or pilot, with owner, purpose, tools, data and credentials, including purchased products and agents people installed themselves. The NIST Playbook's MAP 5.1 asks for the likelihood and magnitude of each identified impact to be identified and documented, which cannot be done for an agent that is not on the list (NIST Playbook, Map). The method is in inventory before controls. Review the census monthly.

Question two: who is answerable?

Settle accountability in a single page. State what agents are for, what needs approval, who approves a new one and who may switch one off. Name a sponsor at executive level and an owner per agent. MAP 3.5 in the Playbook expects processes for human oversight to be defined, assessed and documented under the organisation's governance policies (NIST Playbook, Map).

Question three: what could go wrong, and how badly?

Keep a register with one row per risk per agent, carrying exposure and impact marks, the chosen control and the proof. Our risk register works as a template. Sort agents by their worst credible outcome and give each top risk an owner and a date.

Question four: what did we do about it?

Apply protections in a sensible order. Identity, narrow credentials and limits on reach come before policy checks, isolation and supply chain vetting. Ten controls in build order gives a sequence, and each control should leave behind proof that it exists.

Question five: how do we know it works?

Pick measures that need no heroics. Useful ones include the share of agents with an owner and a unique identity, the share of credentials that expire quickly, how many agents read untrusted content while holding write rights, when each high-risk agent's stop control was last tested, how canary injection tests fare, and how long a vendor fix takes to reach production. Add red team work on a calendar and feed what it finds into regression tests. Plot the trends.

Question six: what happens when it fails?

Write the response plan for misuse and compromise: halting an agent, revoking credentials, keeping logs, telling the right people. MANAGE 4.1 in the Playbook expects post-deployment plans to cover appeal and override, decommissioning, incident response, recovery and change management, and MANAGE 4.3 expects incidents to be communicated, tracked and recovered from (NIST Playbook, Manage). The agent-specific detail is in incident response for agentic AI. After each incident or near miss, update the register and the controls.

How the questions map to NIST

Questions one and three live mostly in Map, two in Govern, five in Measure, and four and six in Manage. The same answers give you evidence for ISO/IEC 42001 as well, a point developed in ISO 42001 for agents.

Do not forget the option to avoid

MANAGE 1.3 lists four responses to high-priority risks: mitigate, transfer, avoid or accept (NIST Playbook, Manage). Agent programmes reach for the first one every time. They almost never choose the third, and so nobody asks whether the agent should exist in its current shape.

That habit costs more than it seems. Some designs cannot be made safe enough by controls, because a single session combines private data, untrusted input and an outbound channel. For those, the cheapest control is a smaller agent: drop the outbound channel, split the job in two, or keep a person in the loop.

Avoid is the right call when the worst credible outcome is severe, no scoping or approval can cap it, and the business value does not depend on that exact design. Accept fits small, reversible harms. The position fails where the value is the broad autonomy itself, as with a general assistant. There the choices narrow to mitigation and acceptance, and the sponsor should sign the residual risk in plain words.

The first ninety days

Spend the first month on the census, the owners, the one-page policy and a first register for the highest-impact agents. In the second month repair identity and credentials for the top-scoring risks and run the first canary tests. In the third, put a checkpoint in front of high-impact tools, test the stop control, hold a first incident drill and publish the first quarterly report.

A report leaders can use

Keep it to five lines: how many agents run and how many are high impact; how many lack an owner or a distinct identity; the top risk with its control and what remains; the latest drill and the time it took; and the specific decisions you need. A report of activity counts rarely gets a decision, while this shape does.

Where programmes go wrong

  • They map to a framework before an inventory exists.
  • They rate risk once for "the AI programme" instead of per agent.
  • They measure activity, such as policies written, instead of outcomes, such as credentials shortened.
  • They leave vendor and plugin risk to procurement alone.
  • They treat the first drill as the last.

Unknowns

  • Which measures regulators and customers will request; standards work is still in progress.
  • Reliable benchmarks for the measures above, so track your own trend first.
  • Effort per agent, which varies widely enough that we offer no universal figure.

Policy and law are covered in the governance guide.

Risk programme FAQs

Frequently Asked Questions

Do we need a dedicated team?

Not at the start. A security lead and part-time agent owners can run the first steps.

Is the NIST AI RMF mandatory?

NIST describes it as voluntary. Contracts or regulation may still point to it.

How is this different from general AI risk management?

The unit is an agent with tools and credentials, so tool permissions, identity and run-time evidence take centre stage.

When should we avoid an agent design?

When the worst credible outcome is severe, controls cannot cap it, and the business value does not need that exact design.