AI coding agents carry four main risks: they add dependencies you did not choose, they run commands on your machine, they send code and prompts to a model provider, and they can be steered by text hidden in files or web pages. The controls that work are approvals before action, scans before merge, platform policies and limits on MCP tools.
You do not have to give up the assistant you already use to put those controls in place. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. If you prefer to stay in the chat window you know, connect Claude or ChatGPT to the Safeguard MCP server and use Safeguard from there.
This guide walks through each risk in plain terms, maps it to a control you can switch on this week, and shows the commands.
What an AI coding agent can actually touch
A chat assistant that only returns text is a suggestion engine. A coding agent is different because it holds tools. Depending on the product and its settings, it can read files in your project, write and edit them, run shell commands, fetch web pages, call MCP servers and push to a branch.
That shift is why the security conversation changes. The question stops being "is this answer correct" and becomes "what did the agent do, with whose permissions, and who saw it first".
Vendors have built controls for exactly this. Claude Code's security documentation describes a permission-based architecture in which a session's permission mode sets which actions Claude can take without asking. In Manual mode it starts read-only and asks before it edits files, runs tests or executes commands. OpenAI's Codex documentation describes sandbox modes (read-only, workspace-write and danger-full-access) and approval policies such as on-request, where the agent works inside the sandbox and asks when it needs to go beyond it.
Those controls are real and worth using. They cover what happens inside one session on one machine. A team also needs controls that sit outside any single agent: a record of what changed in the dependency tree, a policy that a build has to pass, and limits on which tools an assistant can reach in shared systems. The rest of this post covers both layers.
The four main risks
1. Dependencies the agent adds
Ask an agent to "add retry logic" or "parse this date format" and it will often reach for a package. Sometimes that is the right call. Sometimes the package is unmaintained, carries known vulnerabilities, has a licence your legal team would reject, or pulls in a long chain of transitive dependencies nobody reviewed.
There is a stranger version of this problem too. Models sometimes name packages that do not exist. A 2024 research paper on 16 code-generating models and 576,000 code samples found that hallucinated packages averaged at least 5.2% for commercial models and 21.7% for open source models, with 205,474 unique hallucinated package names. If someone registers one of those names on a public registry, an agent that confidently runs the install step fetches whatever that person published.
The point is not that agents are careless. It is that a dependency change is a supply chain decision, and the agent makes it at the speed of autocomplete.
2. Commands the agent runs
Agents run commands to install packages, run tests, apply migrations and clean up build output. Each one runs with your user account's permissions. A command that deletes a folder, rewrites git history, changes a cloud resource or pipes a remote script into a shell can do real damage even when the intent was benign.
Claude Code's own documentation is candid about the boundary: a Bash command you approve can still write anywhere your user account can, which is why it offers an operating system level sandbox for filesystem and network isolation. Codex's workspace-write mode exists for the same reason. The lesson for any tool is the same. The approval prompt is a control only if a person reads it.
3. Data that leaves the machine
When an agent uses a hosted model, your prompts, the code it reads into context and the model's outputs travel to that provider. Claude Code's data usage page says so directly: to interact with the model it sends data over the network, including all user prompts and model outputs, encrypted in transit. Retention and training terms then depend on the account type. Anthropic's page, for example, separates consumer plans (where users choose whether data can be used for model improvement) from commercial terms, where it does not train generative models on code or prompts sent to Claude Code unless the customer opts in.
None of this is hidden, but it is easy to forget in the flow of work. A developer pastes a customer record into a prompt to reproduce a bug. An agent reads a .env file while looking for configuration. A cloud session clones a private repository into a hosted environment. Each is a data flow your security team should know about and decide on.
4. Prompt injection
OWASP describes prompt injection as inputs that alter a model's behaviour or output in unintended ways, and splits it into direct (the user's own prompt) and indirect (content the model pulls in from websites or files). Coding agents read a lot of outside content: README files, issue comments, documentation pages, dependency source and MCP tool results. Any of it can contain instructions written for the model rather than for you.
OWASP is also honest that it is unclear whether fool-proof prevention exists. Its recommended mitigations focus on limiting impact: least privilege, human approval for high-risk actions, separating untrusted content, and filtering inputs and outputs. That is the right frame for coding agents too. Assume some injected text will get read, and make sure it cannot quietly turn into an install, a command or a data transfer.
Controls mapped to each risk
The table below pairs each risk with controls that exist today. The "where it lives" column matters, because a control in one developer's local settings does not protect the rest of the team.
| Risk | What can go wrong | Control | Where it lives |
|---|---|---|---|
| Dependencies | Vulnerable, unmaintained, wrongly licensed or non-existent packages | Scan the changed project before merge; dependency and licence policies; reachability to sort real risk from noise | CI and the platform |
| Commands | Destructive or network commands run with your permissions | Approval modes, deny rules, sandboxing, a person reading each prompt | The agent's settings on each machine |
| Data leaving | Code, secrets or personal data sent to a model or hosted environment | Choose where scans run, keep source local, pick the model per task, block reads of sensitive files | Agent settings, model choice and the platform |
| Prompt injection | Outside text turns into an action | Least privilege, approvals for risky steps, limits on which MCP tools an assistant can call, audit trails | Agent settings and the MCP layer |
Controls inside the agent
Every serious agent has a permission model. Use it deliberately.
- In Claude Code, permission rules can allow, ask or deny, and the documentation says rules are evaluated in the order deny, then ask, then allow. A rule such as
Read(./.env)in the deny list stops Claude's file tools reading that file. Administrators can put settings in managed settings, where users cannot override them, and can disable bypass or auto mode there. - In Codex, administrators can deliver a
requirements.tomlfile through a managed channel to constrain runtime behaviour, such as which permission profiles are allowed. Codex Cloud is off by default for Enterprise workspaces, and access is granted through workspace roles. - In the Safeguard CLI,
/permissionssets the approval mode for the session: Ask, Auto or Yolo. More on that below.
Settings like these are your first line. They are also local, they vary by tool, and they rely on people reading prompts at the end of a long day.
Controls outside the agent
The second layer does not care which agent wrote the code.
- Scan what changed before you merge. Build an SBOM for the branch, match it against vulnerability databases and look at what is new.
- Prioritise with reachability. A vulnerable function your code never calls is a different problem from one on a hot path.
- Enforce policies and gates. A gate that blocks a build with a disallowed licence or a critical, reachable vulnerability holds no matter who opened the pull request.
- Limit and log MCP tool access. Decide which tools an assistant may call against shared systems, and keep a record of what it called.
The next two sections show how Safeguard does both layers.
Do the work properly with the Safeguard CLI
The Safeguard CLI scans code, container images and SBOMs on your own machine, sends only the results to the platform, and includes an assistant that can fix what it finds. It also writes code. That combination is the useful part: the assistant editing your project already knows your vulnerabilities, so the security check is part of the work rather than a step someone remembers later.
Install
It is a single static binary, with no Node, Python or JVM to install first. It runs on macOS, Linux and Windows, on x86_64 or arm64 (Windows ships x86_64 only).
# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
# Windows, in PowerShell
irm https://cli.safeguard.sh/install.ps1 | iex
First session
Run safeguard with no arguments to open the interactive terminal, then sign in and scan the folder you are in:
safeguard
/login
/scan .
/login signs in through the browser. After that you can ask in plain language, for example "how many critical vulns do we have" or "fix the lodash CVE in this repo". @ attaches a file from the folder you started in, and /resume picks up the last session in that folder.
Writing and fixing code, with your approval
The assistant has tools for your local files and for your Safeguard data, and it picks whichever the question needs. It can write files, edit code and run commands, and those actions ask before they act. So it works as a general terminal assistant (find and read files, edit code, run commands) and as a security assistant in the same session.
This demo shows that loop from Safeguard Search: attach a computer running the Safeguard CLI and a folder, ask for a fix, review the diff and approve the command before it runs. Computer work from Search is marked "available, expanding" in the demo itself.
Click through it at your own pace, or open it full screen.
Use the Claude, ChatGPT or Codex plan you already pay for
Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. /model shows or switches the AI model. For connecting a model, see the CLI docs or run /model. Whichever hosted model you choose, what you send in the conversation goes to that provider under its terms, so pick the model with the data risk above in mind.
Approvals: Ask, Auto and Yolo
/permissions sets the approval mode:
- Ask prompts before every action.
- Auto approves known actions and asks for anything new. It is the default.
- Yolo approves everything.
For risky work (an unfamiliar repository, a task that touches infrastructure, anything that pulled in outside text) switch to Ask. Keep Yolo for throwaway environments you are happy to rebuild.
Scan what any agent changed, then gate it in CI
The CLI does not care which agent made the change. After a session in any tool, scan the result:
safeguard scan --dir .
ls output/
Results are JSON files under ./output, such as vuln.json and license.json. You can also scan a repository with --repo, an image with --image or an existing SBOM with --sbom, and check SBOM files with safeguard validate sbom.json.
For CI, safeguard exec runs one non-interactive assistant turn:
safeguard exec "summarise the critical findings in this repository"
When the local runner runs platform scan jobs, your source code never leaves the machine; only SBOMs and findings are uploaded. Policies and gates are then evaluated in the platform, not by the CLI, so the same rule applies to every pull request. There is more on this pattern in checking coding agent changes with the Safeguard CLI.
Platform controls: policies, remediation and MCP Guardrail
The CLI handles the work on a machine. The platform holds the rules that apply to everyone.
Policies and gates. Write the rule once (no critical reachable vulnerabilities, no disallowed licences, an SBOM on every release) and enforce it at build, CI or release. An agent cannot talk its way past a gate.
Reachability analysis. Agents can generate a lot of change quickly, and that tends to produce a lot of findings. Reachability shows which vulnerable code your application actually calls, so people spend review time on the findings that matter.
Autonomous remediation. Safeguard can open tested fix pull requests, singly or in bulk. It ships off by default, and each category starts on manual, so a team turns it on deliberately and still reviews the pull request like any other.
MCP Guardrail. Coding agents increasingly reach shared systems through MCP servers, which is where prompt injection can become a real action. Safeguard's MCP server gates each tool per tenant: a new workspace starts with six read-only tools, an administrator enables more, and tools a tenant cannot use are neither listed nor callable. For MCP traffic more widely, Guard policies match on the MCP method, the tool name (with wildcards) or the agent, and allow, deny or monitor the call. Every evaluated request is written to an append-only audit trail with the rule that matched.
This demo shows the assistant side of that. You connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use.
Click through it at your own pace, or open it full screen.
The same works for ChatGPT, so people can keep the chat they already use and still query findings under the limits you set.
One platform on every surface
The controls follow you across devices. Start in the terminal with the CLI, continue in the desktop app (version 3.2.2 for Windows, macOS and Linux) where you can ask your supply chain anything in plain English, and check findings on your phone with the iOS or Android app. There are IDE extensions for VS Code, JetBrains and Open VSX, and a browser extension for Chrome. If you would rather install nothing, the download page lists a Cloud CLI that runs on Safeguard's infrastructure and a cloud sandbox tenant against a seeded demo repo, free for seven days with no card.
A rollout plan for a team
Here is a sequence that works for a team of five or fifty. Each step is small enough to finish in a day.
- Inventory the agents in use. Ask people which coding agents and MCP servers they run, and on which repositories. You cannot set rules for tools you do not know about.
- Set a default approval posture. For the Safeguard CLI, Auto is the default; agree when people should switch to Ask. For other agents, use their managed settings to set the equivalent baseline and block the most dangerous modes on sensitive repositories.
- Block sensitive reads. Add deny rules for
.envfiles, key folders and anything holding customer data, in whichever agent your team uses. - Install the CLI and run a baseline scan. Run
safeguard scan --dir .on your main repositories so you know the starting point before agents change anything. - Add a scan to CI. Scan every pull request and keep the JSON output as a build artifact.
- Turn on policies and gates. Start with a small rule set you can defend. A gate that blocks half of all builds on day one gets switched off by day three.
- Limit MCP tools. Keep the default read-only set until someone needs more, then enable specific tools rather than everything.
- Review monthly. Look at what the gates blocked, which approvals people granted and which MCP calls were denied, and adjust.
Common mistakes
Treating the approval prompt as the whole control. Prompts help only when someone reads them. Pair them with scans and gates that do not depend on attention.
Running permissive modes on real repositories. Yolo, bypass and full-access modes are useful in disposable environments. On a repository with production credentials nearby, they remove the one check between injected text and an action.
Trusting a package because the agent named it confidently. Confirm it exists, check who publishes it and scan it before it lands.
Scanning only the main branch. The risk arrives in the agent's branch. Scan the pull request, not just what is already merged.
Forgetting where the model runs. Every hosted model is a data flow. Decide which repositories may use which models, and write it down.
Enabling every MCP tool at once. Start read-only and add tools one at a time, with a reason for each.
FAQ
What are the biggest security risks of AI coding agents?
Four repeat everywhere: dependencies the agent adds without review, commands it runs with your permissions, code and prompts sent to a model provider, and prompt injection from files, pages or tool results. Each needs its own control.
Can I keep my Claude, ChatGPT or Codex plan and still use Safeguard?
Yes. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. You can also connect Claude or ChatGPT to the Safeguard MCP server and use Safeguard from the chat you already have.
Does the Safeguard CLI change files without asking?
Tools that change things (writing a file, editing code, running a command) ask before they act, according to the /permissions mode. Ask prompts every time, Auto approves known actions and asks for anything new, and Yolo approves everything.
Does my source code leave my machine when I scan?
When the local runner runs platform scan jobs, source stays on your machine and only SBOMs and findings are uploaded. If you chat with a hosted model, what you send in that conversation goes to the model provider under its terms.
Can prompt injection be prevented completely?
OWASP says it is unclear whether fool-proof prevention exists. The practical goal is to limit impact: least privilege, human approval for risky actions, limits on MCP tools and an audit trail.
Where are policies enforced?
Policies and gates are evaluated in the Safeguard platform, not by the CLI. That is what makes them consistent across every developer and every agent.
What does MCP Guardrail do?
It limits which Safeguard MCP tools a tenant can list and call, starting from six read-only tools. Guard policies can also allow, deny or monitor MCP calls by method, tool name or agent, with each decision recorded in an audit trail.
Is there a way to try this without installing anything?
Yes. The download page lists a Cloud CLI on Safeguard's infrastructure and a cloud sandbox tenant against a seeded demo repo, free for seven days with no card.
For more on how the CLI fits next to other tools, see the Safeguard CLI as a security-aware coding assistant and AI coding agents compared.
Try it yourself
This demo is the install and start walkthrough: set up the runner on your own machine, pick the platform, start it, approve it with its device code, then use the same CLI to scan from the terminal.
Click through it at your own pace, or open it full screen.
When you are ready, download the Safeguard CLI and follow the CLI docs. Bring the plan you already pay for, scan what your agents change, and let the platform hold the rules.
Quick check
Which approval mode is the Safeguard CLI default?
Auto. It approves known actions and asks for anything new. Ask prompts before every action and Yolo approves everything.
Where are Safeguard policies and gates evaluated?
In the platform, not by the CLI. The CLI scans and uploads SBOMs and findings, and the platform applies the rules.
What does OWASP recommend for prompt injection?
Limiting impact rather than promising prevention: least privilege, human approval for high-risk actions, separating untrusted content, filtering inputs and outputs, and adversarial testing.
Sources
- Safeguard CLI overview
- Safeguard CLI interactive terminal
- Safeguard CLI usage guide
- Safeguard downloads
- How MCP Guardrail works
- Claude Code security
- Claude Code permissions
- Claude Code data usage
- Codex sandboxing
- Codex enterprise admin setup
- OWASP LLM01: Prompt Injection
- We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs
Last reviewed: 21 October 2026.
