WHAT SCOPING DOESN'T TOUCH

VSR-01 and VSR-02 both improve access control: narrower grants, better bound to runtime. This report asks a question that has to be answered before either of those improvements gets credited with fixing anything: does the failure in front of you fall inside the territory access control governs at all? ChatSee.ai's State of Enterprise AI Failures 2026 found the largest single failure category, 31.1 percent of over 10,000 observed events, is resolution and escalation breakdowns, a completion-quality failure with no access-control dimension. The Control Coverage Map exists to stop that category, and others like it, from absorbing identity-and-access remediation budget it cannot benefit from.

When "AI safety" and "AI security" both route through the same governance conversation, and the loudest, best-funded, most demoable part of that conversation is access control, there's a structural pull toward treating every failure as an access-control problem, because that's the lever with a vendor, a product, a survey, and a compelling incident-rate number behind it. The pull is not malicious. It's the natural consequence of one part of the problem having excellent tooling and the rest not having any.

The result is a category error with real cost: an organization tightens permissions, adds an identity platform, runs an audit (all genuinely useful work, per VSR-01 and VSR-02), and then is surprised when its failure rate doesn't move, because the failures it was actually experiencing were never access failures in the first place.

This issue's main-issue essay ("The Failure That Wasn't a Hallucination") laid the groundwork: hallucination accounts for under 10 percent of observed enterprise AI failures; resolution and escalation breakdowns account for 31.1 percent, the largest category; execution and action failures rose 62 percent against a Q2 2024 baseline. Access control, however well implemented, addresses roughly one category directly (governance failures) and partially addresses a second (execution/action failures, by limiting blast radius). It does not touch resolution/escalation breakdowns, hallucination, retrieval failures, response failures, or goal-scoping failures: five of roughly seven named categories, including the largest one.

This report formalizes that mapping into a reusable instrument, so an operator can run it against their own failure log rather than trusting DFEI's read of an industry-wide dataset. The terminology collision the main issue names, ChatSee's "scoping failure" (task/goal scoping) versus the identity industry's "scoping" (access scoping), belongs here specifically, because it is the exact confusion that lets a permission-control fix get proposed for a goal-drift problem.

Is the failure I'm trying to fix actually an access failure?

An access failure is one where the agent reached something it should not have been permitted to reach, or took an action outside its authorized scope. Everything else (task misunderstanding, incomplete resolution, hallucinated content, retrieval error, output-quality issue) is a different kind of failure, however much it may resemble an access failure in a postmortem written by someone reaching for the tool they already have.

5.1 The seven-category reference set

Drawn from ChatSee's State of Enterprise AI Failures 2026 taxonomy, as reported: resolution/escalation breakdowns, execution/action failures, hallucination, retrieval failures, task/goal-scoping failures, governance failures, response failures. (Category-level shares beyond the three headline figures were not fully available in the source excerpt DFEI worked from, see Section 11.)

5.2 Coverage classification

Each category is marked against access/permission control:

• Addressed: the failure is, definitionally, an access-control failure (an agent reached something unauthorized).
• Partially addressed: access control limits the consequence but does not prevent the failure itself.
• Untouched: access control has no mechanism relevant to this failure class.

5.3 The two senses of "scope"

Named explicitly because conflating them is the mechanism by which coverage gets overstated. Access scope is what an agent is permitted to reach (the identity-industry sense), addressed by VSR-01/VSR-02's tools. Goal scope is what an agent correctly understands itself to be doing (a task-definition and reasoning problem), addressed by prompt/task design and evaluation, not by identity infrastructure. A "scoping failure" in ChatSee's taxonomy is the second kind. A vendor pitch that says "scoping" without specifying which kind is either simplifying honestly or eliding the gap this report is about.

Category substitution

A failure is filed under "security" or "governance" by default, because that's the team and tooling with capacity, even when its actual mechanism belongs to a different category entirely.

Coverage overstatement

A vendor or internal team claims a governance/identity initiative "addresses AI failure risk" broadly, when the honest claim is narrower: it addresses the subset of failure risk that is access-shaped.

The scope-word collision

A remediation plan targets "tightening scope" in response to a goal-drift incident, implementing access restrictions that do nothing to the reasoning process that produced the drift, because the word "scope" pointed the fix at the wrong layer.

For any incident or failure-log entry:

Purpose

Sort an operator's own failure log by whether access/permission control is the relevant lever, before allocating remediation effort.

Use when

• After any incident, before deciding which team or tool owns the fix.
• Reviewing a vendor's governance-platform pitch against your actual failure distribution.
• Auditing whether past remediation spend went to the categories actually producing failures.

What it creates

A failure log re-tagged by coverage classification (addressed / partially addressed / untouched), surfacing what share of total incidents access control can plausibly move.

Technical version

control_coverage_map:
  failure_id:
  category:              # resolution_escalation | execution_action | hallucination | retrieval | goal_scoping | governance | response | other
  access_dimension_present: true|false
  coverage_classification: addressed | partially_addressed | untouched
  scope_word_used:        # access | goal | unspecified | n/a
  remediation_owner:

Manual / no-code alternative

Tag each failure-log row with the seven-category reference set, then a second column for the three-way coverage classification; sum by category to see where access control can and cannot move the needle.

Output

A percentage: how much of the actual observed failure volume access control addresses, against how much of the current remediation budget is being spent on it.

Failure prevented

Expanding access-control tooling to "fix" a failure category (like resolution/escalation breakdowns, the largest observed class) that access control was never built to touch.

Before tightening access, confirm the failure you're fixing is an access failure.

A customer-service agent fails to resolve a billing dispute: it correctly reads the account, correctly stays within its authorized read/write scope, and closes the ticket as resolved when the underlying issue was never fixed. Run the coverage map. Step 1: no unauthorized reach. Not an access failure. Step 2: the action taken (closing the ticket) was within authorized scope but was the wrong action given the actual state of the issue: a resolution/escalation breakdown, ChatSee's largest category. Step 3: confirmed untouched by access control. The correct remediation owner is the team responsible for the agent's completion-verification logic, not the identity/access team, and no amount of tightening the agent's permissions would have changed this outcome.

This report's seven-category reference set is drawn from ChatSee's reported taxonomy; DFEI's terrain research had direct figures for three categories (hallucination <10%, resolution/escalation 31.1%, execution/action +62% vs. baseline) and named-but-unquantified figures for the remaining four. Operators applying this tool to their own logs should build their own category shares rather than assuming ChatSee's distribution transfers directly. Industries and deployment types vary, a point ChatSee's own report makes explicitly. This report also does not resolve how to fix an untouched-category failure, only that access control is not the fix. The actual remediation (task design, evaluation, retrieval quality) is outside this report's scope, appropriately.

Access control is real, valuable, and, per VSR-01 and VSR-02, worth doing well regardless of anything else in this issue. It is also, by structure, a partial answer to a seven-part problem. The Control Coverage Map exists so that partial answer doesn't get budgeted, staffed, and marketed as if it were the whole one. The largest category of enterprise AI failure right now has no access dimension at all. No identity platform will show up in its postmortem, because nothing about the failure involved unauthorized access. Confirm which failure you have before reaching for this issue's most fundable fix.

DFEI.010 :: VSR-03 :: What Scoping Doesn't Touch Dispatches From Emerging Intelligence