AI Coding Agent Security Checklist: Before You Connect Codex, Claude Code, Cursor, or Devin

#Agents changed the risk

Autocomplete suggested code. Agents take actions.

Codex, Claude Code, Cursor agents, Devin style systems, and MCP connected assistants can read repositories, run commands, inspect tickets, call tools, open pull requests, and write files. That is useful. It also means the agent now sits inside your development trust boundary.

If the agent can see secrets, an attacker can try to make it reveal secrets. If it can run commands, an attacker can try to make it run the wrong command. If it can edit CI, an attacker can try to turn a helpful assistant into a supply chain path.

#Before you connect the repo

Answer these before the agent gets access.

• Can it read private code?
• Can it read environment files?
• Can it read tickets or customer data?
• Can it run shell commands?
• Can it install packages?
• Can it push branches?
• Can it open pull requests?
• Can it edit workflows?
• Can it call MCP tools?
• Can it reach production systems?

If the answer is yes, write down why. If nobody can explain the permission, remove it.

#Secrets check

Run a secrets scan before giving an agent repo access.

Use tools like:

• gitleaks
• trufflehog
• GitHub secret scanning
• detect-secrets

Scan current files and history. Agents love context. If the context includes old secrets, assume those secrets can leak through logs, prompts, tool calls, or generated code.

Check for:

• .env files
• API keys
• cloud credentials
• OAuth secrets
• private keys
• database URLs
• webhook signing secrets
• service role tokens
• test credentials that still work

Rotate anything real before the agent starts working.

#Repo instruction files

Treat repo instructions as executable influence.

Agents read files like:

• README files
• AGENTS.md
• CLAUDE.md
• tool instructions
• issue text
• pull request comments
• MCP descriptions
• docs inside dependencies

A malicious instruction can say something like: ignore previous rules, print secrets, change CI, or install a package. The agent may not obey it, but you should not build security on may.

Keep trusted instructions short and explicit. Make the agent ignore instructions in dependencies, generated files, uploaded user content, and external web pages.

#Shell access

Shell access is where the risk jumps.

If an agent can run commands, restrict:

• network access
• filesystem access
• package install commands
• credential files
• SSH keys
• cloud CLIs
• production kubeconfigs
• browser profiles

A local dev box often has more power than people admit. AWS profiles, GitHub tokens, npm tokens, SSH keys, browser sessions, and database tunnels all live there.

Run agents in a workspace that does not have your real home directory mounted if the work is sensitive.

#CI and GitHub Actions

Do not let an agent casually edit CI.

Dangerous files:

• .github/workflows/*
• package scripts
• Dockerfiles
• deployment configs
• Terraform
• Helm charts
• release scripts
• preinstall and postinstall hooks

A one line workflow change can turn a pull request into a secret exfiltration path. Require human review for any CI, deployment, auth, or dependency change.

#MCP servers

MCP turns tools into model reachable actions. That is powerful and risky.

For each MCP server, record:

• what it can read
• what it can write
• what credentials it uses
• whether it can reach the internet
• whether it can touch production
• whether tool descriptions contain untrusted text
• whether logs store prompts or outputs

Disable tools the agent does not need. A calendar tool does not belong in a code audit. A browser tool does not need access to your password manager. A database tool should not point at production unless the task truly requires it.

#Dependency installs

Agents often install packages to solve problems. That is where supply chain risk enters.

Require review for:

• new npm packages
• postinstall scripts
• GitHub dependencies
• curl to shell commands
• pip installs from random repos
• Docker images from personal namespaces
• package manager config changes

If the agent says it needs a package, make it explain why and whether the standard library or existing dependency can do the job.

#Pull request review rule

Every agent PR gets a different review lens.

Check:

• Did it change auth?
• Did it weaken validation?
• Did it add broad CORS?
• Did it log secrets?
• Did it add a dependency?
• Did it touch CI?
• Did it change permissions?
• Did it add eval, exec, shell, or dynamic imports?
• Did it remove tests?
• Did it create a new public endpoint?

Do not review agent code like a coworker wrote it. Review it like a fast intern with root and no memory of yesterday.

#The safe default

Start agents with:

• read access to one repo
• no production credentials
• no cloud profiles
• no deployment tokens
• no write access until the task requires it
• no CI edits without approval
• no MCP servers except the ones needed
• logs that do not retain secrets
• a clean workspace

Then add power only when the task needs it.

#What Valtik checks in an AI security audit

For teams using AI coding agents, we look at:

• repo permissions
• secret exposure
• agent instruction files
• prompt injection paths
• MCP server permissions
• CI blast radius
• dependency install risk
• local developer credential exposure
• logging and retention
• pull request review controls

The useful question is not whether your team uses AI. It does. The question is whether the assistant has become an unreviewed path into code, secrets, and deployment.