An AI coding agent can read a project, change files and use tools to complete a development task. Choosing one therefore means deciding what access you are comfortable giving it, alongside whether its code is useful.
For a security or IT leader, the practical question is: Can we explain what this agent can read, change and send elsewhere in the setup we intend to use? Start there before comparing coding benchmarks.
Compare the setup your team will actually use
A product name is too broad for a security decision. A developer working locally, a cloud agent running on a separate machine and an agent connected to company systems can have different access and approval settings.
Record the product, subscription, interface and integrations being assessed. Then use the vendor's current documentation to check the controls. The following starting points were reviewed on 13 October 2026; they are not a ranking of the products' security.
| Product | Documented starting point | What to verify in your pilot |
|---|---|---|
| Claude Code | Anthropic documents permission modes and a shell sandbox with filesystem and network isolation. | Which mode is active, which commands can run and which files and network destinations are reachable. |
| Codex | OpenAI distinguishes sandbox boundaries from the policy governing action approvals. | The effective boundaries and approval rules for the interface and execution environment you use. |
| Cursor | Cursor documents agent controls and a Privacy Mode that prevents training on your data when enabled. | Privacy settings, agent execution controls and the behavior of local and cloud workflows separately. |
Read the details in Claude Code's security guidance, OpenAI's sandbox documentation and Cursor's security documentation. Availability and behavior can depend on the plan and configuration, so check the specific setup rather than treating a documentation page as proof that a control is enabled.
Separate data protection from permission to act
Two questions often get mixed together during procurement:
- Data handling: Where does source code, a prompt, an index or an activity log go? What is retained, who can access it and can it be used for training?
- Action permissions: Can the agent change files, use credentials, contact external services or publish something?
A favorable answer about training does not establish a safe execution boundary. Conversely, an isolated execution environment does not answer every question about vendor retention or subprocessors.
Ask the vendor for the applicable data-handling terms and ask your engineering team to demonstrate the effective permissions. Both answers belong in the approval record.
Use this checklist before approving a coding agent
The same questions work across products. A small security team can use the table as a review worksheet, adding an owner and evidence beside each answer.
| Review area | Question to answer | Useful evidence |
|---|---|---|
| Project access | Which repositories and directories can the agent read or change? | Repository grants and effective filesystem restrictions. |
| Company data | Which data classes may employees include in prompts or connected tools? | Approved data rules and the relevant vendor terms. |
| Network access | Which destinations can the execution environment contact? | Network policy and a safe demonstration of a blocked destination. |
| Credentials | Which identity and credentials are available to the agent? | Scoped access, credential lifetime and a revocation procedure. |
| Connected tools | Who approves integrations and their permissions? | Integration inventory with owners and approved scopes. |
| Consequential actions | Who approves publishing, destructive changes or access expansion? | Approval rules and named reviewers. |
| Accountability | What activity can you investigate afterward? | Available logs, code-review records and a reporting contact. |
Some controls may sit in your existing development platform rather than the coding agent. Record that dependency. For example, a mandatory human review may be enforced through repository rules; the agent's ability to propose code does not need to include permission to merge it.
Test boundaries with a small, realistic pilot
Choose a representative project with synthetic data and no production credentials. Give the agent an ordinary task, such as updating documentation or proposing a small change with tests.
Check the proposed changes and observe the permissions it requests. Can it reach an unrelated directory? Does an unapproved network destination stay blocked? Can it propose a pull request while a human retains responsibility for merging it?
Use harmless test targets and an approved environment. Keep a short record of the configuration, observed behavior and limitations. Repeat the relevant checks when you change execution mode or add an integration.
Avoid making the pilot a contest for the longest task completed without intervention. You are testing whether the boundaries hold while the tool does useful work.
Make the approval usable for employees
An approval should tell developers which account to use, which projects are in scope, which data is permitted and when they need another person's review. Give them a contact for uncertain requests and an easy way to report unexpected behavior.
Include examples in security awareness training: a request for a broader permission, a prompt containing customer data and an unfamiliar instruction found in a repository. Our guide to prompt injection in AI coding agents provides a short exercise for that conversation.
Start with the smallest access that makes the pilot useful. Expand it only when an owner can explain the need and verify the new boundary. That gives your team a clear route to adopting the agent without leaving the approval decision to each developer.
