Skip to content

docs: agent-driven approval loop and auto-approval mode user guide #1614

Description

@zredlined

Description

Add user-facing documentation for the agent-driven policy approval loop landing in #1097 / #1528, including the auto-approval mode opt-in. The PR explicitly defers this user-facing docs page; this issue tracks the follow-up.

The existing `docs/sandboxes/policy-advisor.mdx` covers manual CLI review only. The agent-driven loop, the prover-gated auto-approval mode, and the four formal-prover categories that determine auto-vs-escalate are undocumented for end users today.

Context

What needs to be documented:

  • The loop end-to-end. Sandbox denial → agent reads `/etc/openshell/skills/policy_advisor.md` → agent POSTs a narrow proposal to `policy.local` → gateway runs the prover → either auto-approve (empty delta) or pending (any finding) → on approval the sandbox hot-reloads → agent retries.
  • The four prover categories (`link_local_reach`, `l7_bypass_credentialed`, `credential_reach_expansion`, `capability_expansion`) and what each means in plain language for an operator deciding whether a finding is acceptable.
  • Opt-in auto-mode. `openshell sandbox create --approval-mode auto` (sandbox scope), `openshell settings set --global --key proposal_approval_mode --value auto` (gateway scope), the manual default, and gateway-wins-over-sandbox resolution.
  • The audit trail. `CONFIG:APPROVED` events with `auto=true`, `source=`, `prover_delta=empty`, `resolved_from=` and what each unmapped field means.
  • Walkthrough. Point at `examples/agent-driven-policy-management/demo.sh` and explain the two-path flow (un-credentialed auto-approves silently; credentialed escalates with a categorical finding).

What NOT to document yet (deferred per PR #1528):

  • LLM-based contextual review layered on the deterministic gate.
  • Intent files / per-finding auto-reject vs. escalate configuration.
  • Credential scope modeling, MCP L7 surface, per-binary credential isolation, L7 watch mode, trust tiers.

Definition of Done

  • New page (or expansion of `docs/sandboxes/policy-advisor.mdx`) covering the loop, prover categories, auto-mode opt-in, and audit fields.
  • Navigation entry in `docs/index.yml` so the page is discoverable from the sandboxes section.
  • Cross-link from the existing `docs/security/best-practices.mdx` and `docs/observability/` pages where appropriate.
  • Brief documentation of the `SandboxDraft` / draft inbox flow in the TUI is covered separately if scope grows — keep this page focused on the loop semantics, not TUI navigation.

Related

Activity

  1. added
    area:docsDocumentation and examples
    area:policyPolicy engine and policy lifecycle work
    on May 28, 2026
  2. rpelevin commented on Jun 6, 2026

    @rpelevin

    For the user guide, I would make the approval loop read as a state machine, not just a narrative around the agent retrying.

    The important states seem to be:

    • sandbox denial
    • agent proposal created
    • prover result: empty delta auto-approve, finding escalate
    • pending human approval
    • approved / denied / expired
    • sandbox hot-reload
    • agent retry

    For auditability, the proposal should bind to the denied action, sandbox/profile id, requested policy delta, prover category, approver or auto-approval reason, timestamp, and retry result.

    One regression/docs example I would include: if the agent changes the requested policy delta after denial, the previous approval or empty-delta proof cannot authorize the new proposal. That makes auto-approval understandable without making it feel like a blanket trust switch.

  3. github-actions commented on Jun 20, 2026

    @github-actions

    This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.

  4. zredlined commented on Jul 2, 2026

    @zredlined
    CollaboratorAuthor

    Closing as superseded by the newer managed maximum policy semantics in #2109. Approval-loop docs should be written against the current governed ask/auto, max-policy, provider-layer, and revalidation model rather than the older auto-approval framing here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:docsDocumentation and examplesarea:policyPolicy engine and policy lifecycle workstate:staleInactive item at risk of automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions