NIST AI RMF and ISO 42001 Won't Stop Your Agent From Deleting the Wrong Records

Does NIST AI RMF Prevent Excessive Agency Incidents? No, and Here's the Gap

Someone on your team asked this question after a close call, or maybe after reading the OWASP LLM Top 10 and getting nervous. Fair. The honest answer: NIST AI RMF and ISO 42001 give you a governance vocabulary, a documented risk process, and something to show an auditor. Neither one tells you what your support agent can actually do to a customer record in your CRM at 2am with nobody watching.

That's not a knock on the frameworks. NIST AI RMF's Govern and Manage functions are genuinely useful for structuring how your org thinks about AI risk. ISO 42001 gives you a certifiable management system. Both are worth having, especially if you're selling into enterprise and need the paper trail. But a framework describes categories of risk. It does not enumerate the specific read, write, update, and delete permissions your agent has in your billing system, your ticketing tool, or your customer database. Compliance on paper and a scoped agent in production are two different artifacts, and only one of them stops an incident.

What Excessive Agency Actually Looks Like in a Real Workflow

Excessive agency is OWASP's term for it, and it's the right one: an agent ends up with more functional capability than the task requires, usually because nobody drew a hard line around what it was built to do versus what the underlying integration lets it do.

Here's the workflow that trips almost everyone up. You build an agent to resolve support tickets: read the ticket, look up the account, update the status, maybe issue a refund under some dollar threshold. Reasonable scope. But the API credential you wired it up with was the same one your support team uses for everything, because that was faster to ship. Now the agent that was supposed to update ticket status can also merge duplicate accounts, bulk-edit billing records, and delete a customer profile flagged as a dupe. Nobody granted that permission on purpose. It came bundled with the access token, and nobody wrote down what the agent should be blocked from doing, only what it was supposed to do.

The failure isn't malice or a model going rogue. It's an agent doing exactly what an ambiguous instruction plus a broad permission set allows it to do. That's excessive agency in one sentence: legitimate reason to touch one thing, implicit permission to touch ten others.

We've written about this failure mode in more depth here: Excessive Agency Is the Security Failure Nobody Scoped. Worth reading if you want the full mechanics, prompt injection angles included.

The Fix Is a Document, Not a Framework

The artifact that actually prevents this is boring and specific: a written authorization map, produced before deployment, for every agentic workflow you ship.

For each workflow, it should answer four questions in writing:

• What data can it read? Named tables, fields, or record types, not "customer data."
• What actions can it take? Update status, draft a reply, issue a refund under $50. Named actions, named limits.
• What is it explicitly blocked from? Delete, merge, bulk-edit, anything touching PII fields it doesn't need. Write the negative space down; don't assume it's implied.
• Who signed off, and when? A name and a date, not a Slack thread that scrolled away.

This isn't a compliance checkbox. It's closer to a least-privilege access review, except most teams doing their first agentic build skip it because the workflow feels small and low-risk. It's low-risk right up until the agent's blast radius includes records nobody meant to expose it to. The authorization map is what you produce before that happens, not the incident report you write after.

If your evaluation process is still "seems fine" in a demo, that's a related gap worth closing at the same time. We cover that here: "Seems Fine" Isn't a Metric.

Why This Matters More Right Now Than It Did Six Months Ago

Mid-year is when the math changes. Teams that shipped a first agentic workflow earlier this year are now deciding what to scale next, and the honest pattern we see is: workflow one got built carefully, under scrutiny, with someone watching every step. Workflow two and three get built faster, reusing the same credentials, the same integration patterns, the same "it worked last time" assumptions. Agent count goes up. Blast radius goes up with it. Authorization scope creep compounds quietly, because nobody re-scopes permissions when they copy a pattern that already shipped.

This is exactly the moment to write the authorization map down, before you're running five agentic workflows against three systems with permissions nobody can fully trace back to a decision. We go deeper on why the second and third workflows carry more governance risk than the first in Why Your Second AI Workflow Needs Governance the First One Never Had and Why Your Second AI Workflow Is More Dangerous Than Your First.

This Is a Two-Week Problem

Here's the part that should be reassuring: producing a real authorization map, for your first agentic workflow or your fourth, is not a six-month governance initiative. It's scoping work. You can do it in two weeks if you're specific about the workflow, the systems it touches, and who has authority to sign off.

That's the shape of our AI Opportunity & Readiness Sprint: two weeks, fixed fee, and the output is an executable plan plus the authorization map itself, not a slide deck telling you AI is important. We've done the version of this work that ships; PolicyFlow went from prototype to a production insurance data-intake workflow in three months with one senior engineer and an AI co-pilot, and the scoping discipline (what it could touch, what it couldn't) was decided before a line of production code shipped, not after.

Get the Authorization Map Before You Ship the Next Workflow

Download the case study on how we scope and ship production AI workflows, PolicyFlow included, to see what a real authorization map and rollout plan look like in practice. Or book an AI Opportunity & Readiness Sprint and get your next agentic workflow mapped, authorized in writing, and ready for production before you scale to the one after it. Start at horizontwolabs.com.