Threat model for a coding agent
A coding agent processes repository content and may execute model-selected actions. Risk can come from an incorrect model decision, malicious instructions embedded in files, unsafe dependencies, overly broad permissions, or secrets exposed through environment variables and logs.
The model should be treated as an untrusted decision-maker operating through trusted enforcement code. The runtime, not the prompt, must decide which actions are permitted.
Core security controls
These controls are complementary. Local inference protects the model-data path, while a sandbox controls tools. Approval policies add human review where a static boundary cannot express intent.
Safer operating practices
- Run the agent from the narrowest repository directory that contains the task.
- Keep credentials out of prompts, tracked configuration, screenshots, and logs.
- Review proposed commands that install software, modify system paths, or access the network.
- Use version control so file changes are inspectable and recoverable.
- Run relevant tests after edits and inspect the diff before deployment.
- Do not grant unattended automation broader permissions than its use case requires.
Security in integrations
Custom clients should display approval requests clearly, preserve the runtime's sandbox configuration, and validate which workspace is sent when starting a thread. SDK processes should receive a minimal environment rather than every host secret by default.
For interface options, see the app server and SDK guide. For model-data locality, see local LLM inference.
Primary source: Midnight Coder sandbox documentation.
Review the runtime boundary
Inspect Midnight Coder's source and documented sandbox and approval surfaces.
Explore Midnight CoderReview source