Enterprise permission modes with managed maximum policies

Problem

Enterprise deployments need to let agents start useful and evolve their access without letting
them exceed organization-controlled security boundaries. OpenShell has policy hot reload,
provider policy composition, and the policy.local proposal loop, but it needs one admission
contract that applies consistently to every way sandbox authority can change.

The older proposal-specific auto-approval and risk-query model also overlaps with managed maximum
admission. Keeping both would give reviewers and agents two different answers to whether a
capability may apply.

Product contract

Add gateway-managed maximum policy admission. A maximum is a ceiling, not the sandbox's active
policy, and it extends the existing OpenShell policy format rather than introducing another policy
language:

effective authority = sandbox policy + provider policy + credential reach + approved grants
candidate effective authority <= applicable managed policy envelope

The gateway evaluates the fully composed live candidate immediately before it creates or updates a
sandbox. The same admission decision protects sandbox creation, policy revisions and proposal
application, provider changes, and eventually agent/subagent policy composition.

A narrower active policy is valid; a maximum does not grant access by itself. Stored proposals and
prior approvals are evidence, not reusable authorization.

Workflow sequencing

This issue intentionally covers the broader end state, but the implementation is sequenced so the
core human and agent workflow can receive feedback before more policy-language complexity is added:

1. Establish the core managed-maximum workflow with filesystem, L4, and enforced REST containment,
   immutable ask or auto modes, provider composition, live-state revalidation, and one automatic
   admission surface.
2. Validate the core developer and reviewer experience in draft PR #2168.
3. Extend the same admission contract with GraphQL, remote MCP, and multiple policy inputs for
   agents and subagents. These are remaining phases of this issue, not separate non-goals.

The exact multi-policy API and composition rules can incorporate feedback from the core workflow,
but the organization-controlled maximum remains the outer authority boundary.

Permission modes

Without a managed maximum, accepted agent proposals remain pending for authenticated human review.
There is no separate unmanaged auto, yolo, or learn mode. A developer who wants hands-off
iteration can configure an explicit broad maximum and select managed auto.

An authenticated user's direct policy edit is approval of that exact request, but it must still
fit inside every applicable managed boundary. At creation time, review-required starting authority
is rejected so it cannot be granted silently.

Managed auto automates approval of eligible proposals. It does not make a maximum the active
policy or allow a denied runtime request automatically. Agents continue to use the existing
denial, proposal, wait, hot-reload, and retry loop.

Decision flow

if no managed maximum is configured:
    keep accepted agent proposals pending for human review

resolve all applicable managed policy inputs

if the requested permission mode is not allowed:
    reject

candidate = compose live sandbox policy, provider policy, credentials, and approved grants

if the candidate uses an authority surface not yet supported by containment:
    reject with admin-required guidance

if the candidate exceeds an applicable maximum or intersects an explicit deny:
    reject with a counterexample

if sandbox creation includes review-required authority:
    reject with review guidance

if this is sandbox creation, an authority removal/no-op, or a direct authenticated edit:
    apply

if mode is ask:
    ask

if the requested delta includes review-required authority:
    ask

apply

Credentialed raw-L4 advisory

Retain the useful observation behind the earlier L7-bypass finding as a non-gating advisory. Raw L4
authority to a host targeted by an attached provider credential records binary, host, and port
evidence because OpenShell cannot bound the stream by HTTP method or path.

The advisory never returns apply, ask, or reject and cannot override managed admission. To make
that authority require approval, mark the corresponding region review.required in the managed
policy.

Loopback, link-local, unspecified, and known metadata targets are different: OpenShell rejects
them as always-blocked network authority.

Target scope

• Configure managed maximum policy with identity, version, allowed/default modes, audit labels,
  and optional review requirements.
• Prove containment for filesystem paths; L4 host, port, and binary authority; REST method/path
  authority; GraphQL endpoint, operation, and root-field authority; and remote MCP endpoint/tool
  authority.
• Accept multiple applicable policy inputs so parent agents and subagents can be checked against
  their delegated policies while remaining inside the organization maximum.
• Enforce explicit denies before allows. Unsupported managed surfaces fail closed.
• Include provider-derived policy and credential-bearing reach in the fully composed candidate.
  Never log credential values.
• Return actionable apply, ask, or reject decisions with managed policy identity/version, mode,
  source, reason or counterexample, provider context, and candidate/delta hashes.
• Recompute against live policy, provider state, and applicable policy inputs immediately before
  apply.
• Keep initial maximum mutation constrained while sandboxes exist and preserve the
  proof-to-commit boundary under supported storage modes.

Review requirements belong to capabilities in managed policy, not to the source of a change. The
same write should require review whether it came from an agent proposal, provider attachment, or
subagent delegation.

Compatibility cleanup

• Remove proposal_approval_mode and sandbox create --approval-mode.
• Remove the empty-finding unmanaged auto-approval gate.
• Remove openshell policy prove and the legacy proposal-risk query model, registries,
  accepted-risk files, and findings.
• Preserve stale stored legacy approval settings as inert data.
• Keep credentialed raw L4 as advisory evidence rather than a second enforcement primitive.

Expected behavior

Checked-in fixtures and examples should cover autonomous in-boundary work, read-auto/write-review
REST and GraphQL access, remote MCP tools, and nested agent policy composition.

Acceptance criteria

• A gateway administrator can configure and inspect managed maximum policy without making it
  active sandbox policy.
• Sandbox creation validates its mode and fully composed starting authority.
• One admission contract governs creation, provider changes, direct and proposal-driven policy
  revisions, and agent/subagent policy composition.
• Unmanaged proposals require human review; managed ask and auto behave as described above.
• Containment, deny precedence, and review eligibility work for filesystem, L4, REST, GraphQL,
  and remote MCP authority.
• Multiple applicable policy inputs keep agents and subagents inside both delegated and
  organization-managed bounds.
• Unsupported managed surfaces fail closed before approval logic.
• Pending changes are revalidated from live policy, provider state, and applicable policy
  inputs before apply.
• Credentialed raw L4 remains advisory and cannot change admission.
• CLI/API responses and OCSF audit events explain decisions consistently and never expose
  secrets.
• Focused containment/admission tests and golden end-to-end flows demonstrate create,
  automatic apply, reviewed apply, rejection, hot reload/retry, provider composition,
  GraphQL/MCP behavior, nested policy bounds, and audit output.

Non-goals

• A new approval inbox or prompting on every use of authority already granted.
• Treating a maximum as permission to bypass the sandbox's active policy.
• A general policy catalog, signed policy bundles, or unrelated tenant-management UX.
• A contextual or LLM reviewer that becomes another enforcement boundary.

Existing work

• Draft implementation: PR #2168.
• #1062 provides the policy.local proposal and wait/retry workflow.
• #1840 / PR #1843 provide earlier containment-spike context reused selectively.
• #823 covers deny precedence.
• #1636 covers stale proposal and approval revalidation.
• #1434 provides the reviewer substrate.