Monotonic Narrowing

How monotonic narrowing works

Monotonic narrowing means delegated authority can only shrink as it moves from one hop to the next. Each actor may pass onward only the subset it received, so the chain cannot quietly expand permissions while crossing boundaries.

This is a governance rule as much as a technical one: the downstream party should inherit a constrained delegation envelope, not a fresh opportunity to act with broader access than the upstream requester possessed.

Why monotonic narrowing matters in delegated access

The value of the rule is predictability. When authority only narrows, reviewers can reason about what each hop is allowed to do without assuming that a later system, agent, or service will reintroduce hidden privilege.

That matters most in multi-step request flows where one component asks another to act on its behalf. If the downstream hop can regain broader authority, the trust boundary becomes porous and the original access decision loses meaning.

Where monotonic narrowing shows up

The pattern appears in federated request chains, agent handoffs, service-to-service delegation, and other systems where one actor speaks for another. It is especially important when the delegated path crosses control planes, tenants, or administrative domains.

In those designs, the authority passed forward should be constrained by scope, resource, time, and action, so the receiving hop can complete only the work already justified by the upstream hop.

What monotonic narrowing prevents

The rule blocks a common class of delegation failure: privilege inflation during transit. Without it, a downstream system may combine received authority with local standing access and end up acting far beyond the original intent.

It also helps preserve accountability. If each hop can only lose or retain portions of authority, it becomes easier to audit who was permitted to do what, and harder for an intermediary to claim that excess access was implied.

Risk and Threat Considerations

When monotonic narrowing is absent, delegated workflows can become privilege-amplifying paths. That creates exposure for unauthorized actions, lateral movement across trust boundaries, and silent overreach by a compromised intermediary or misconfigured service.

Failure mechanism: A hop preserves or reconstructs authority beyond the subset it received, often by combining delegation with ambient privileges, weak scope enforcement, or permissive downstream trust.

Impact: The chain can produce broader access than any single approval intended, increasing the blast radius of compromise and making misuse harder to detect and contain.

Practitioner Guidance

Why practitioners should care: Monotonic narrowing is a design constraint, not just a policy preference. If a delegated path can widen authority at any hop, the access model no longer reflects the actual execution path and reviews become unreliable.

Governance implication: Treat every delegation boundary as a point where scope must be explicitly reduced or preserved, never expanded by default. The practical question is whether the downstream hop can prove it only received the minimum authority needed for its step.

Related resources from NHI Mgmt Group

• When does narrowing an LLM’s scope help security?
• What do security teams get wrong about narrowing scan scope?
• Why does narrowing macOS hardware support create operational risk for IT teams?
• How can legal and compliance teams evaluate whether an eDiscovery search is narrowing the right evidence, not just reducing volume?