AI coding agents

AI Coding-Agent Permission Boundaries

Define least-privilege tool access, trust boundaries, approval gates, and postconditions for coding-agent work.

Core conceptAnthropicOpenAIGoogle
CurrentNext review due 2026-08-24Content version 0.30.0
Format
Decision Path
Level
Intermediate
Audience
Developer, Operator, Leader
Owner
Project42 Editorial
Review cadence
Every 30 days
Prerequisites
An AI coding-agent work plan; Knowledge of the target environment and data classification
01

Classify actions before granting tools

Separate read-only discovery, reversible workspace edits, local execution, network access, secret access, external writes, production changes, and destructive actions. Grant only the tools, paths, domains, and duration needed for the current step. Repository instructions influence behavior; a sandbox, permission engine, identity policy, and branch protection enforce boundaries.

Treat untrusted repositories, generated instructions, dependency scripts, web content, tool output, and issue text as data until an authorized person accepts them as instructions. Trusted-folder prompts and workspace trust reduce accidental execution, but they do not make repository content trustworthy.

02

Record permission and approval boundaries

Prefer a clean isolated environment for unfamiliar code. Keep credentials out of prompts, logs, fixtures, patches, and commits. Do not combine an open-ended shell, unrestricted network access, broad credentials, and unattended execution. A missing tool response is not proof that an external mutation failed; reconcile system state before retrying.

Coding-agent permission matrix
text
Step: [PLAN STEP]
Environment trust: [TRUSTED | UNTRUSTED | ISOLATED]
Data classification: [PUBLIC | INTERNAL | RESTRICTED]
Read paths: [ALLOWLIST]
Write paths: [ALLOWLIST]
Executable commands: [EXACT OR BOUNDED COMMAND SET]
Network destinations: [ALLOWLIST OR NONE]
Credential capability: [NONE | NAMED LEAST-PRIVILEGE IDENTITY]
External writes: [NONE | SYSTEM AND OBJECT]
Must ask before: [MATERIAL ACTIONS]
Always denied: [DESTRUCTIVE OR OUT-OF-SCOPE ACTIONS]
Timeout/revocation: [WHEN ACCESS ENDS]
Precondition: [STATE TO CONFIRM BEFORE ACTION]
Postcondition: [STATE TO VERIFY AFTER ACTION]
Rollback/recovery: [REVOKE ACCESS, RESTORE POLICY, RECONCILE SIDE EFFECTS]
Audit evidence: [LOG, CHANGE ID, TEST, OR REVIEW]
03

Expected evidence and verification

The expected evidence is a permission matrix whose allowed capabilities are no broader than the work-plan step, plus an audit record of approvals and verified postconditions.

Test denied paths and disallowed actions with safe probes, confirm credentials expose only the intended capability, inspect staged changes before commit, and verify external state after mutation. Revoke temporary access at the stated boundary. Escalate any request to bypass controls, expose secrets, broaden scope, or perform an irreversible action.