An authorized narrowing that a control plane cannot represent does not survive its own reconciliation

Description

This weakness names a gap between two layers a well designed enforcement point and a poorly expressive control plane can quietly leave open between them. The first layer is where authority is actually exercised: a proxy, a gateway or another point of enforcement correctly applies a rule an operator added, denying one specific action while leaving the rest of a broader grant intact. The second, separate layer is the system's own persisted, canonical description of what that grant is supposed to be, the record a restart, a rebuild or a reconciliation pass consults to decide whether the running state matches what was intended. When that persisted description's own schema has no field for the kind of narrowing the operator made, the two layers diverge the moment the operator acts, not because either one is broken, but because only one of them can say what just happened. A reconciliation process built to treat any such divergence as drift, an error to correct or refuse, has no way to distinguish an operator's own deliberate, working restriction from a genuine inconsistency, because the persisted description it trusts cannot carry the distinction in the first place. This differs from action without applicable policy, AEW-001: there, no path in the system ever computes a denial for the action in question at all, so nothing is enforced anywhere; here, the narrower authority is computed, rendered and actually enforced at the point of execution, and the gap opens one layer further along, in whether the system's own record of intent can represent what its own enforcement point already holds. It differs from an explicit denial discarded by default substitution during policy compilation, AEW-022: there, a generic templating helper's own emptiness test silently flips an operator's explicit false to a permissive default inside one render pass, a defaulting bug inside a compiler; here no compiler runs on the operator's own change at all, because the schema the compiler would read from has no field for it to begin with, an absence of expressiveness rather than a bug in how an existing field is defaulted. It differs from approval not bound to the executed action, AEW-005: there, a reviewed object and an executed effect come apart, generally toward more permissive behavior than was reviewed; here the live enforced state is narrower, more restrictive, than what the persisted description represents, and the documented failure mode is the control plane refusing to proceed rather than silently executing something wider than what was approved.

The authority gap

The authority the enforcement point actually holds and exercises is the operator's own narrower grant, correctly applied. The authority the control plane's own lifecycle machinery can act on is only what its persisted description can represent, which has no vocabulary for the narrowing at all, so the system cannot preserve, through its own restart or reconciliation, an authority state its own enforcement point already correctly holds.

Failure conditions

• An enforcement point genuinely and correctly applies an operator supplied narrowing of an agent's authority, such as a rule denying one specific action while a broader grant remains active.
• The system's own persisted, canonical description of that authority, consulted by its restart, rebuild or reconciliation logic, has no field capable of representing the narrowing the operator made.
• A reconciliation, status or lifecycle process compares live enforced state against that persisted description and treats any divergence between them as an inconsistency requiring correction or refusal, with no path to classify a divergence as an authorized, deliberate narrowing.
• The system's response to the resulting divergence is a lifecycle operation, such as a restart or a respawn, failing, refusing or being held back, rather than either preserving or silently discarding the narrower live state.

Consequences shown by the evidence

• A restart, rebuild or gateway respawn refuses or is quarantined because the system cannot reconcile a working, operator-authorized restriction against a persisted description that has no way to represent it, an availability failure produced by a security control that is itself functioning correctly.
• An operator whose only path to restoring normal lifecycle operation is removing the very restriction that triggered the refusal faces a structural incentive to abandon a working control in order to regain availability, though this weakness's own known example documents refusal and quarantine, not that outcome, as the system's actual current behavior.
• A control plane's own audit trail and status reporting describe an authority state that does not match what an enforcement point is actually doing, undermining confidence in either as a faithful record.

Detection signals

• A drift, consistency or reconciliation check reports an inconsistency, or a restart or respawn operation refuses, immediately after an operator manually applies a narrowing change at an enforcement point the control plane does not directly manage.
• A system's own registration or intent schema, read directly, has no field corresponding to a narrowing capability its own enforcement point's policy language otherwise supports.
• Documentation or an issue tracker names a specific error condition raised when live enforced state is narrower, rather than wider, than a persisted description.

Known examples

• NVIDIA/NemoClaw issue 11115, opened 5 September 2026 by ericksoa and, per this record's own direct verification on two independently phrased reads, still open with zero comments at this weakness's own 7 September 2026 verification. NemoClaw's own managed MCP server registration renders a generated OpenShell policy; OpenShell's own policy schema, independently corroborated through search, supports a per-tool deny_rules entry an operator can hand-edit into that generated policy to deny one specific destructive tool, such as doordash_submit_order, while leaving a server's other tools available, and this weakness's own reading of that schema found no claim anywhere that OpenShell's own proxy fails to enforce such an entry once applied. The issue's own verbatim account of what happens next: "Editing deny_rules into the generated policy via policy get / openshell policy set works at the proxy, but NemoClaw treats the change as drift (HERMES_MCP_CONFIG_DRIFT), mcp status reports the policy missing, mcp restart refuses, and the in-sandbox supervisor quarantines the next gateway respawn." NemoClaw's own registered, canonical description of an MCP server's authorized intent carries no field for a denied tool at all, so an operator's own working, correctly enforced restriction cannot be represented in the description NemoClaw's own restart and reconciliation logic reads as authoritative, and the system's response is refusal and quarantine rather than either preserving or silently discarding the narrower live state. An unmerged draft pull request, 11135, opened 6 September 2026 by the same reporter and carrying 16 commits at this weakness's own verification, proposes persisting a denied-tool list in the registry entry itself and states its own design intent to journal a replacement update before removing the prior generated policy, so that, in its own words, "a failed narrowing update leaves the MCP route blocked" rather than silently reverting to the wider policy, the corrective this weakness's own response patterns already name; the pull request had not been reviewed or merged at verification.

Recorded instances

No recorded instance yet. The weakness stands on the records below.

Related Intelligence Records

The published Moona Intelligence Records whose evidence establishes this weakness.

• You Cannot Prompt Your Way Out of Agent Authority