AI Coding Agents Security Checklist for Development Teams

By the UXreviewer.io team4 min read

Securing AI coding agents means controlling what they can access, what they can execute and what they can change without human review. The essentials are least-privilege permissions, no production secrets on agent machines, sandboxed or containerised execution, protection against prompt injection from untrusted content, careful handling of new dependencies, mandatory code review and logging of agent actions. These measures apply whichever agent you use.

Coding agents are powerful precisely because they run commands and edit files. That also makes them a new kind of actor in your development environment. The checklist below reflects how we set up agentic workflows in our own ISO 27001 certified environment and in client projects. It is general guidance, not a substitute for your own security assessment.

Why coding agents create new security risks

A traditional autocomplete suggests text that a developer chooses to accept. An agent reads files, executes shell commands, installs packages, calls external tools and may push code. If it is misled or simply wrong, it can leak secrets, delete data, introduce vulnerable dependencies or weaken security controls, often within a single session.

The main threat sources are well understood: overly broad permissions, sensitive data within reach, malicious instructions hidden in content the agent reads (prompt injection), hallucinated or typo-squatted packages, and insecure code patterns that slip through review because the diff is large and looks plausible.

Permissions and execution environment

Start by limiting what the agent can do without asking:

• Use the agent's permission or approval modes; allow-list safe commands such as running tests and linters instead of granting blanket shell access.
• Require explicit approval for network calls, package installation, git push and file deletion outside the project.
• Run agents in containers, dev containers or dedicated VMs, especially for autonomous or background work.
• Give cloud agents scoped, short-lived credentials and restrict their network access where the platform allows.
• Never let agents operate directly on production systems or databases.

Secrets and sensitive data

Agents read files to build context, so anything in the repository or working directory can end up in a prompt. Keep secrets in a secrets manager, not in .env files the agent can read; exclude sensitive paths using the tool's ignore or exclusion settings; use test data rather than real customer data in development; and check the vendor's data retention and training terms for your plan. If you process personal data, involve your data protection officer, as described in GDPR for AI agents.

Prompt injection and untrusted content

Agents increasingly read issues, web pages, documentation and tool output, and some of that content can contain instructions aimed at the model. An attacker could hide a request in an issue comment or a dependency's README asking the agent to exfiltrate environment variables or change a security setting.

Mitigations include treating all external content as untrusted, restricting which MCP servers and tools are enabled, requiring confirmation for actions with side effects, limiting outbound network access and reviewing agent output with injection in mind. Our article on prompt injection risks explains the attack patterns, and MCP explained covers tool connections.

Dependencies and generated code

Agents sometimes suggest packages that do not exist or have names close to popular ones, which attackers can exploit by registering those names. They also reproduce insecure patterns found in training data, such as string-built SQL queries, missing authorisation checks or permissive CORS settings. Treat these as known failure modes:

• Verify every new dependency: existence, maintainer, popularity and licence.
• Pin versions and use lockfiles; run dependency and vulnerability scanning in CI.
• Run static analysis and secret scanning on every pull request.
• Ask reviewers to check authorisation and input validation explicitly in agent-written code.
• Encode secure patterns in project instruction files so the agent follows them by default.

The checklist: before, during and after agent work

Use this sequence as a team standard and adapt it to your risk level:

1. Before: define approved tools, models and MCP servers, and document their data handling.
2. Before: configure permission modes, command allow-lists and path exclusions per repository.
3. Before: provide isolated environments and scoped credentials for autonomous agents.
4. During: keep humans in the loop for side-effect actions and watch for unexpected commands.
5. After: route all agent changes through pull requests with human review and CI checks.
6. After: log agent sessions and tool calls where possible and keep them for audits.
7. Ongoing: review incidents and near misses, then update instructions and policies.

Making security part of the workflow, not a blocker

Security rules that slow developers down get bypassed. The goal is a setup where the safe path is also the convenient one: pre-configured dev containers, shared permission settings checked into the repository, a short list of approved MCP servers and clear review templates for agent pull requests. Training matters as much as configuration; developers need to recognise suspicious agent behaviour and know when to stop a session.

We cover these practices in our agentic coding best practices and in team workshops. For regulated organisations, connect agent governance to your existing information security management system so that audits see one consistent process.

Frequently asked questions