The map below is a starter policy, not a universal rule. The right boundary depends on credential scope, target system, reversibility, owner, approval model, and evidence coverage.
Starter action boundary
Allow
- Code edits in normal repo scope
- Tests, linting, and docs
- Local refactors
- Read-only repo analysis
- Non-sensitive generated comments
Approve
- Package installs or dependency changes
- Workflow or CI/CD config edits
- MCP calls to internal systems
- Deploy or release triggers
- Cloud CLI or infrastructure commands
- Secret-adjacent reads
Block
- Disabling required checks
- Unmanaged secret reads
- Broad PAT or static key use without purpose
- Destructive production actions
- Workflow changes that bypass approval
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, 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, approve, or block decisions appear across agent, repo, workflow, credential, action, target, and proof.
Open the lab