Gov Autonomous Execution Policy

Operating pattern

Preconditions for any autonomous execution

All of the following must be true before enabling any autonomous approval mode:

1. Sandboxed execution mode — execution_mode must be one of: sandboxed-devcontainer, sandboxed-remote-vm, or ci-like-ephemeral-runner. Never enable autonomous modes on interactive-native.
2. Implementation phase only — current_phase must be implementation (including verification or release-readiness sub-steps). Autonomous modes are not permitted during onboarding, architecture, or planning.
3. Documented execution profile — execution-plan/runtime/execution-profile.yaml must exist with autonomous_allowed: true, filesystem_scope, and network_policy all explicitly set.
4. Credentials outside Git — no local auth tokens, API keys, or proxy configs are committed to the repository.
5. Audit evidence path configured — every autonomous run must write runtime evidence under execution-plan/runtime/execution-control/.

Approval modes and their scope

• interactive — all sensitive steps require user confirmation; default for all phases.
• restricted-autonomous — AI executes low-risk, repo-scoped tasks in a sandbox without per-step approval; human review still required for the gated operations below.
• sandbox-autonomous — fully unattended inside a documented sandbox profile; requires durable audit evidence for every run. Use only when the team has high trust in the task scope and the sandbox is well-constrained.

Operations that always require human approval

Regardless of approval mode, these operations must never be executed autonomously:

• product brief, concept clarification, and system-architecture document updates
• destructive migrations or infrastructure deletion
• production access or credential changes
• broadening network, filesystem, or sandbox permissions
• adding new MCP servers or powerful integrations without a recorded project decision
• protected-branch pushes, release publication, or organization-settings changes

Sandbox interactive mode

Sandboxed interactive work is fully supported: pair any sandboxed execution mode with approval_mode: interactive. Use this when you want reproducible or isolated execution but still require normal approvals. This is the recommended default for teams transitioning toward sandboxed setups.

Minimal footprint principle

Autonomous agents should request only the permissions and filesystem/network scope required for the current task. Prefer narrow repo-only filesystem scope and curated-allowlist network policy over broad access. Stopping conditions (max iterations, scope guards) should be defined before long-running autonomous tasks begin.

Audit evidence for autonomous runs

Record under execution-plan/runtime/execution-control/ for every autonomous run:

• execution mode and approval mode used
• network policy and filesystem scope in effect
• changed files list
• key commands or scenario description
• follow-up review or rollback notes when relevant

Guideline lookup

• Use docs/guidelines/autonomous-execution-policy.md for the full precondition list and required evidence fields.
• Follow docs/guidelines/execution-modes.md for mode descriptions.
• Follow docs/guidelines/shared-operating-policy.md#guideline-lookup.
• Before writing execution-plan/runtime/execution-profile.yaml: create a HUS-* story in execution-plan/backlog/ titled "Approve autonomous execution profile" that states the requested approval_mode, execution_mode, network_policy, and filesystem_scope. Record the decision using gov-review-gate-management. Only write the execution profile once that story carries status: approved.

Story and artifact maintenance

• Follow docs/guidelines/shared-operating-policy.md#story-maintenance for backlog, evidence, and follow-up updates tied to this skill.

Quality bars

• All five preconditions are verified before autonomous approval mode is enabled.
• execution-plan/runtime/execution-profile.yaml is written and consistent with project-state.yaml.
• The still-human-gated operations list is documented and reviewed via an approved HUS-* story in execution-plan/backlog/.
• Every autonomous run has a corresponding audit entry under execution-plan/runtime/execution-control/.
• Policy changes (enabling or broadening autonomous scope) are always recorded as an approved HUS-* story, never self-approved.

Failure modes to avoid

• Enabling unattended execution without a documented sandbox trust profile.
• Creating an "approve everything" policy that removes meaningful guardrails.
• Not requiring audit evidence for autonomous runs, making post-run review impossible.
• Applying changes to autonomous execution policy without human review.
• Setting approval_mode: sandbox-autonomous while execution_mode: interactive-native — there is no actual sandbox; the guardrail is meaningless.
• Enabling autonomous modes outside the implementation phase — onboarding, architecture, and planning steps require interactive confirmation.
• Broadening filesystem scope or network policy autonomously without a human decision record.

Completion checklist

• Use docs/guidelines/shared-operating-policy.md#completion-checklist as the default completion gate for this skill.
• All five preconditions for autonomous execution are confirmed and recorded.
• execution-plan/runtime/execution-profile.yaml reflects the approved autonomous boundaries and is backed by an approved HUS-* story.
• The still-human-gated operations list is explicitly documented and approved via a HUS-* story.
• Audit evidence requirements are stated and the execution-plan/runtime/execution-control/ path is configured.
• Policy boundaries were reviewed and recorded in an approved HUS-* story before any autonomous run begins.

Commands

Inspect the current execution profile:

cat execution-plan/runtime/execution-profile.yaml

Verify autonomous preconditions (check all five fields are set):

python skills/gov-execution-mode-selection/configure_execution_mode.py \
  --mode sandboxed-devcontainer \
  --approval-mode restricted-autonomous \
  --network-policy curated-allowlist \
  --filesystem-scope repo-only

Check the current project phase (must be implementation before enabling autonomous modes):

python -c "
import yaml, pathlib
state = yaml.safe_load(pathlib.Path('execution-plan/project-state.yaml').read_text())
print('Phase:', state['project']['current_phase'])
print('Approval mode:', state['repository_preferences']['approval_mode'])
"

Worked example

Scenario: The team wants to enable restricted-autonomous mode for implementation sprints.

1. Verify phase — project-state.yaml shows current_phase: implementation. Precondition 2 met.
2. Verify sandbox — detect_environment.py confirms Docker is present and devcontainer assets exist. Choose sandboxed-devcontainer.
3. Run configure — configure_execution_mode.py --mode sandboxed-devcontainer --approval-mode restricted-autonomous --network-policy curated-allowlist --filesystem-scope repo-only. Profile written.
4. Document still-gated operations — AI assistant produces a bullet list of operations that still require human approval (architecture changes, credential access, etc.). Human reviews and confirms the list.
5. Set stopping conditions — team agrees: max 20 tool calls per autonomous task; any destructive file operation triggers a pause.
6. First autonomous run — AI executes a backlog story autonomously; writes audit entry to execution-plan/runtime/execution-control/run-001.md.
7. Post-run review — human reviews the audit entry, verifies changed files, confirms no scope was exceeded.