Monotonic Privilege Confinement

also known as Monotonic Confinement, Shrink-Only Action Space, Narrowing-Only Policy Update

Let a task-derived action policy change during a run, but admit an update automatically only when a decision procedure proves it narrows the permitted set, so privileges shrink freely and widen only on approval.

Context

An agent is given a task, and a policy over tool calls decides which of them may run. A policy written once by an operator is static, and a static policy cannot know what a particular task will need, so it ends up either wide enough to be no defence or narrow enough to break ordinary work. Systems that close this gap have the policy generated from the user's request at the start of the run and revised as execution proceeds and new information arrives. That revision step is what makes the policy fit the task. It is also the step that runs while content fetched from outside sits in the same context window as the request.

Problem

A policy that can be rewritten mid-run is only as trustworthy as its update path. The untrusted content a revision is meant to react to — a fetched page, an inbound message, a tool result — is present when the revision is proposed, so an injected instruction can ask for an update that adds a tool, loosens an argument constraint, or raises a spend ceiling. A free-form update mechanism has no way to tell a tightening the task legitimately needs from a widening an attacker planted, and once the wider policy is in force every later call passes the check honestly. Escalation then looks exactly like adaptation, and the audit trail records an allowed action rather than an incident.

Forces

A policy fixed before the run cannot know which tools and argument values the task will need, so it is either wide enough to be no defence or narrow enough to break ordinary work.
Letting the model revise the policy restores that fit, but the component doing the revising is the same one an injection is trying to control.
Tightening and loosening are both edits to one object, yet only tightening can safely be driven by content that arrived from outside the run.
The direction check sits on the path of every revision, so it has to be decidable and cheap; a check that needs another model call reintroduces the component being defended.
Every expansion routed to a person costs latency and attention, so a policy that starts too tight turns a security gain into an approval queue nobody answers.

When to use

The policy governing tool calls is derived from the task at runtime rather than authored in advance by an operator.
The agent reads content it did not author — web pages, inbound messages, tool results — during the same run in which its policy can change.
The permitted set can be written as symbolic rules over tool names and argument values that a solver can compare for containment.
An expansion can be routed to a principal outside the run who answers within the task's latency budget.

When not to use

The policy is static and externally owned, so gating each action against it is enough and there is no update operation to protect.
No approval path exists outside the run, which leaves every expansion either blocking the task or waved through by the agent itself.
The permitted set cannot be expressed in a decidable form, so containment cannot be decided and the check degrades into comparing rule text.
The task legitimately needs privileges to grow as it proceeds, with each step earned by measured competence rather than by content the agent just read.

Example

An assistant is asked to clear out an inbox, so the policy written at the start lets it read messages, archive them, and reply to one named thread. Halfway through, a newsletter it opens contains a line telling it to forward the finance folder to an outside address, and the assistant proposes a policy update that adds that recipient. The checker sees the update would permit calls the current policy forbids, so it is held and the operator is asked instead. When the reply finally goes out, a second update that drops the send capability is a narrowing, so it applies without asking anyone.

Diagram

flowchart TD A["Task"] --> B["Initial policy P0 written before untrusted content"] B --> C["Agent runs; every tool call checked against current policy"] C --> D["Untrusted content read (page, message, tool result)"] D --> E["Candidate policy update proposed"] E --> F{"Decision procedure: candidate set contained in current?"} F -- "narrowing" --> G["Applied automatically"] F -- "expansion" --> H["Held for out-of-band approval"] G --> C H -- "approved by principal outside the run" --> C H -- "not approved" --> I["Policy unchanged; the wider call stays blocked"]

Solution

Therefore:

