Policy starter

AI Action Boundary Map

A practical allow / review / approve / block starting point for AI-assisted software delivery actions. Use it to keep normal coding fast while gating paths with blast radius.

Last updated: May 19, 2026

See it as a graph

An AI Action Boundary Map is a practical allow, review, approve, and block policy for AI-assisted engineering actions. It keeps low-risk coding fast while adding the right control for actions that can use credentials, change workflows, call tools, deploy, publish, or touch production.

Starter action boundary

Allow

  • Code edits in normal repo scope
  • Tests, linting, and docs
  • Local refactors
  • Read-only repo analysis
  • Non-sensitive generated comments

Review

  • Package installs or dependency changes
  • Workflow or CI/CD config edits
  • MCP calls to internal systems
  • Shell, network, or protected-file access
  • Unclear owner, purpose, or target

Approve

  • Deploy or release triggers
  • Cloud CLI or infrastructure commands
  • Secret-adjacent reads
  • Package publishing, signing, or migration jobs
  • Customer-impacting or production-adjacent changes

Block

  • Disabling required checks
  • Unmanaged secret reads
  • Broad PAT or static key use without purpose
  • Destructive production actions
  • Workflow changes that bypass approval

Boundary by environment

Environment Default stance Review or approval trigger
Local dev Allow normal edits, tests, docs, and local refactors. Review shell, network, protected files, or tool calls outside repo scope.
Pull request Allow reviewable code changes under branch protection. Review workflow edits, required-check changes, package scripts, or generated release config.
CI/CD Approve jobs that can use secrets or publish artifacts. Deploy, package publish, signing, cloud commands, migrations, or secret-adjacent reads.
Production / release Require explicit approval and retained proof. Customer-impacting changes, destructive actions, feature flags, admin tools, or data writes.

Evidence to keep at the boundary

Owner and purpose

Who asked for the action, which agent or automation acted, and what business or engineering purpose was declared.

Credential and scope

Which token, service account, OAuth grant, CI secret, cloud role, or inherited identity was involved.

Approval reason

Who approved the action, what policy applied, and why it was allowed, reviewed, approved, or blocked.

Outcome

What changed, which target was affected, what validation ran, and where logs or proof live afterward.

Copyable map

See how this boundary appears in a graph.

The lab shows where allow, review, approve, or block decisions appear across agent, repo, workflow, credential, action, target, and proof.

Open the lab