Secure an AI coding assistant with four controls: limit what it can read, limit what it can run, require human approval for risky actions, and run the same security checks on its output that you run on human code. Prompts and policy documents help, but enforceable settings and automated checks do the real work.
Definitions
Coding assistant. A tool that suggests or writes code in an editor or terminal. Some only autocomplete. Others act as agents that edit files, run commands and call external tools.
Agent permissions. The rules that decide which actions run without asking you. Vendors document these as modes, allow rules and deny rules.
Blast radius. What a mistaken or manipulated action can touch.
The four controls
| Control | Question it answers | Example mechanism |
|---|---|---|
| Read limits | What code and secrets can the tool see? | Content exclusion, deny rules for secret files |
| Run limits | What can it execute and reach? | Permission modes, sandboxed shell, network allowlists |
| Approval | Who signs off on risky actions? | Manual approval for commands, protected branches, required reviews |
| Output checks | Is the code it wrote safe? | SAST, dependency review, secret scanning, tests in CI |
Steps for a team
- Pick the starting mode. Vendor documentation describes modes from asking about nearly everything to running most things unattended. Start strict, and loosen per project once you see the prompts.
- Write deny rules for sensitive files. Block reads of key files and environment files in the tool's settings. Remember that some exclusion features have gaps. Check the product page for which modes they cover.
- Turn on the sandbox where available. An operating system boundary around shell commands is stronger than a prompt. Note that file tools and local MCP servers may run outside it.
- Restrict network access. Allow the domains the work needs. Commands that fetch from the web should not be auto approved by default.
- Protect the branch. Require pull requests and reviews so the assistant's work reaches main only through the normal gate.
- Run checks in CI. Secret scanning with push protection, dependency review and static analysis apply to AI written code exactly as to human code.
- Control shared settings. Use organization level managed settings for rules you must enforce, and keep project settings in version control so changes are reviewed.
- Log usage. Know who used which tool, and keep prompt content out of logs unless you have a reason.
What not to rely on
A line in a system prompt telling the model to be careful is not a control. The NCSC advises assuming the model can be manipulated and using deterministic, non-LLM controls to limit what it can do. See the related post on prompt injection against coding agents.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request is blocked until the checks pass.
Quick check
Should we ban AI coding assistants?
Not necessarily. A ban often pushes use onto personal accounts you cannot see. A supported tool with enforced settings and normal CI checks is easier to govern.
Is human review of every change enough?
Review helps but fatigue is real, especially for large changes. Pair it with automated checks and small pull requests.
What is the first setting to change?
Make sure shell commands and network fetches ask for approval or run in a sandbox, and add deny rules for secret files.
Where Safeguard fits
Safeguard provides dependency and SBOM scanning, reachability analysis, and policies and gates that can block a pull request, which covers the output checks for AI written code. You can run a free scan at gold.safeguard.sh/scan.
Sources
- Claude Code security documentation
- GitHub Copilot content exclusion
- GitHub secret scanning push protection
- NCSC on prompt injection
Last reviewed: 19 October 2026.
