Repository navigation
docs: agent-driven approval loop and auto-approval mode user guide #1614
Copy link
Copy link
Closed
Labels
area:docsDocumentation and examplesDocumentation and examplesarea:policyPolicy engine and policy lifecycle workPolicy engine and policy lifecycle workstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
Description
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
- Lands alongside the loop exiting feature-flag status: feat(gateway): persist and validate agent policy proposal operations #1097, feat(policy): add agentic approval loop #1528
- Parent umbrella: OpenShell Agent-Driven Policy Management #1062
- Pairs with: Policy Advisor #1038 (Policy Advisor roadmap), Make agent policy approvals explainable with the Policy Prover #1532 (explainability), feat(policy): define agent-oriented policy modes and safety levels #1435 (agent-oriented policy modes)
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area:docsDocumentation and examplesDocumentation and examplesarea:policyPolicy engine and policy lifecycle workPolicy engine and policy lifecycle workstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
Activity
rpelevin commentedon Jun 6, 2026
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:
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.
github-actions commentedon Jun 20, 2026
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.
zredlined commentedon Jul 2, 2026
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.