Summary / 25. Permissions and least privilege / Document
Paper 2026-09-06
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# Component 25 — Permissions / Least Privilege ## Making Authority Explicit, Task-Scoped, Capability-Based, and Monotonically Confined Under a Deterministic Control Plane with Zero Learned Entries --- ### Abstract This paper specifies the twenty-fifth component of the coding harness: permissions and least privilege. Component 24 drew the fence — an execution sandbox that contains arbitrary generated code under a deterministic control plane with zero learned entries. Component 25 is the law the fence enforces: the rules that decide, before any worker ever reaches the fence, exactly which files, commands, services, arguments, credentials, and data flows that worker may touch. Its central claim is that authority must be *derived*, not *declared*: the model may request authority but never grants it. The smallest set of actions and resources sufficient for the current workflow state is computed by deterministic software on CPU [D] and enforced at the tool boundary; ambient authority is removed so that a worker holds explicit capabilities rather than broad access; credentials are exposed only through scoped, short-lived proxies rather than raw secrets; specialist agents are prevented from laundering authority through one another; permissions narrow automatically and monotonically as work progresses; and every expansion is a first-class security transition demanding evidence that lower-privilege alternatives are genuinely insufficient. The structural invariant that governs the whole design is that the learned column contains at most one entry — and at this component, as at the sandbox, the correct value is zero: the permission control plane is deterministic software on CPU [D], and the model is the *requestor* the control plane mediates, not a *decider* within it. We assemble the evidence along five dimensions of scope (resource, action, tool, temporal, data-flow) and three enforcement pillars (capability derivation, policy enforcement, complete mediation), trace the lineage from Saltzer & Schroeder's design principles through Hardy's Confused Deputy to Capsicum's file-descriptor capabilities, and close with the honest-measurement machinery — the over-privileged tool-use rate, the false-positive and overhead audits, and the human-factors question of whether user-authored policies actually help — that turns least privilege from a policy intention into a *measured, legible property* of tool choice. --- ## 1. Introduction Every component of the harness so far has argued, in some register, that a learned model should do the thinking and deterministic software should do the guaranteeing. Component 24 sharpened that argument to its limit: the sandbox assumes the generated code *and* the agent directing it are untrusted, and it contains them with a control plane that has zero learned entries. Component 25 is the component that makes the sandbox's guarantee *coherent*, because a fence is only as strong as the rules deciding what is allowed to stand on either side of it. The sandbox is the fence; permissions are the law. A sandbox that contains arbitrary code but grants that code the full ambient authority of Piper's own account is not a security boundary at all — it is a containment box with the doors unlocked. This paper specifies the twenty-fifth component: the permission and least-privilege system that decides, before any worker reaches the fence, exactly which capabilities it holds. **Permissions should be explicit, task-scoped, state-scoped, capability-based, and monotonically confined: derive the smallest set of actions and resources sufficient for the current workflow state; express authority over exact files, commands, services, arguments, credentials, and data flows rather than coarse tool access; enforce those capabilities deterministically outside the model; remove ambient authority and expose credentials through constrained proxies rather than raw secrets; prevent specialist agents from laundering authority through one another; automatically revoke or narrow permissions as work progresses; and treat every privilege expansion as a first-class security transition requiring evidence that lower-privilege alternatives are genuinely insufficient.** **Never give a worker everything Piper can access. Give it exactly the capability needed for the next state — and make it structurally impossible for that worker to acquire anything else.** The second sentence is the human version of the first, and it is the sentence that makes this component non-negotiable. Throughout the harness, the model is a *trusted collaborator* held to account by deterministic gates: the workflow state machine trusts the model to make semantic judgments inside states and trusts the gates to keep those judgments inside bounds. Permissions cannot afford that trust even *before* execution begins, because the request itself — "let me read this file, call this tool, hit this network endpoint" — is the precise place where an injected instruction, a laundered request, or a simple over-reach becomes action. The design load is therefore not "help Piper do the right thing" but "make it *structurally impossible* for any worker — including a fully compromised Piper — to acquire authority beyond the capability derived for the current state." ### 1.1 The inversion: least privilege is a property the model does not volunteer The central inversion of this component is that the model cannot be trusted to *voluntarily obey* least privilege, and the measurement says so directly. The most decisive evidence is the ToolPrivBench benchmark [1]: across eight domains and five recurring risk patterns, six of the eleven evaluated models exceed a 30% over-privileged tool-use rate (OPUR), with the worst offenders being the small open-weight models the harness itself most plausibly runs locally — Qwen3-8B at 64.9% and LLaMA-3.1-8B at 55.9%. These are not adversarial settings; they are ordinary tool-selection tasks where the model reaches for a higher-privilege tool than the task actually requires. The inversion sharpens when one looks at what *fixes* the problem. General safety alignment — the very intervention that makes models refuse harmful requests — does not reliably transfer to least-privilege tool choice. In the same benchmark, safety alignment *increased* over-privilege for Qwen2.5-7B, from 50.4% to 60.7%, and reduced it only modestly for Ministral (68.8% to 62.5%). A model made *more* safe in one sense became *less* safe in the sense that matters here. The lesson is structural: least privilege is not a behavior the model acquires from alignment; it is a property the *system* imposes, because the model's distribution over tool choices does not honor it and alignment does not push it there. This is the same shape of finding that drove Component 24's "containment must hold for arbitrary generated text": here it becomes "authority must be enforced over arbitrary tool requests," and the model's own output distribution is the reason. The failure is also *amplified by* the environment the harness itself creates. ToolPrivBench measures both initial tool selection and escalation after transient tool failures, and finds that over-privilege is further amplified by transient failures — a finding of direct relevance to a harness whose whole architecture is built around running candidate patches, observing failures, and iterating. The very repair loop that makes the harness effective is the loop that, ungoverned, teaches the model to escalate: a tool call fails, the model reaches for a broader tool to "just get it working," and the failure — which is *transient*, not *informative about privilege* — becomes a justification for more authority. §5 returns to this and makes the rule explicit: a transient failure is not evidence that lower privilege was insufficient. ### 1.2 The D/L invariant Every element of this component is classified into one of two columns: **[D]** — deterministic software running on CPU — or **[L]** — a learned model. The structural invariant that governs the entire design is: > **the L column contains at most one entry.** The permission control plane — capability derivation, the policy engine, the grant/deny decision, monotonic-confinement narrowing versus expansion, and revocation — is deterministic software on CPU [D], with **zero learned entries by construction**. The model may *request* authority but never *grants* it; the grant decision is a computation over the current workflow state and the candidate capability, not a judgment the model is asked to make. **An empty L column is a permitted, correct state** — a deterministic phase of the harness that needs no model call at all — and here, as in Component 24, it is the *only* correct state for the enforcement path: a permission system with any learned entry in the grant/deny decision has reintroduced the very entity — a model whose tool-choice distribution is measurably over-privileged — into the one place whose correctness must not be probabilistic. The only learned elements in the system are *outside* the control plane: the harness's model calls that *request* capability. Inside the control plane there is nothing to learn, and nothing that learns. This is the same invariant that governs Component 24, held at the same strength but applied to a different moment. The sandbox's invariant holds *during execution*; the permission system's invariant holds *before execution*, at the request boundary. The two compose: the permission system decides what a worker may *ask for and receive*, and the sandbox decides what the received capability may *do*. Neither has a learned entry in its enforcement path, and both are correct to have none. ### 1.3 The kinship with the program's own M3 and M5 rules This component is not a new idea entering the program from outside; it is the coding-harness instance of two rules the program already ratifies. The prompt-injection ruleset's **M3** makes irreversible and high-blast actions token-gated by a *deterministic* (non-LLM) classifier that fails closed regardless of who the request claims to be from; the permission control plane is the same principle applied to *authority* rather than *bluntness* — a deterministic grant/deny gate that fails closed. The ruleset's **M5** routes state-changing tool calls through deterministic gates; the permission system is precisely such a gate, placed at the tool boundary where every state-changing call must pass. The relationship to Component 24 is the closest of all: where the sandbox is the *fence*, this component is the *law* — the sandbox enforces that received capabilities cannot escape their containment, and the permission system decides which capabilities are ever minted. A fence without a law contains everything and authorizes nothing; a law without a fence authorizes precisely and enforces nothing. The harness needs both, and they share one invariant. --- ## 2. The five dimensions of least privilege "Least privilege" is frequently treated as a single scalar — give the agent *less* — but the measurement and the mechanism both decompose it into five independent dimensions, each with its own failure mode, its own guarantee, and its own point in the pipeline where it is enforced. Conflating them produces a permission system that is either too coarse to be meaningful or too scattered to be auditable. The five are layered and complementary: no one of them is sufficient, and dropping any one leaves a hole the other four do not cover. ### 2.1 Resource scope: which objects may be touched Resource scope is the most familiar dimension and the one least-privilege mechanisms historically started with: *which* files, directories, endpoints, and devices may be the target of an action. The canonical failure is ambient authority — a worker that holds all of Piper's own reach and must be *persuaded* not to use it. The canonical fix is the explicit capability: a worker holds a handle to a *specific* object, not a path in a globally reachable namespace. Capsicum's model is the clean statement [5]: in capability mode, a process's authority over the filesystem is reduced to the file descriptors it already holds, so "read this file" is authorized by *possessing the descriptor*, not by the ambient right of Piper's account to read any file she owns. The sandbox component's own §5 traces this lineage; here the point is narrower — resource scope is the *object* dimension, and its unit of currency is the capability (the descriptor, the token, the handle), never the global name. ### 2.2 Action scope: which operations may be performed on those objects Possessing a capability to an object does not yet say *what* may be done to it. A descriptor may permit read without write; a tool may be reachable without all of its verbs being reachable. Saltzer & Schroeder's least-privilege principle is the founding statement, but their *complete mediation* and *separation of privilege* principles are the ones that make action scope enforceable [3]: every access to every object must be checked against the authority of the actor (complete mediation), and no single mechanism should be sufficient to cross a privileged boundary (separation of privilege). In the harness, action scope is where the policy distinguishes "read this file" from "write this file," "run this command" from "install this package," "query this service" from "mutate this service" — a distinction that is easy to state and easy to get wrong when the unit of authority is the whole tool rather than the specific action-argument pair. AgentBound's framing — securing the *execution boundaries* of AI agents via manifest-style permissions for MCP servers — is the applied form of this dimension [20]. ### 2.3 Tool scope: which tools are even reachable Tool scope is coarser than action scope and answers a prior question: *which* tools exist in a worker's universe at all. The ToolPrivBench result is, at bottom, a tool-scope finding: over-privilege is measured as selecting a tool with more authority than the task requires, i.e., a worker whose tool scope includes tools it should never have been offered [1]. MiniScope's contribution is the most direct on this dimension [6]: it authorizes *tool-calling* agents at the granularity of individual tool calls and their arguments — a mobile-OS-style authorization model (mirroring how a phone asks permission per capability rather than granting an app "the phone") — and it does so across ten real applications with 1–6% latency overhead. The point that matters for design is that tool scope is not "which tools the model *wants*"; it is "which tools the *state* makes reachable," and the two are different lists. ### 2.4 Temporal scope: when authority exists Authority that never expires is ambient authority in the time dimension. A worker granted read access to a directory for a single step of the workflow must not still hold it three steps later; a credential minted for one API call must not outlive that call. Lingering Authority names the problem directly [11]: its PORTICO system makes capabilities *revocable* and scopes them to resources and effects, so that authority is not merely granted but *withdrawn* as the agent's task moves on. This is the dimension that makes monotonic confinement possible in the first place: narrowing requires that authority can be *reduced over time*, and revocation is the mechanism. §5 builds the escalation discipline on top of exactly this. ### 2.5 Data-flow scope: where information may travel The first four dimensions govern *actions*; the fifth governs *flow*. Two individually legitimate capabilities — "read the secret" and "write to the network" — compose into a prohibited *flow* when held by the same worker, and a permission system that only checks individual actions cannot see the composition. This is the dimension SEAgent addresses with its information-flow graph [2], which monitors agent–tool interactions so that a chain of individually-permitted steps cannot move protected data to an unauthorized sink. It is also the lineage of Goguen & Meseguer's noninterference [17], and of the capability-provenance tracking in CaMeL [8] and tacit's tracked capabilities [9]. Data-flow scope is the reason the permission system must be able to reason about *sets* of capabilities and their composition, not just about individual grants — a point the multi-agent laundering problem in §4 makes concrete. ### 2.6 Ambient authority versus explicit capability The five dimensions share a single underlying distinction, and it is the oldest one in the field: *ambient authority* versus *explicit capability*. Under ambient authority — the model POSIX inherited — a process holds everything its user holds, and confinement is attempted by *filtering* a maximal grant. Under explicit capability, a process holds *only* the capabilities it was handed, and authority is *constructed* by *combining* minimal grants. Capsicum is the pragmatic realization of the latter [5]: capability mode turns off the ambient namespace and leaves only the descriptors already held, so the ambient authority is *removed* rather than filtered. Miller's dissertation is the foundational treatment of the object-capability composition that underlies it — how capabilities compose into a *confinement* guarantee rather than a per-call check [18]. The harness's permission system must choose the explicit-capability side unconditionally: filtering a maximal grant fails closed only if the filter is perfect, whereas constructing a minimal grant fails closed by *construction*, because there is nothing to filter and nothing ambient to leak. --- ## 3. The deterministic control plane The five dimensions of §2 describe *what* must be scoped; this section specifies *who* computes the scoping. The answer is the load-bearing one: the permission control plane is deterministic software on CPU [D], with zero learned entries. It has three pillars — capability derivation, policy enforcement, and complete mediation — plus one discipline — monotonic confinement — and the model's relationship to all of them is a single word: *request*. ### 3.1 Capability derivation: computing the grant, not asking for it The first pillar answers "what capability does the current workflow state actually need?" — and it answers it by *computation*, not by asking the model. MiniScope is the reference design [6]: given a task and the current state, it derives the set of tool calls (and their argument ranges) the task can possibly require, and it authorizes *only* those. Its two mechanisms are directly reusable here. First, the *hierarchy*: tools and actions are arranged in a lattice from narrow to broad, so that "derive the least privilege" is a search down the lattice for the narrowest node that covers the task's requirements — a deterministic optimization, not a model judgment. Second, the *optimization*: the derived set is minimized against the task, so a task that needs to read one file does not receive the whole directory. The model contributes the *task*, never the *grant*; the grant is the output of the derivation. This is the point at which the D/L invariant bites hardest. A capability is derived from the *state* — which stage of the workflow is running, what resources that stage demonstrably consumes, what the evidence so far has shown — not from the model's *intentions*. The model may say "I need write access to the whole repository," and the derivation may answer "the current state is a read-only recon step; you receive read on these three files, and the request is recorded but not granted." The model *requests* authority; the derivation *grants* it, or doesn't. ### 3.2 Policy enforcement: symbolic rules, not model discretion The second pillar answers "is this requested action, against the currently derived capability set, allowed?" — and it answers with deterministic policy. Progent is the reference design [7]: it expresses security policy as *symbolic rules* over the agent's actions, with two outcomes — ALLOW or FORBID — plus a Fallback action for requests the rules do not cover. The precision of that correction matters and is recorded here scrupulously: Progent's rule outcomes are ALLOW and FORBID with a Fallback action, *not* a naive ALLOW/DENY pair with a model-chosen substitute. The Fallback is itself a policy decision (typically: deny, and route to a safe default), not a model judgment. The significance for the harness is that policy enforcement is *complete and deterministic*: every request lands in ALLOW, FORBID, or a fixed Fallback, and none of the three is a model call. A request that falls through to Fallback is denied by default — fail closed, exactly as the program's M3 rule demands of any deterministic gate. ### 3.3 Monotonic confinement: narrowing automatic, expansion gated The third pillar is a discipline over *changes* to the derived capability set, and it is where the phrase "monotonically confined" in the thesis earns its place. Progent's SMT-based classification distinguishes two directions of change, and it treats them asymmetrically [7]: *narrowing* — reducing a worker's capability set — is applied **automatically**, as the natural, always-safe direction; *expansion* — granting more authority than the current state has — **requires approval** and is treated as a security transition (§5). This asymmetry is the operational definition of monotonic confinement: authority only ever shrinks automatically and only ever grows through an explicit, evidence-gated, first-class event. The model cannot expand its own authority by asking nicely, because expansion is not on the list of things a request can silently do; it is a *transition* the control plane mediates. Lingering Authority supplies the revocation half of the same idea [11]: capabilities are revocable and effect-scoped, so that the automatic direction — shrinking — has a concrete mechanism to act through. ### 3.4 Complete mediation at the tool boundary The three pillars are worthless unless every request passes through them. This is Saltzer & Schroeder's complete-mediation principle [3], applied at the one place in the harness where every action converges: the tool boundary. Every file access, command execution, service call, credential use, and network flow is a tool call; the tool boundary is therefore the single choke point through which all authority is exercised. The permission system must *be* that choke point — a mediator that sits between every worker and every tool, such that no action can reach a tool without a grant computed by the derivation pillar and checked by the enforcement pillar. This is the same posture as the OS framing advanced by Pirch, Horlboge, Großmann, Asif, Kireev, Holz, and Rieck [15]: the agent is an untrusted user process, and the permission mediator is the kernel that mediates its every reach. Complete mediation is not a feature of the permission system; it is the *existence condition* of the permission system, and it fails the moment any tool is reachable by a path that does not cross the mediator. ### 3.5 Recapitulation of the invariant at the architecture level The architecture of this component is the three pillars plus the mediation choke point, and the whole of it sits inside a single column. The control plane — capability derivation, the policy engine, the grant/deny decision, monotonic-confinement narrowing versus expansion, and revocation — is deterministic software on CPU [D]. There is no learned entry anywhere in that path, and the invariant that governs it is the one already stated and restated: > **the L column contains at most one entry.** And here the correct value is **zero**: **an empty L column is a permitted, correct state**, and it is the state the enforcement path must be in, because the enforcement path is exactly the place where a model — with its measurably over-privileged tool-choice distribution — must have no decision-making role. The model's relationship to the control plane is a single, well-defined edge: it may *request* authority, and the control plane *grants or denies* it. Request, never grant. That one word is the entire security boundary of this component, and everything else in the paper is the machinery that keeps the word true. --- ## 4. Credentials as capabilities, and the confused-deputy defense Authority over *files and tools* is only half the problem. The other half is authority over *secrets* — and secrets are where least privilege has historically collapsed, because a secret that enters the model's context is no longer scoped at all. This section treats credentials as capabilities, and treats the classic confused-deputy failure as the case the permission system must structurally prevent. ### 4.1 Credentials via scoped proxies, never raw secrets The rule is simple and absolute: a worker never receives a raw secret. It receives a *capability* — a scoped, short-lived proxy that authorizes one operation, against one service, for one bounded interval — and the proxy, not the worker, holds the credential. This is the capability model applied to secrets: the credential is the ambient authority (a key that opens everything it touches), and the proxy is the explicit capability (a handle that opens exactly what the task needs). The program's own M1 rule — secrets never enter model context, the tool layer injects credentials at call time, and the model holds only opaque handles — is the same principle stated as a standing rule; this component is its coding-harness instantiation. The lineage that makes it rigorous is the capability-tracking line. tacit tracks capabilities through the agent's execution and reports 100% security across 131 trials in its classified mode [9]; Verifiably Safe Tool Use applies STPA hazard analysis to a capability-enhanced MCP to make tool use verifiably safe [10]; CaMeL defeats prompt injections *by design* with capability and provenance tracking [8]. The common thread is that the secret is never the thing the model holds — the model holds a tracked capability, and the tracking is what makes the proxy's scope enforceable rather than advisory. ### 4.2 SEAgent: the mandatory-access-control reference The reference design for this section is SEAgent [2] — the framework whose paper is titled "Taming Various Privilege Escalation in LLM-Based Agent Systems: A Mandatory Access Control Framework" (SEAgent is the framework name, not part of the title). Its three components map cleanly onto the harness's needs. First, it is a *mandatory access control* (MAC) framework built on *attribute-based access control* (ABAC): the grant decision is not left to the agent's discretion (discretionary access control) but is enforced by policy over the attributes of the actor, the object, and the operation — which is exactly the "deterministic grant/deny, not model discretion" posture of §3. Second, it monitors agent–tool interactions via an *information-flow graph*: the data-flow scope of §2.5, made concrete, so that a chain of individually-legitimate actions cannot compose into a prohibited flow. Third, it explicitly identifies and blocks a *variant akin to the classic confused-deputy problem* — the agent induced to exercise its own authority on behalf of a hostile instruction — and it does all of this while maintaining a low false-positive rate and negligible system overhead. The overhead claim matters doubly for the harness: a permission system that adds a model call per request is not only insecure, it is unusable, and SEAgent demonstrates that mandatory control need not be either. ### 4.3 The multi-agent laundering problem The thesis names a failure mode no single-agent permission system sees: specialist agents laundering authority through one another. In the harness, workers are *specialists* — a repair agent, a research agent, a network agent — and their capabilities are derived per-specialty. The laundering attack is a *chain*: the repair agent, which has no network capability, asks the research agent to "fetch this reference," and the research agent — which has no network capability either — asks the network agent to fetch it, and the network agent, which *does* have network, complies, because the request came from a *peer* it trusts. Each individual grant is legitimate; the *composition* is a capability the repair agent was never supposed to hold, acquired not by asking for it but by *borrowing* it through a chain of peers. This is data-flow scope (§2.5) applied to the *social* structure of the harness rather than to a single agent's actions. The defense is the same in both places: authority must be traceable to a *derivation*, not a *requester*. A request arriving at the network agent must carry the provenance of the original capability derivation that justifies it, and the network agent's mediator must check that provenance against the *originating* worker's derived set — not against the immediately-preceding peer's. If the repair agent's derived set lacks network authority, then no chain of peer requests can synthesize it, because the provenance check fails at the first hop. This is the mechanism behind the thesis's "prevent specialist agents from laundering authority through one another," and it is the multi-agent generalization of the same capability-tracking discipline that tacit [9] and CaMeL [8] apply within a single agent. ### 4.4 Hardy's Confused Deputy: the founding story The entire section is a footnote to the founding story, which Norm Hardy told in 1988 and which is worth retelling because every element of it recurs in the LLM-agent setting [4]. A FORT compiler at Tymshare, installed in the protected directory SYSX, was instrumented to write usage statistics to a hardcoded file, (SYSX)STAT. The compiler — the *deputy* — held elevated authority, because it alone could write into SYSX. A user discovered that the compiler's debug-output option accepted a filename, and that by supplying an arbitrary target file the user could redirect the compiler's privileged write to *any* file — exploiting the deputy's authority to do something the user could not do directly. The deputy was *confused*: it exercised its own authority on behalf of a request it did not understand, and the attacker rode that authority to a target the attacker could never have reached. The story is the template for everything in this section. The confused deputy is the agent with a broad tool; the debug-output filename is the injected instruction or laundered request; the protected SYSX authority is the raw credential or ambient capability the agent holds; and the fix — why capabilities "might have been invented" — is the explicit capability: give the deputy a *handle to the specific file it may write*, not the ambient right to write to the whole protected directory. SEAgent's confused-deputy variant [2] is the same failure in the agent setting, and the permission system's answer — credentials as scoped proxies, provenance-tracked requests, and deterministic grant/deny — is the same fix, applied forty years later, to a deputy that is no longer a compiler but a learned model. --- ## 5. Monotonic confinement, and escalation as a first-class event §3 established that narrowing is automatic and expansion is gated. This section specifies the gate: the *PermissionExpansionRequest*, a first-class security transition that makes every privilege increase visible, evidence-gated, and auditable — and it closes with the discipline that a transient failure is not a justification. ### 5.1 The PermissionExpansionRequest When the capability derivation produces a grant that is *larger* than the current state's set — or when a worker explicitly requests more — the control plane does not silently widen. It opens a security transition carrying, at minimum, the following fields: - **Requested capability**: the exact file, command, service, argument range, credential proxy, or data-flow edge being asked for. - **Current capabilities**: the worker's present derived set, so the *delta* is explicit rather than implicit. - **Task requirement**: what the current workflow state demonstrably needs that the requested capability would satisfy. - **Why-insufficient**: a specific account of why the current set cannot satisfy that requirement — not "I need more," but "this operation requires write on X, and the current set grants only read." - **Evidence**: the concrete artifact (a failing step, an error, a task specification) that the requirement is real. - **Alternatives-attempted**: what lower-privilege approaches were already tried and how they failed. - **Risk**: the marginal risk of granting the expansion, scoped against the workflow. The request is *data*, not a *decision* — it is the structured input to a deterministic evaluation, and the evaluation, not the request, produces the outcome. This is the mechanism by which "treat every privilege expansion as a first-class security transition" becomes something the system *does* rather than something the thesis *says*. ### 5.2 The decision space: deny, allow-once, allow-narrower, require-human The expansion evaluation returns one of a fixed set of outcomes, and none of them is a model call: - **Deny**: the requirement is not demonstrated, the evidence is insufficient, or the requested capability exceeds what the task can justify; the request is refused and the worker continues (or fails) with its current set. - **Allow-once**: the expansion is granted for exactly one action, then auto-revoked — the temporal-scope discipline of §2.4 applied to the grant itself. - **Allow-narrower**: the requirement is valid but the requested capability is broader than it justifies; the control plane grants the narrowest capability that satisfies the demonstrated requirement, not the one requested. - **Require-human**: the expansion crosses a boundary the deterministic plane is not authorized to cross — an irreversible action, a new credential, a new service — and is routed to the operator for out-of-band confirmation, per the program's M3 token-gating. The key property is the *asymmetry preserved throughout*: the automatic direction is always toward less authority, and the only direction that admits a human or a one-time narrow grant is the expansion direction. A worker can, on its own, end up with *less* than it started; it can never, on its own, end up with *more*. ### 5.3 Transient failure is not justification for escalation The discipline that closes this section is the direct correction of the failure mode the harness's own loop would otherwise teach. ToolPrivBench found that over-privilege is amplified by transient tool failures [1] — a tool call fails, and the model reaches for a broader tool. In a harness built on iterative repair, that is not a corner case; it is the *steady state*. The permission system must therefore encode the rule explicitly: a transient failure is evidence about *the attempt*, not about *the privilege*. "The call failed" says nothing about whether a higher-privilege call would have succeeded, and it is specifically *not* the "why-insufficient" and "evidence" fields of a PermissionExpansionRequest. The request's evidence field must demonstrate that a *lower-privilege alternative was genuinely insufficient* — the thesis's exact words — and "the last attempt errored" does not meet that bar. This one rule is what keeps the harness's repair loop from being a privilege-escalation treadmill: the model may retry, may re-derive, may narrow, but it may not convert its own failures into authority. --- ## 6. Honest measurement, and the legibility problem A permission system that cannot be measured cannot be trusted, and a permission system that cannot be *read* cannot be audited. This section assembles the measurement machinery — the over-privilege rate, the false-positive and overhead audits, and the human-factors question — and argues that least privilege must be a *legible* property, not merely an enforceable one. ### 6.1 The over-privileged tool-use rate The headline metric is the over-privileged tool-use rate (OPUR) from ToolPrivBench [1], and it is the number the harness must drive toward zero. Six of the eleven evaluated models exceed 30% OPUR, with Qwen3-8B at 64.9% and LLaMA-3.1-8B at 55.9%; across eight domains and five recurring risk patterns, the benchmark measures both initial selection and escalation after transient failures. The metric's value to this component is twofold. It is a *detection* instrument: it tells the harness whether its own model, running its own tool-choice loop, is over-privileged even before any policy exists. And it is a *regression* instrument: the OPUR of the harness's tool-choice loop, measured against a policy-derived oracle of "what the task actually needed," is the number that must fall when the permission system is introduced, and that must not creep back up as the harness evolves. The benchmark's own mitigation finding — privilege-aware post-training, not general safety alignment — is a hint, not a substitute: the harness should not expect alignment to fix this, because §1.1's numbers show alignment can make it worse. ### 6.2 False positives and overhead A least-privilege system that over-blocks is one the operator will disable, and one that adds a model call per request is one the harness cannot afford. SEAgent is the reference for the *cost* side of the ledger [2]: its mandatory control framework blocks various privilege escalation while maintaining a low false-positive rate and negligible system overhead. The false-positive claim matters because a MAC gate that denies legitimate requests forces a choice between a broken harness and a disabled gate; the negligible-overhead claim matters because the permission mediator sits on the *hot path* of every tool call in the harness. Both are honest-measurement requirements, not design flourishes: the harness must measure the permission system's false-positive rate against its own workloads and its per-request overhead, and treat regressions in either as permission-system bugs. ### 6.3 The human-factors question The least-settled measurement is the human one: does letting *users* author permission policies actually improve protection against agent overreach? The single work directly on the question is "Do User-Authored Permission Policies Improve Protection Against AI Agent Overreach?" — a single-author preprint by Ting Yan, roughly eleven days old at the time of verification, and unrefereed [19]. It is flagged as such here scrupulously: the finding is interesting and unvalidated, and it must not be cited as settled. The question it poses is nonetheless the right one for the harness, because the harness's policies are ultimately authored by the operator and by Piper, not by the model — and whether human-authored policies over-trust or under-trust is an empirical matter the harness should measure, not assume. The mention-level systems reinforce the same theme from the mechanism side: Conleash's consent-driven MCP authorization makes the *grant* itself a user-facing, legible decision ("options, not clicks") [22]; MCP-Secure adds a runtime access-control layer for privilege-aware tooling [23]; CapChain binds capability tokens to a verifiable provenance log [24]; SkillScope pushes least-privilege enforcement down to the granularity of individual skills [21]. ### 6.4 Legibility as a property, not a courtesy The thread that unites the measurement machinery is that least privilege must be *legible*: the derived capability set, the policy rules, the grant/deny log, and every PermissionExpansionRequest must be readable artifacts, not buried state. Legibility is what makes §5's escalation discipline auditable — a history of "denied, allow-once, allow-narrower, require-human" outcomes is a record the operator can *read* to see whether the permission system is working or silently over-granting. It is also what makes the *honest measurement* of §6.1 and §6.2 possible, because a rate can only be computed against a policy oracle that is itself inspectable. Legibility is not a courtesy appended to the permission system; it is the property that lets the operator — and Piper — verify the law the fence enforces, rather than merely trusting it. --- ## 7. Conclusion The coding harness's twenty-fifth component is the law to Component 24's fence. The sandbox contains arbitrary generated code; the permission system decides, before any worker reaches the fence, exactly which capabilities it holds — and it makes the acquisition of anything beyond that capability structurally impossible. **Permissions should be explicit, task-scoped, state-scoped, capability-based, and monotonically confined: derive the smallest set of actions and resources sufficient for the current workflow state; express authority over exact files, commands, services, arguments, credentials, and data flows rather than coarse tool access; enforce those capabilities deterministically outside the model; remove ambient authority and expose credentials through constrained proxies rather than raw secrets; prevent specialist agents from laundering authority through one another; automatically revoke or narrow permissions as work progresses; and treat every privilege expansion as a first-class security transition requiring evidence that lower-privilege alternatives are genuinely insufficient.** **Never give a worker everything Piper can access. Give it exactly the capability needed for the next state — and make it structurally impossible for that worker to acquire anything else.** The design reduces to one structural invariant, stated once more, in its strongest form: > **the L column contains at most one entry.** The permission control plane — capability derivation, the policy engine, the grant/deny decision, monotonic-confinement narrowing versus expansion, and revocation — is deterministic software on CPU [D], with **zero learned entries by construction**. The model may *request* authority but never *grants* it. **An empty L column is a permitted, correct state** — a deterministic phase of the harness needing no model call — and it is the *only* correct state for the enforcement path, because the enforcement path is the one place where a model with a measurably over-privileged tool-choice distribution must have no decision-making role. The inversion that motivated the component — six of eleven models over 30% OPUR, Qwen3-8B at 64.9%, and safety alignment *worsening* Qwen2.5-7B from 50.4% to 60.7% — is not a defect to align away but a fact to design against, and the design is the explicit capability: authority derived from state, enforced by policy, mediated at the tool boundary, scoped in time and flow, exposed through proxies rather than secrets, and shrunk automatically while every expansion is gated as a first-class, evidence-bearing, legible transition. ToolPrivBench and SEAgent put the measurement on both sides of the ledger — the over-privilege rate to drive down, and the low false-positive, negligible-overhead mandatory control to adopt [1, 2]; Saltzer & Schroeder and Hardy supply the founding principles and the founding story [3, 4]; Capsicum and Miller give the capability model its practical and theoretical form [5, 18]; MiniScope and Progent place derivation and policy in deterministic software [6, 7]; CaMeL, tacit, Verifiably Safe Tool Use, and Lingering Authority carry the capability discipline through credentials, tracking, and revocation [8, 9, 10, 11]; and InjecAgent, Spotlighting, and GuardAgent keep the request-side threat — the injected or laundered request the permission system must refuse — in view [12, 13, 14]. The permission system is the component where the harness states its deepest principle with the least hedging: authority is not a thing the model is *trusted to limit*; it is a thing the system *makes it impossible to exceed* — because the grant was never the model's to give. --- ## References [1] Kaiyue Yang, Yuyan Bu, Jingwei Yi, Yuchi Wang, Biyu Zhou, Juntao Dai, Songlin Hu, and Yaodong Yang. "When Lower Privileges Suffice: Investigating Over-Privileged Tool Selection in LLM Agents." arXiv:2606.20023, 2026. (Preprint; submitted 2026/06/18, no peer-reviewed venue as of this writing.) [2] Zimo Ji, Daoyuan Wu, Wenyuan Jiang, Pingchuan Ma, Zongjie Li, Yudong Gao, Shuai Wang, and Yingjiu Li. "Taming Various Privilege Escalation in LLM-Based Agent Systems: A Mandatory Access Control Framework." arXiv:2601.11893, 2026. (Preprint; SEAgent is the framework name, not part of the title. MAC built on ABAC; information-flow graph; confused-deputy variant; low false-positive rate and negligible overhead.) [3] Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems." *Proceedings of the IEEE*, Vol. 63, No. 9, pp. 1278–1308, September 1975. DOI: 10.1109/PROC.1975.9939. [4] Norm Hardy. "The Confused Deputy (or why capabilities might have been invented)." *ACM SIGOPS Operating Systems Review*, Vol. 22, Issue 4, pp. 36–38, October 1988. DOI: 10.1145/54289.871709. [5] Robert N. M. Watson, Jonathan Anderson, Ben Laurie, and Kris Kennaway. "Capsicum: practical capabilities for UNIX." In *Proceedings of the 19th USENIX Security Symposium* (USENIX Security '10), August 2010. [6] Jinhao Zhu, Kevin Tseng, Gil Vernik, Xiao Huang, Shishir G. Patil, Vivian Fang, and Raluca Ada Popa. "MiniScope: A Least Privilege Framework for Authorizing Tool Calling Agents." arXiv:2512.11147, 2025. (CoRR preprint; no peer-reviewed venue as of this writing.) [7] Tianneng Shi, Jingxuan He, Zhun Wang, Hongwei Li, Linyu Wu, Wenbo Guo, and Dawn Song. "Progent: Securing AI Agents with Privilege Control." arXiv:2504.11703, 2025 (v3 May 2026). (ALLOW/FORBID symbolic rules plus a Fallback action; SMT-classified narrowing automatic, expansion requires approval.) [8] Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis, and Florian Tramèr. "Defeating Prompt Injections by Design." In *IEEE Conference on Secure and Trustworthy Machine Learning* (SaTML 2026). arXiv:2503.18813. (CaMeL is the system name, not part of the title.) [9] Martin Odersky, Yaoyu Zhao, Yichen Xu, Oliver Bračevac, and Cao Nguyen Pham. "Securing Agents With Tracked Capabilities." In *ACM Conference on AI Systems* (CAIS 2026). arXiv:2603.00991. (arXiv title: "Tracking Capabilities for Safer Agents.") [10] Aarya Doshi, Yining Hong, Congying Xu, Eunsuk Kang, Alexandros Kapravelos, and Christian Kästner. "Towards Verifiably Safe Tool Use for LLM Agents." In *International Conference on Software Engineering — New Ideas and Emerging Results* (ICSE NIER 2026). arXiv:2601.08012. [11] Igor Santos-Grueiro. "Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents." arXiv:2606.22504, 2026. (Single-author preprint; no peer-reviewed venue as of this writing; its attribution of least-privilege to Saltzer & Schroeder was not independently verified — the principle is cited here directly from [3].) [12] Qiusi Zhan, Zhixiang Liang, Zifan Ying, and Daniel Kang. "InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents." In *Findings of the Association for Computational Linguistics: ACL 2024* (ACL Findings 2024). arXiv:2403.02691. (1,054 test cases; 17 user tools and 62 attacker tools; 30 LLM agents; GPT-4 attack-success rate 24%.) [13] Keegan Hines, Gary Lopez, Matthew Hall, Federico Zarfati, Yonatan Zunger, and Emre Kiciman. "Defending Against Indirect Prompt Injection Attacks With Spotlighting." arXiv:2403.14720, 2024. (Microsoft; the three transformations are Delimiting, Datamarking, and Encoding.) [14] Zhen Xiang, Linzhi Zheng, Yanjie Li, Junyuan Hong, Qinbin Li, Han Xie, Jiawei Zhang, Zidi Xiong, Chulin Xie, Carl Yang, Dawn Song, and Bo Li. "GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning." In *Proceedings of the 42nd International Conference on Machine Learning* (ICML 2025). arXiv:2406.09187. [15] Lukas Pirch, Micha Horlboge, Patrick Großmann, Syeda Mahnur Asif, Klim Kireev, Thorsten Holz, and Konrad Rieck. "Toward Securing AI Agents Like Operating Systems." arXiv:2605.14932, 2026. [16] Edoardo Debenedetti, Jie Zhang, Mislav Balunović, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. "AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents." In *Advances in Neural Information Processing Systems 37 (NeurIPS 2024) Datasets and Benchmarks Track*. arXiv:2406.13352. [17] J. A. Goguen and J. Meseguer. "Security Policies and Security Models." In *Proceedings of the 1982 IEEE Symposium on Security and Privacy*, April 1982. [18] Mark S. Miller. "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control." PhD dissertation, Johns Hopkins University, 2006. [19] Ting Yan. "Do User-Authored Permission Policies Improve Protection Against AI Agent Overreach?" arXiv:2608.27443, 2026. (Single-author, ~11-day-old preprint at verification time; unrefereed — treat findings as preliminary.) [20] Christoph Bühler, Matteo Biagiola, Luca Di Grazia, and Guido Salvaneschi. "AgentBound: Securing Execution Boundaries of AI Agents." In *Proceedings of the 34th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering* (ESEC/FSE 2026). arXiv:2510.21236. [21] Jiangrong Wu, Yuhong Nan, Yixi Lin, Huaijin Wang, Yuming Xiao, Shuai Wang, and Zibin Zheng. "SkillScope: Toward Fine-Grained Least-Privilege Enforcement for Agent Skills." arXiv:2605.05868, 2026. (Preprint; no peer-reviewed venue as of this writing.) [22] Ying Li, Yanju Chen, Peiran Wang, Issac Khabra, Faysal Hossain Shezan, Yu Feng, and Yuan Tian. "Options, Not Clicks: Lattice Refinement for Consent-Driven MCP Authorization." arXiv:2605.11360, 2026. (Preprint; "Conleash" is the framework name, not part of the title.) [23] Gamini Singh and Vijay K. Madisetti. "MCP-Secure: A Runtime Access Control Layer for Privilege-Aware LLM Agent Tooling." *IEEE Open Journal of the Computer Society*, 2026. DOI: 10.1109/ojcs.2026.3664314. (The specific three-layer L1/L2/L3 content claim was not verifiable from the primary abstract; treated as unverified detail.) [24] Tuck Wai Choong, Wen-Bin Hsieh, and Jenq-Shiou Leu. "CapChain: A Capability-Token Access Control Architecture with Verifiable Provenance for Multi-Agent LLM Systems." *Applied Sciences* (MDPI), 2026. DOI: 10.3390/app16157776.