THE APPROVAL THAT WASN'T RUNTIME-BOUND

VSR-01 found the access an agent was granted but never used. This report addresses the access an agent does use, and asks a narrower but more consequential question: was the permission covering that specific action actually checked at the moment the action happened, or was it checked once, earlier, and simply presumed to still apply? Rubrik's "Agent Identity," announced this coverage window, authorizes access one tool call at a time: an explicit bet that the second kind of check, runtime-bound, is the one that matters. This report gives operators a way to test which kind of check they currently have, independent of whether they've bought a product built around the distinction.

A permission granted at deployment is a statement about the agent's eligibility at that moment: this agent, for this purpose, may reach these systems. It is not, by default, a statement re-evaluated every time the agent actually reaches one of them. Most access-control systems, including the ones in place long before "agent identity" became a category, work this way: check once at authentication or authorization time, trust the session for its duration.

That pattern is adequate for a human user whose actions over a session are bounded by what a person can physically do in that time. It is not adequate for an agent that can take hundreds of consequential actions inside a single approved session, any one of which might be the specific action that shouldn't have happened even though the agent was, in general, allowed to be doing what it was doing. The permission held. The trajectory, at the specific step that mattered, was never actually looked at.

Rubrik's Agent Identity is this issue's clearest signal that the industry has identified this exact gap and is building toward closing it. Its own description, "governs agent access one tool call at a time," is a direct statement that a session-level or deployment-level grant is insufficient. The practitioner guidance surfacing in the same window (via Akto's 2025 AI Yearbook commentary, circulated on nhimg.org) makes the same point independently: "bind approvals to runtime execution... rather than relying on design-time trust," specifically naming repository changes, infrastructure updates, payment flows, and data export as categories that need approval gates at the moment of the action, not only at the moment of deployment.

This is where VSR-01 and VSR-02 connect directly. A grant that is appropriately narrow (VSR-01's finding) is still only as good as its enforcement: a narrow grant checked once at deployment can still authorize an unacceptable specific action inside that narrow scope, if nothing checks the action itself. Narrowing the grant reduces the space of possible harm; binding the check to runtime is what actually evaluates whether a specific action, inside that space, should have happened.

Was this approval checked at the moment of the action, or only once before it?

The test does not ask whether an action was authorized in principle. A design-time grant answers that. It asks whether anything evaluated the specific action, at the specific moment, against the specific context that existed right then. If the answer traces back to a check that happened earlier and was never repeated, the approval is design-time trust, however current it may feel.

5.1 Design-time trust

An approval evaluated once, at deployment, at session start, or at initial provisioning, and treated as valid for every subsequent action that falls within its declared scope, without re-evaluation. The check answers "is this agent eligible," once, and the answer is presumed to hold indefinitely within scope.

5.2 Runtime-bound approval

An approval re-evaluated at the moment of the specific action, using the context available at that moment: the current state, the specific parameters of this call, anything that has changed since the grant was made. The check answers "is this specific action, right now, acceptable," every time.

5.3 The binding spectrum

Most real systems sit somewhere between the two poles rather than cleanly at either end. The test below is designed to locate a given approval on that spectrum, not to force a binary label where the reality is graduated. Session-length re-authentication, periodic re-checks, and anomaly-triggered re-evaluation are all partial movements toward runtime binding without reaching full per-action checking.

Session-length trust inflation

An approval granted for a session is treated as covering every action inside that session equally, regardless of how long the session runs or how much has changed since it started. The longer an agent's session, the more this failure mode compounds: an approval given at 9am is doing the same work at 5pm regardless of what the agent has since learned, been told, or attempted.

Scope-shaped false confidence

Because VSR-01's grant-narrowing discipline genuinely reduces harm, it's easy to conclude that a narrow, well-audited grant is sufficient on its own. It reduces the space of possible harmful actions. It does not evaluate whether the action actually taken, inside that space, was the right one at that moment.

Approval theater

A visible approval step exists in the workflow: a human clicked "approve," but the thing approved was the agent's eligibility to proceed, not the specific action it eventually took. The approval satisfies a governance checklist without functioning as a runtime control.

For any permission gate in an agent's pipeline:

An approval passes as genuinely runtime-bound only if it clears all four.

Purpose

Classify any existing approval or permission gate as design-time trust or runtime-bound, using a repeatable decision procedure rather than an impression of how the system "should" work.

Use when

• Auditing an existing agent pipeline's approval gates before adding new ones.
• Evaluating a vendor's "agent governance" claim: ask which of their gates are runtime-bound by this test, specifically.
• After VSR-01's grant audit, to check whether the remaining (justified) grants are at least enforced at the point that matters.

What it creates

A per-gate classification (design-time trust / partially runtime-bound / fully runtime-bound) with the specific failed step named, so the fix is a concrete engineering change, not a vague "add more governance" instruction.

Technical version

runtime_binding_test:
  gate_id:
  permission_covered:
  checked_more_than_once_per_session: true|false
  check_uses_action_specific_parameters: true|false
  check_has_access_to_current_state: true|false
  check_can_block_or_alter_action: true|false
  classification: design_time_trust | partially_runtime_bound | fully_runtime_bound
  failed_at_step:   # first "no" above, if any

Manual / no-code alternative

Walk each approval gate through the four-question table in Section 07 by hand; a single "no" moves the gate down one classification tier from "fully runtime-bound."

Output

A ranked list of approval gates by binding strength, so remediation effort goes to the gates doing the least actual runtime work first.

Failure prevented

An agent technically staying within a permission granted at deployment while the specific action it takes at runtime is never itself evaluated.

An approval that isn't re-checked at the moment of action isn't a control at the moment of action, it's a memory of one.

A support agent is granted, at deployment, permission to issue account credits up to a stated cap: a reasonable, narrow grant under VSR-01's discipline. Run the binding test on the credit-issuance gate. Step 1: the permission is checked once, at session authentication. Step 2: fails. Every credit issuance during the session is treated as pre-authorized up to the cap, regardless of the specific customer, prior credits already issued that session, or whether the pattern of requests looks anomalous. Classification: design-time trust, despite a narrow and well-justified grant. The fix is not a wider audit of what the agent is allowed to do (VSR-01 already covers that ground). It's moving the credit-cap check from session start to the moment of each issuance, so a specific request that would push cumulative credits past a sane threshold is caught at the request that actually crosses it, not discovered afterward in a log.

This report classifies whether a check is runtime-bound; it does not evaluate whether the check's logic is correct. A runtime-bound check with a bad rule is still a bad control, just one that fails fast instead of failing silently. It also does not resolve the legitimate engineering cost of runtime binding: per-action checks add latency and complexity that session-level checks avoid, and not every action justifies the cost. The test surfaces where that tradeoff is being made implicitly (by default, unexamined) versus explicitly (a deliberate choice to accept design-time trust for a low-stakes action class).

Rubrik's bet, govern access one tool call at a time, names the right layer of the problem, whether or not any given operator buys that specific product. The Runtime Binding Test exists so an operator can evaluate their own pipeline against that standard today: not "do we have approval gates," but "do our approval gates check the action, or only remember having checked the agent." A narrow grant, checked once, is still a grant checked once. Runtime binding is what turns a permission into a control that's actually present at the moment it's needed.

DFEI.010 :: VSR-02 :: The Approval That Wasn't Runtime-Bound Dispatches From Emerging Intelligence