Represent the policy as symbolic rules over tool names and argument values, so two versions of it can be compared by a decision procedure rather than by reading. Generate the first version from the task before any external content has been read. When execution suggests a revision, do not apply it: hand the current policy and the candidate to a solver that decides whether the candidate's permitted set is contained in the current one. Containment means the update only removes reachable calls, so it applies on its own and needs no person. Any other result is an expansion, and an expansion is held until a principal outside the run approves it; the agent cannot approve its own. The effective action space therefore moves in one direction for the whole run, and a contamination event such as reading untrusted tool output can itself force a narrowing, cutting future authority the moment attacker-influenced data enters the state. Restriction need not be all-or-nothing: graded strategies remove reachability along particular argument flows instead of dropping whole tools, which keeps more of the task completable at the same attack success rate. Because the check is symbolic it adds no model call and no tokens.

What it gives you

An injected instruction cannot widen the permitted set on its own, so the widest the run can ever be is the policy written before untrusted content was read.
Narrowing stays free, which lets the runtime react to a contamination event immediately instead of waiting on an approval round trip.
The containment test is symbolic, so enforcement costs no extra model call and no token overhead — SkillGuard reports adding neither.
Measured on standard agent-security benchmarks: an independent reproduction of Progent on AgentDojo with an open-weight agent cut mean attack success from 25.8% to 4.2%, and a hand-crafted adaptive attack did not push it back above 2.6%.
Graded restriction recovers utility that binary restriction throws away — removing reachability along specific argument flows preserves substantially more capability than dropping whole tools at the same attack success rate.

What it costs you

The invariant protects the update path only. A first policy that was already too wide stays too wide for the whole run, because nothing may widen it and nothing forces it to tighten.
A legitimate task turn that needs a new tool lands in the approval queue, so a run can stall on a person who is not there, and the operator's usual repair is to pre-approve a broad expansion class.
Only constraints expressible as decidable symbolic rules can be enforced; a constraint that depends on what an argument means rather than what value it holds falls outside the solver.
Published results come from static benchmark suites. Adaptive, defence-aware attacks previously broke twelve in-band defences at over 90% success, and the equivalent optimized attack against monotone out-of-band enforcement is still open.

What this pattern forbids. A proposed policy update may not take effect unless a decision procedure has shown its permitted set to be contained in the current one; any update that widens the action space is rejected until a principal outside the run approves it, and the agent cannot approve its own expansion.

The smaller patterns that complete this one —

usesApproval Queue★★— Queue agent-proposed actions for asynchronous human review while the agent continues other work.

And the patterns that stand alongside it, or against it —

complementsAttenuating Delegation Chain★— Carry authority down a multi-hop agent delegation as a signed, append-only chain in which each child link is no wider than its parent on every facet, so a verifier can reject widening offline.
alternative-toProgressive Tool Access★— Grant tool permissions on a need-to-use basis, starting minimum and expanding only as the agent proves competency, mirroring how humans earn system access.
alternative-toProgressive Delegation★— Stage the human-to-agent handoff over time: the agent starts producing drafts a human always reviews; its autonomy expands action-by-action as measured trust accrues.
complementsPolicy-as-Code Gate★— Evaluate every proposed agent action against externally-managed machine-readable policies before dispatch, so compliance authorship lives outside the prompt and outside the agent code.
complementsDual LLM Pattern★— Split agent work between a privileged model that holds tool access and a quarantined model that reads untrusted content, exchanging only opaque references between them.
complementsCode-Then-Execute with Dataflow Analysis★— Have the agent emit code in a sandbox DSL whose values are statically tagged trusted/tainted via dataflow analysis before execution, enabling per-value policy enforcement.
complementsLethal Trifecta Threat Model★— Block prompt-injection-driven exfiltration by ensuring no single agent execution path holds all three of: access to private data, exposure to untrusted content, and an outbound communication channel.
alternative-toAgent Privilege Escalation✕— Anti-pattern: let an agent's effective permissions be the union of its own identity, the identities of its tools, and the identities of the services those tools call.
alternative-toTool Over-Broad Scope✕— Anti-pattern: grant the agent tools scoped so broadly that a single hallucinated argument can escalate into a privilege incident.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance

Source: patterns/monotonic-privilege-confinement.md on GitHub · commit 4eec3f8 · view history
Added to catalog: 2026-09-09
Last updated: 2026-09-09
Contribute: open an issue or PR at github.com/agentpatternscatalog/patterns.