Direct answer
A coding-agent threat model should treat prompts, repository content, tool output, and external resources as potentially untrusted inputs while treating file writes, command execution, network access, credentials, and releases as privileged actions. Apply least privilege, sandboxing, approval, secret isolation, output review, and auditable verification at each boundary.
Key takeaways
- Model data inputs and action capabilities as separate trust boundaries.
- Grant permissions by task and environment, not by user convenience.
- Keep secrets outside prompts, repositories, generated patches, and ordinary logs.
- Pair preventive controls with detection, revocation, rollback, and incident evidence.
Key facts
| Fact | Verified value | Evidence |
|---|---|---|
| Codex controls | Codex documents sandbox and approval controls for command and file access. | View source |
| Claude controls | Claude Code documents security responsibilities and permission boundaries. | View source |
| Isolation | Claude Code documents sandboxing as a control distinct from application-level permissions. | View source |
| Risk process | The NIST AI RMF organizes AI risk work around governance, mapping, measurement, and management. | View source |
What this guide helps you solve
Help engineering and security teams review coding-agent deployments before granting real capabilities.
Verification scope and limits
- Evidence basis
- Official documentationSpecification
- Verification scope
- The model maps documented client controls to common repository, execution, credential, network, and delivery boundaries.
- Limits and invalidation conditions
- - It is not a substitute for a system-specific security assessment.
- - Cloud, IDE, and CI controls differ.
- - No claim is made that any client configuration eliminates prompt injection.
Draw the system before listing threats
Map the user, client, model endpoint, repository, shell, tool servers, network destinations, secret store, CI runner, and deployment target. Mark where data crosses process, machine, account, and organization boundaries. A threat tied to a concrete flow is easier to control than a generic warning about AI risk.
Separate read capability from action capability. Reading a public source file and executing its embedded command are different security events even when they appear in the same conversation.
Prioritize assets and credible abuse paths
Protect credentials, proprietary source, personal data, signing keys, production state, and delivery authority. Credible abuse paths include malicious repository instructions, dependency scripts, compromised tool servers, overbroad shell permissions, secret exposure in logs, and an unreviewed patch reaching production.
Rate impact and likelihood for the actual environment. A read-only disposable clone has a different risk profile from a persistent runner with cloud credentials and release access.
Apply least privilege before the task begins
Use a clean worktree or disposable runner, narrow filesystem access, restrict network destinations, inject short-lived credentials only into the process that needs them, and require approval for state-changing tools. Pin and review tool-server sources and dependency installation commands.
- Read-only exploration before writes
- Workspace-only writes before broader access
- Allowlisted commands and destinations
- No production credentials in local sessions
- Human approval for releases and destructive operations
Design detection and recovery with prevention
Record sanitized action metadata, permission changes, tool identities, repository revision, and verification results. Alert on unexpected destinations, protected-path changes, secret scanning findings, repeated approval failures, or release actions outside the expected workflow.
Prepare key revocation, tool disablement, runner isolation, patch rollback, and artifact invalidation procedures before enabling autonomous actions.
Revisit the model when capabilities change
Repeat the review when adding a model provider, enabling a new MCP server, changing sandbox policy, moving into CI, or granting deployment access. Validate controls with a benign test that attempts a denied path, destination, or operation; never test destructive behavior against production.
Official sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
Read the verification methodology