AI coding tools no longer merely suggest functions; they can modify files, run terminal commands, download dependencies, and prepare pull requests. Although these capabilities accelerate development, every tool given to an agent creates a new trust boundary. The safe starting point is not “How intelligent is the model?” but “How far can it reach if it makes a mistake or encounters a malicious instruction?”
Define the task and permission boundaries first
Instead of giving the agent an open-ended task such as “fix the project,” specify which directories it may change, which tests it may run, and which production resources it must not touch. Conduct the first trial in a separate branch, a temporary workspace, or an isolated development environment. Do not allow the agent to write directly to the main branch, publish a release, or modify production infrastructure.
Reduce permissions according to the task. An agent that only updates documentation should not have access to a cloud account, a package publishing key, or a customer database. Do not grant write permission when read-only access is sufficient. Email, task-management systems, and cloud services accessed through tool integrations should also be included in the risk assessment as though they were part of the repository.
Do not treat text in the repository as trusted instructions
Prompt injection is not limited to a hostile command typed into a chat box. An issue, web page, package document, test output, source-code comment, or hidden text read by the agent may also carry instructions such as “forget the previous rules” to the model. OWASP classifies this kind of externally sourced content as indirect prompt injection and states that no flawless prevention method is known.
Therefore, treat externally obtained content as data, not as instructions that confer authority. Do not allow community-contributed issues or pull-request text to launch a privileged agent automatically. Use code ownership and mandatory review rules to restrict who can change agent instruction files in the repository. Filtering invisible HTML comments or unusual Unicode characters can help, but it is not a security boundary by itself.
OWASP source: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
Remove secrets from the workspace
The safest secret is one the agent never sees. Do not place real `.env` files, personal access tokens, production connection strings, or private keys in the agent's context. For testing, use short-lived, least-privileged credentials that are valid only in the test environment. Remember that command output and logs may also contain keys, customer data, or private URLs.
After the agent makes changes, inspect not only the source files but also the Git diff and any new untracked files. Run a secret scan before committing. If you believe a key was accidentally included in the context, do not merely delete it from the file; revoke and rotate it. The value may remain in chat history, terminal output, or remote-service logs.
Keep network access disabled by default
Unrestricted internet access can make it easier for a malicious instruction to send code or secrets to an external address. If network access is required, use an allowlist limited to essential package registries and documented domains. Pin dependency versions, and check the package name, source, and maintenance status before allowing the agent to run an arbitrary installation command.
GitHub's cloud-agent documentation explicitly states that the firewall can reduce the risk of data exfiltration but does not cover every process or MCP server and may be bypassed by sophisticated attacks. A firewall therefore does not replace reduced privileges, secret isolation, or human review.
GitHub firewall source: https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/customize-the-agent-firewall
Require human approval for dangerous actions
Reading a file and deleting one do not carry the same risk. Divide commands into at least three classes: low-risk operations that may run automatically, changes that require approval, and actions that are entirely prohibited. Publishing packages, deploying to production, changing database schemas, modifying access policies, transferring money, sending external messages, and performing deletions that are difficult to reverse should require explicit human approval.
The approval screen should not merely ask “Continue?” It should show the command to be run, the target environment, the resources that will change, and the potential impact. Do not accept the agent's own explanation as evidence. Check the actual Git diff, test results, and deployment plan directly through the tools.
Review generated code as a contribution
Code compiling does not mean it is safe or correct. Break the change into small pieces and run formatting, static analysis, unit tests, integration tests, dependency scans, and secret scans. Pay particular attention to security boundaries such as authentication, authorization, file uploads, HTML processing, and query construction. Check that tests added by the agent do not merely validate its own solution and legitimize incorrect behavior.
NIST's generative AI risk profile recommends testing outputs against known correct data and using different evaluation methods, while documenting human oversight and content provenance. In practice, this means looking for reproducible tests, independent review, and traceable records instead of relying on the agent's confident explanation.
NIST source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
A five-minute final check
Before starting the task, list the repositories, tools, networks, and accounts the agent can access. Remove real secrets, and use a separate branch and an isolated environment. Treat external content as untrusted data. Put an approval gate in front of destructive actions or actions that affect the outside world. When the work is complete, independently review the diff, tests, dependencies, and secret scan; retain session logs and revoke temporary credentials.
The goal is not to make the agent completely risk-free. The goal is to establish a workflow in which a single mistake cannot reach production systems, corporate secrets, or user data; every important operation can be reversed; and it is possible to see who initiated what.