What Should an AI Coding Agent Be Allowed to Access?

Approving an AI coding tool is only the start. Teams also need to decide what it can access and what actions it can take.

Depending on its configuration, a coding agent may inherit access to files, credentials, networks, and connected tools available to the developer. Those permissions should match the task, not simply whatever happens to be available on the machine.

Agentic coding tools are powerful and can create significant boosts to productivity, but many organizations have either too few security parameters around these agents or too many. While the risks of allocating broad permissions to agents can lead to destructive actions, implementing overbearing restrictions can negate the productivity gains agents can allow. We recently talked with developers at an organization that locked things down, leaving them with an approved tool that was years out of date. They'd stopped using it. So how do we get the best of both worlds?

Start with the job, not the tool

Take a routine request: fix this bug and open a pull request. Map what that job needs before you add integrations or broader permissions. It helps to break a job down into 5 permission categories:

• Files. What files does an agent need access to in order to fix the bug? Any project that is not relevant to the task should be kept out of the agent’s reach.

• Execution. What commands will the harness need to run to complete the work? For our example, we likely need commands like build, lint, test, and possibly install, as well as git and gh cli commands needed to open a PR.

• Network. What outside resources can our agent access? Common resources include the model API, package registries, and documentation.

• Credentials. What are the minimum credentials my agent needs? To open a PR you would need a GitHub token with write permissions to a single repository.

• Connected tools. What outside tools are needed for this task? In the case of agents, these are often MCP connections. Agents can invoke tools provided through these connections. Understanding the permissions you are granting these tools can protect you from unintentional destructive actions.

Those last two are easy to underestimate. Anthropic's May 2026 report on how it contains Claude describes integrations running outside an isolated environment, and a case where data left through an API domain that was on the allowed list.

Vet what gets installed

An agent suggesting an npm or NuGet package doesn't mean that package belongs on your machine. Check the exact name, publisher, version and source, run it through your dependency scanning, and decide who approves additions.

Apply the same scrutiny to MCP servers and IDE extensions. In desktop VS Code, an extension runs with the editor's permissions, which usually means it can read files and run processes. Check what that exposes on your developers' machines. IT can centrally restrict which extensions are installed through VS Code's enterprise policies.

OWASP's guidance on supply chain risk recommends vetting suppliers and scanning for vulnerabilities, including in development environments. A clean scan is one piece of evidence. It doesn't prove a component is trustworthy.

Put permissions behind the instructions

Instructions are not security. "Do not touch production" is not sufficient protection for critical systems. Never providing that agent with an identity to access production is a much more robust security practice.

OWASP's guidance on excessive agency names three causes: too much functionality, too many permissions and too much autonomy. It recommends enforcing authorization in the systems the agent calls, not trusting the model to decide what's allowed. For us, that means editing and testing run freely inside a dedicated sandbox, while merging, deploying and infrastructure changes stay behind a person and the permissions of the systems involved.

The same limits reduce what a successful prompt injection can do. These attacks use instructions hidden in a webpage, file or tool result to steer the agent. Anthropic's November 2025 research on browser agents reports real progress against these attacks but says plainly the problem isn't solved. Whatever the agent reads shouldn't gain authority just because it read it.

Test the limits before you trust them

Before any sensitive data is involved, try to break your own setup with harmless test resources:

• Can the agent read a dummy file outside its workspace?

• Can it reach a test site you've blocked, including through an enabled remote tool?

• Does a read-only integration reject a write?

• Does an action that needs approval actually stop?

Check the answer at the filesystem, network or service layer. An agent saying it refused something doesn't prove it couldn't have done it.

Record which tools, versions and access settings you tested. When those change, repeat the checks above to confirm the access limits still work.

Keep reviewing the code the agent produces. Restricting its access limits where it can make changes; it doesn’t guarantee those changes are correct.

None of this makes a coding agent perfectly safe. Nothing does. It turns the risk into something your team chose rather than something it inherited from a default install.

Next: what a sandbox doesn't cover, and how to turn individual AI use into a team practice.

If your developers already use coding agents, pick one real workflow and map its access. We help teams work through the tooling, controls and training that fit their software. Talk with WWC.