THE SCOPE THAT WAS TOO WIDE

DFEI.010 argues that access control is being sold as a complete answer to trajectory risk when it addresses only one layer of it: what an agent is permitted to reach. This report takes the first and most tractable slice of that layer: the grant itself, made once, before any trajectory runs. Teleport's 2026 Infrastructure Identity Survey found a 4.5x incident-rate gap between least-privileged and over-privileged AI systems (17% vs. 76%). The survey shows a correlation between privilege level and incident rate; it does not isolate which mechanism drives it. Unused, never-exercised grants are a plausible contributor worth auditing regardless of whether they're the whole explanation. The Grant-vs-Use Gap Audit exists to make that unused margin visible before it becomes an incident, by treating every unexercised grant as a cost with no matching benefit.

Access is usually provisioned for the task an agent might need to do, not the task it actually does. That gap between possible and actual use is invisible under normal operation. An over-provisioned agent behaves identically to a correctly-provisioned one right up until something goes wrong inside the unused margin. Nobody notices the extra scope because nothing has exploited it yet. That is exactly the condition the Teleport incident-rate data is describing: the difference between a 17 percent and a 76 percent incident rate is not a difference in what agents were asked to do. It is a difference in what they were allowed to do beyond that.

Provisioning teams default wide for a reasonable-sounding reason: narrowing access later, once a real limitation surfaces, is friction; granting wide up front avoids a support ticket. That reasoning treats unused scope as free. It is not free. It is deferred, unpriced risk sitting on the balance sheet until an agent's trajectory, through a goal-drift, a compromised tool call, or simple correct-but-unanticipated behavior, reaches into it.

The coverage window's identity-security buildout (SailPoint's Agentic Fabric, Rubrik's Agent Identity, Okta's CISO survey naming agent governance a board-level crisis) is entirely a response to this problem at the infrastructure level. What none of those product launches supply is an audit method an operator can run today, without buying a platform, to find out how wide their own current grants already are. This report supplies that method as a standalone worksheet, independent of any vendor's identity fabric, so the finding does not have to wait on a procurement cycle.

It also sets up the rest of this issue's VSR stack: a grant that is too wide is the precondition for VSR-02's runtime-binding problem (a wide grant is exactly what makes design-time trust dangerous) and VSR-04's lifecycle problem (a grant that was appropriately wide at creation and stayed that way as the agent's purpose narrowed).

How much of this agent's granted access has never been used?

The question deliberately does not ask "is this access dangerous?" That requires predicting a future incident. It asks a fact that is already knowable from an access log: what was granted, and what of that has actually been exercised. Unused scope is the audit's finding; whether it should be revoked is the operator's decision, informed by that finding.

The audit runs on three inputs per agent, over a defined review window (30 or 90 days recommended):

5.1 Granted capability set

The full list of systems, data stores, tools, and actions the agent is technically permitted to reach: the provisioning record, not the agent's own self-description of what it does.

5.2 Exercised capability set

The subset of the granted set the agent actually invoked during the review window, drawn from execution logs, not from intent or design documents.

5.3 The gap

Gap = Granted − Exercised

Every item in the gap is a capability that contributed zero observed value during the window and carries the full incident risk of having existed. The gap is not automatically wrong. Some capabilities are legitimately rare-but-necessary (a monthly reconciliation job, a disaster-recovery path), but every item in it now requires an explicit justification rather than defaulting to silent approval.

Provisioning for the imagined worst case

Access is sized to the most demanding scenario anyone can imagine the agent facing, rather than the scenario it actually faces, on the theory that it's better to have it and not need it. The audit inverts that theory: having it and not needing it is the exact condition the incident-rate data punishes.

Grant sprawl through iteration

An agent's permissions accumulate additively as its capabilities are extended over time (a new tool added here, a new data source there), and nothing ever subtracts the access from an earlier, narrower version of the task. The gap grows monotonically unless something forces a review.

Confusing "might need" with "does need"

Provisioning teams reasonably want to avoid repeated access requests, so they grant for a horizon of possible future tasks rather than the current one. The audit does not argue against provisioning for known future needs. It argues that "possible future need" has to be named and justified, not assumed by default width.

Run this against any agent identity with production access:

Purpose

Convert a provisioning record and an execution log into a single, defensible list of unjustified access.

Use when

• Onboarding an existing agent identity into a governance program for the first time.
• After any incident, to check whether unused scope was part of the exposure even if it wasn't part of the cause.
• On a recurring cadence (recommended quarterly) as a standing discipline, not a one-time cleanup.

What it creates

A ranked list of unused capabilities per agent, each tagged justified / unjustified / needs-owner-review.

Technical version

grant_use_gap:
  agent_id:
  review_window_days:
  granted_capabilities: []      # full provisioning record
  exercised_capabilities: []    # from execution logs
  gap: []                       # granted - exercised, computed
  gap_items:
    - capability:
      justification:            # known-future-need | rare-but-real | none
      owner:
      decision:                 # retain | revoke | pending

Manual / no-code alternative

A two-column spreadsheet: granted capabilities down the rows, a checkbox for "exercised in window," with unchecked rows sorted to the top as the review queue.

Output

A short list an owner can act on directly: revoke, justify, or flag for the next review. Not a security report that gets filed and not read.

Failure prevented

Standing "just in case" access that contributes nothing to task completion but sits inside the blast radius calculation the whole time.

If a granted capability hasn't been exercised in the review window, its risk is already priced in and its benefit is not.

Apply the audit to a customer-support agent granted read/write access to the full CRM, billing system, and internal ticketing queue at deployment: a reasonable-sounding bundle for "handles customer issues end to end." A 90-day exercised-capability pull shows the agent has never written to billing; every resolved ticket routed through read-only billing lookups and CRM writes. The billing write permission is the gap: zero observed benefit, full standing exposure to a billing-system incident if the agent's trajectory ever goes wrong in a way that reaches it. The audit does not say the permission was wrong to grant. A future billing-adjustment feature might genuinely need it. It says the permission needs an owner and a justification now, rather than continuing to exist by default.

This report finds unused scope; it does not evaluate whether the used scope was exercised safely. That is a runtime question, addressed in VSR-02. It requires an execution log detailed enough to distinguish capabilities, not just a coarse "agent ran successfully" record; where that instrumentation is missing, the audit's first finding is the instrumentation gap itself. It also does not resolve the judgment call of whether a rare-but-real future need justifies standing access versus just-in-time provisioning. That tradeoff is an operator decision this tool surfaces, not one it makes.

The Teleport survey's 4.5x incident-rate gap is, read carefully, a statement about what agents were given more than what they did. The Grant-vs-Use Gap Audit exists to make that distinction actionable without waiting for an incident to reveal it: find the access that never earned its place, and require it to justify itself before the next trajectory has the chance to reach it. Closing the gap is the cheapest risk reduction available in this issue's terrain, and it requires no new vendor relationship to start.

DFEI.010 :: VSR-01 :: The Scope That Was Too Wide Dispatches From Emerging Intelligence