An AI coding agent security checklist should limit what an agent can read, write, execute, install, and deploy before it is allowed to work autonomously. The practical baseline is least-privilege access, a disposable sandbox, verified dependencies, secret isolation, network controls, automated scans, human approval for high-impact actions, and logs that make every tool call explainable.
AI coding agents are different from autocomplete tools. Claude Code, Cursor, GitHub Copilot agent features, and similar systems can inspect a repository, modify files, run shell commands, install packages, call external services, and prepare a release. That autonomy is useful, but it also expands the attack surface from the generated code to the development environment itself.
This checklist is for developers and small engineering teams that use AI to ship web, mobile, or backend software. It complements a deeper AI-generated codebase audit by focusing on the agent's permissions and operating boundary during the coding session.
Why does an AI coding agent need a separate security checklist?
Traditional code review asks whether a change is correct, secure, and maintainable. An agent security review asks an additional question: what could the tool do while producing that change? A malicious instruction hidden in a README, issue, webpage, dependency, or test fixture can influence the agent if the agent treats repository content as trusted instructions.
Once an agent can run commands or use credentials, a prompt injection or hallucinated package can have effects outside the source file being edited. The OWASP Top 10 for Agentic Applications 2026 frames this wider problem around risks such as identity and privilege abuse, tool misuse, and agentic supply-chain vulnerabilities.
The goal is not to pretend that prompts can be made perfectly trustworthy. Design the workflow so that a compromised or mistaken agent has limited reach, cannot silently approve its own actions, and leaves enough evidence for a human to investigate.
AI coding agent security checklist at a glance
| Control | What to verify | Default decision |
|---|---|---|
| 1. Scope the workspace | The agent can access only the repository and files required for the task | Deny home directories, production data, and unrelated repositories |
| 2. Separate permissions | Read, write, execute, install, network, and deploy are separate capabilities | Start read-only, then grant one capability at a time |
| 3. Use a disposable sandbox | Generated code and tests run in an isolated environment that can be reset | No production credentials or personal files in the sandbox |
| 4. Protect secrets | Tokens, keys, customer data, and private prompts stay outside the agent context | Use placeholders and short-lived credentials |
| 5. Verify dependencies | New packages exist, are reputable, licensed correctly, and are pinned or locked | Require review before installation |
| 6. Control network access | Outbound requests are visible and limited to approved domains and services | Deny by default in test environments |
| 7. Gate the merge and deploy | Tests, type checks, SAST, SCA, and human review run before release | The agent cannot merge or deploy its own change |
| 8. Log and recover | Tool calls, approvals, diffs, package changes, and rollback paths are recorded | Keep an audit trail and a fast reset path |
1. Scope the agent to a disposable workspace
Give the agent the smallest file boundary that can complete the task. A frontend bug fix may need app/, components/, and tests, but it does not need your SSH directory, cloud credential folder, another client's repository, or a production database dump.
Write the boundary down in the agent's project instructions. Name directories that are forbidden, commands that require approval, and files that may contain secrets. Remember that an ignore rule is not a security boundary: the agent can still read a file if the operating system and tool permissions allow it.
Review symlinks and mounted directories as well. A path that appears to be inside the workspace can point somewhere else. The process running the agent should not have broad access that defeats the repository boundary.
2. Split read, write, execute, install, and deploy permissions
Do not treat access as a single trusted or untrusted switch. Reading source code is lower risk than editing it. Editing is lower risk than running an unreviewed script. Running a script is lower risk than installing a package, opening a network connection, migrating a database, or pushing a release.
Use a staged workflow:
- Plan: allow repository reads and request a proposed change list.
- Implement: allow writes inside the workspace, with the diff visible.
- Verify: run tests in a sandbox with restricted network and temporary data.
- Release: require an independent human or CI identity to merge and deploy.
This separation reduces the blast radius of both prompt injection and ordinary model mistakes. It also prevents the agent from changing the code, changing the tests, and approving the result as one uninterrupted action.
3. Run generated code in a resettable sandbox
Generated code is untrusted until it has passed review and automated checks. Run build scripts, test fixtures, migrations, and code interpreters in a container, virtual machine, or platform sandbox that can be deleted and recreated. Restrict filesystem access, process creation, and outbound network traffic according to the test's needs.
A sandbox is not a substitute for application security. It is a containment layer that protects the developer workstation and nearby systems while the code is being evaluated. Snapshot the environment before risky experiments and use synthetic data instead of copied customer records.
If the project needs a service such as a database or queue, provide a local test instance with an isolated account. Do not connect an autonomous coding session directly to production simply because the application works locally.
4. Keep secrets and sensitive data outside the agent context
Never paste API keys, passwords, private certificates, customer records, or production connection strings into a prompt. Use environment variable names, redacted fixtures, and test credentials with narrow scope. Rotate any secret that was accidentally exposed to the model, terminal transcript, logs, or generated patch.
Protect the files that normally carry credentials, including .env, cloud credential directories, SSH keys, signing keys, and CI configuration. A secret scanner should run against the working tree and the full diff, not only the final source file.
OpenSSF's security-focused guide for AI code assistant instructions recommends treating AI-written code and development instructions as security-sensitive. The same principle applies to the information supplied to the assistant.
5. Verify every dependency before installation
AI models can suggest a plausible package name that does not belong to the intended project. Attackers can register such names and wait for automated or hurried installation. This supply-chain technique is commonly called slopsquatting.
Before accepting a new package, verify its exact name on the official registry, repository ownership, release history, license, maintainer activity, and transitive dependencies. Prefer the existing lockfile and package manager's integrity checks. Review why the dependency is needed and whether a platform or standard-library feature already solves the problem.
Run software composition analysis and lockfile checks in CI. OpenSSF's dependency firewall guidance describes the value of monitoring package requests, validating provenance, inspecting transitive dependencies, and requiring approval for suspicious or newly published packages. The related hallucinated dependency guide covers the implementation details.
6. Treat repository content and web results as untrusted input
An agent may read a README, issue, documentation page, generated fixture, or package script and encounter text that looks like an instruction. Separate data from authority: repository content can describe the system, but it cannot grant permissions or override the agent's operating policy.
Require the agent to show the source of instructions that influence a plan. Do not let content fetched from the web authorize shell commands, package installs, credential access, or deployment actions. Review tool arguments, not just the natural-language explanation that follows them.
For applications that themselves use LLMs, also validate model outputs before passing them to a shell, database, template, or browser. The controls in this checklist protect the coding session, while input validation and authorization protect the application at runtime.
7. Gate changes with tests, scans, and independent approval
A green type check does not prove that an AI-generated change is safe. Before merge, run the checks appropriate to the risk:
- Unit, integration, and end-to-end tests for intended behavior and failure paths.
- Type checking, linting, formatting, and a production build.
- Secret scanning, static application security testing, and dependency scanning.
- Authorization, input validation, rate-limit, and error-handling tests at trust boundaries.
- License and provenance checks for newly introduced code and packages.
GitHub's review guidance for AI-generated code organizes review around functional checks, context and intent, code quality, dependencies, AI-specific pitfalls, collaborative review, and automation. Use those categories as a human review prompt, then make the high-confidence checks mandatory in CI.
Label AI-assisted pull requests if that helps the team choose review depth. High-impact changes involving authentication, payments, infrastructure, data migrations, public APIs, or personal data should receive explicit human sign-off even when every automated check passes.
8. Log actions and keep recovery cheap
Record the agent identity, repository revision, prompt or task reference, tool calls, approvals, changed files, package changes, test results, and release decision. Logs should be useful for incident response without storing secrets or unnecessary private prompt content.
Every autonomous workflow needs a recovery plan. Keep changes in a branch, preserve reviewable diffs, make database migrations reversible where possible, and ensure deployment can roll back to a known-good artifact. Observability should cover the application after release too. If your Next.js project has no operational visibility, use this AI Next.js observability checklist as the next step.
How should a small team implement this checklist?
Start with the controls that reduce catastrophic reach: workspace isolation, no production credentials, manual approval for shell and package installation, and CI-owned merge and deployment. Then add dependency provenance checks, restricted network access, action logging, and risk-based review tiers.
Test the policy with harmless failure scenarios. Put a fake secret in a test fixture and verify that the agent cannot read it. Add a deliberately untrusted instruction to a sample README and verify that the agent reports it instead of executing it. Request a nonexistent package and confirm that installation stops for review. These tests show whether the boundary is enforced, not merely documented.
Finally, revisit permissions when the workflow changes. A tool that was safe for a read-only review may be too powerful for an autonomous refactor. The App Development Decision Matrix can help decide when a prototype has crossed into a production system that needs stronger architecture and release controls.
Frequently asked questions about AI coding agent security
What is the most important AI coding agent security control?
The most important control is limiting the agent's effective permissions. Start with a scoped workspace, no production credentials, and manual approval for commands, package installation, network access, and deployment.
Can a coding agent safely run shell commands?
It can run selected commands in a disposable, restricted environment. Do not give an autonomous agent unrestricted shell access on a workstation or server that contains secrets, production data, or unrelated projects.
How do I prevent an AI agent from installing a malicious package?
Require approval for new packages, verify the exact registry name and provenance, review the license and transitive dependencies, use a lockfile, and run software composition analysis in CI. Treat a model's package recommendation as untrusted input.
Should AI-generated code always receive human review?
Yes for changes that affect security boundaries, data, infrastructure, public APIs, payments, or deployment. Automated checks can cover repeatable failures, but a human still needs to confirm intent, architecture, and risk for high-impact changes.
Is a sandbox enough to secure an AI coding agent?
No. Sandboxing limits damage during execution, but it does not replace secure code review, dependency verification, secret management, authorization tests, or release controls. Use the sandbox as one layer in a defense-in-depth workflow.