Limit a coding AI’s access to the work it needs to do

Imagine using AI to add a download feature to maintenance software. An operations manager wants the month’s completed jobs in Excel. The AI needs to change the code producing a CSV file, a spreadsheet-compatible data format, and try the result.

For this job, the team can provide an application copy and fictional service records. The AI does not need to inspect real customer companies’ files. It also does not need to publish the change to the software they use.

This separation limits the effects of a wrong command or misleading instruction encountered during the work. The tools need to enforce it, and the team needs to verify it.

Connect each permission to a required action

Ask the team to show which operations the work requires. Reading relevant files, editing them and running tests are identifiable needs. Administrative access across all services extends far beyond them.

The following arrangement fits our example. Existing development and release facilities can fill these roles.

Stage	Access needed in this example	Limit to enforce
Develop	Relevant code, a working copy and fictional data	No access to real customer records or the live application
Verify	Proposed version and a test environment	Code running during tests cannot obtain production credentials
Publish	Approved version and permission to release it	Release authority cannot execute arbitrary unverified code
Change the rules	A proposal the responsible person can examine	The AI cannot expand its own permissions or remove a required check

Pay particular attention to the test service. It executes the code the AI proposes. If that service holds credentials for real customer records, the code may use them even when the AI never directly sees the credentials.

Make the tools enforce the boundary

An instruction saying “do not touch customer data” explains the intention. The configuration also needs to prevent the action. The AI can read pages, tickets or files containing incorrect or malicious instructions. That text should not be enough to authorize an operation.

OWASP’s AI Agent Security guidance places authorization enforcement in the component executing the action, outside the model’s context. The system can then check the actor, resource, operation and required approval.

Inspect what the environment can read and reach: mounted directories, launched programs, network connections and external services. Blocking one command may leave another route to the same resource. Anthropic’s containment report illustrates why filesystem and network limits need to be considered together.

Resolve a blocked need without opening the whole system

Suppose the AI needs a test report to investigate a failure. The team can provide that report after removing sensitive information, for a defined period. This exception addresses a specific need.

The person approving it needs to know what will be read or changed and why. If the target or action changes, the earlier approval does not automatically cover the new request. Temporary access needs an expiry and a way to revoke it.

When an operation is refused, identify what is missing first. The tool may need a more precise command or a test-service connection. Sharing an administrator account for convenience would undo the original boundary.

Maintain control through release

The approved version needs to remain identifiable through installation. Released files should correspond to the files whose checks were examined. A late edit requires the affected checks to run again.

Changes to publication rules need a separate review from application changes. GitHub’s secure-use guidance explains risks from broad permissions and untrusted code running in privileged workflows. The team needs equivalent protections on its own platform.

Test refusals as well as permitted work

In a test environment, establish that the AI can complete its assignment while being blocked from reading a forbidden file, contacting an unapproved destination or publishing an unapproved version. Repeat relevant checks when tools or permissions change.

The previous article examines test quality. These access limits protect testing and publication. The next explains what to do when a faulty change reaches users despite those precautions.