AI Coding Agents Security Guide: Protecting Secrets, Code and Pipelines

AI coding agents sit in the most credential-rich place in the organisation: the developer's machine and the software delivery pipeline. They read source code and configuration, run shell commands, install packages, open pull requests and connect to cloud, repository and database tools through MCP servers. They do this with the developer's access, often with little separation between "suggest" and "execute". That makes them highly productive and, if misdirected or compromised, a fast path to secrets, source code and production. This guide covers the identity and security risks of AI coding assistants and agents, in the IDE, the terminal and CI/CD, and the controls that let teams use them safely.

Key takeaways

• A coding agent inherits everything the developer's environment can reach: local files and .env files, cloud CLI sessions, SSH keys, Git credentials, package registry tokens and MCP server credentials.
• The biggest risks are secrets entering the agent's context, agents acting with over-scoped tokens, untrusted repositories and dependencies steering the agent, and supply chain attacks on the tools themselves.
• Run agents in sandboxes with scoped, short-lived credentials, not directly in a developer's fully privileged session.
• Keep humans in control of irreversible and production-affecting actions, enforced by tooling and permissions rather than instructions.
• In CI/CD, give agents their own workload identities with narrow, keyless access, never a shared personal access token.

Where coding agents run

• IDE assistants and extensions: completion and chat inside the editor, increasingly with the ability to edit files and run commands.
• Terminal and command-line agents: agents that plan and execute multi-step changes, run tests, use Git and call tools from the developer's shell.
• Cloud and background agents: agents that work on a repository in a hosted environment and open pull requests for review.
• CI/CD agents: agents triggered by issues, pull requests or pipeline events to review, fix or generate code.
• "Vibe coding" platforms: tools where the agent builds and deploys whole applications, often including databases and hosting.

Each has a different identity picture. IDE and terminal agents usually run as the developer. Cloud and CI/CD agents usually run under a platform or pipeline identity. Vibe coding platforms often hold production credentials directly.

The risks

1. Secrets in the agent's context

Agents read files to understand a project. If .env files, configuration with embedded credentials, private keys or cloud credential files are in scope, their contents can end up in prompts sent to a model provider, in logs, in generated code and in commit messages. Once a secret has been in a model's context, treat it as potentially exposed. This extends the secret sprawl challenge into AI tooling.

2. Ambient, over-scoped credentials

A developer's terminal typically has an authenticated cloud CLI, a Git credential helper and package registry tokens. An agent running there can use all of them. When an agent hits a permissions error it may look for another credential that works. In the PocketOS incident, a coding agent found an API token with blanket authority and deleted a production storage volume and its backups. In the Replit incident, an AI coding assistant deleted a live database during a test and created thousands of fake users.

3. Prompt injection from code and content

Repositories, issues, pull request descriptions, documentation, dependency README files and web pages the agent fetches can all contain instructions. A malicious contribution or a poisoned dependency can tell an agent to add a backdoor, weaken a check, or send environment variables to an external URL. Agent instruction files (such as AGENTS.md and tool-specific rule files) are also a target: whoever can edit them can steer the agent.

4. Unsafe command execution

Agents that run shell commands can execute destructive or exfiltrating commands, whether hallucinated or injected. The Gemini CLI vulnerability allowed silent code execution. OWASP lists this as ASI05, Unexpected Code Execution.

5. Supply chain attacks on AI tools and packages

• The Amazon Q coding agent compromise saw data-wiping instructions injected into a published extension.
• The JetBrains Marketplace AI plugin campaign used malicious plugins to steal AI API keys from developers.
• The malicious Nx package attack, Shai-Hulud npm campaign and Mastra npm backdoor targeted developer credentials through package ecosystems that coding agents install from.
• Hard-coded secrets in VS Code extensions show that the tooling itself can leak credentials.

Coding agents amplify these risks because they install packages and extensions quickly and on the model's judgement, including packages that do not exist (a hallucinated name an attacker can register).

6. MCP server credentials

Coding agents commonly connect to GitHub, cloud, database and ticketing MCP servers configured with long-lived personal access tokens in local JSON files. See the MCP Security Guide.

7. CI/CD agent identities

Agents in pipelines often run with the pipeline's token, which may be able to push to protected branches, publish packages or deploy. An agent triggered by an external contributor's issue or pull request may process attacker-controlled text while holding those permissions. The tj-actions supply chain attack showed how CI/CD secrets leak at scale when a single component is compromised.

8. Attribution

When an agent commits code or runs commands as the developer, logs cannot distinguish the human from the agent. That weakens code review, incident investigation and compliance evidence.

Controls for local agents (IDE and terminal)

• Sandbox the agent. Run it in a container, development container or virtual machine with only the project mounted, no access to home-directory credential stores, and restricted network egress. Many agents offer built-in sandbox and permission modes; use the most restrictive that works.
• Keep secrets out of the workspace. Use a secrets manager or runtime injection instead of .env files; configure agent ignore rules for credential files; scan the workspace for secrets before enabling an agent.
• Scope the credentials the agent can use. Give it a separate, short-lived, least-privilege token for the specific repository or project, rather than the developer's session. Never let it use production or admin credentials.
• Require approval for risky actions. Configure the agent to ask before running shell commands, installing packages, pushing code or calling tools that change external systems, and keep auto-approve lists short.
• Control what the agent can install. Route package installs through an internal registry or proxy with allowlisting, and block newly published or unknown packages by default.
• Allowlist extensions, plugins and MCP servers through device management, and keep them updated.
• Protect instruction files. Treat AGENTS.md and agent rule files as code: require review for changes, and be cautious running agents on untrusted repositories.

Controls for cloud and CI/CD agents

• Give each agent its own workload identity, separate from human accounts and other pipelines.
• Use keyless authentication: OIDC-based workload identity federation from the CI platform to the cloud, with trust policies pinned to the specific repository, workflow and branch. See the NHI Authentication Guide and Cloud Workload Identity Guide.
• Limit repository permissions: the agent can create branches and open pull requests, but cannot push to protected branches, approve its own changes, change workflows or publish releases.
• Separate untrusted input from privileged execution. Do not run agents with write tokens or secrets on events triggered by external contributors.
• Require human review of every agent-authored change before merge, with branch protection enforcing it.
• Keep deploy credentials out of reach: agents build and test; separate, controlled pipelines deploy.

Governance

• Publish an approved list of coding assistants and agents, with the configuration each must use.
• Register agents that run with their own identities (cloud and CI/CD) in your NHI inventory, with an owner.
• Mark agent-authored commits and pull requests (for example with commit trailers or a dedicated bot identity) so reviewers and auditors can tell them apart.
• Monitor for secrets in prompts, logs and agent-generated commits, and rotate any secret that has entered an agent's context.
• Include coding agents in secure development training and in your agentic AI security policy.

Practitioner checklist

• Coding agents run in a sandbox without access to the developer's credential stores.
• No long-lived secrets in project files; credential files excluded from agent context.
• Agents use separate, scoped, short-lived tokens, never production or admin credentials.
• Shell commands, package installs, pushes and external tool calls require approval unless explicitly allowlisted.
• Packages come through an allowlisting registry proxy; extensions, plugins and MCP servers are approved and pinned.
• CI/CD agents use keyless workload identity with trust policies pinned to repository, workflow and branch.
• Agents cannot merge, approve, change workflows or deploy; branch protection enforces human review.
• Agent activity is distinguishable from human activity in commits and logs.
• Any secret exposed to an agent's context is rotated.

Standards and references

• OWASP Top 10 for Agentic Applications for 2026: ASI01, ASI02, ASI04, ASI05
• OWASP Non-Human Identities Top 10 (2025): NHI2 Secret Leakage, NHI3 Vulnerable Third-Party NHI, NHI6 Insecure Cloud Deployment Configurations, NHI10 Human Use of NHI
• Model Context Protocol specification
• SLSA: Supply-chain Levels for Software Artifacts
• NIST SP 800-218: Secure Software Development Framework

Related NHI Mgmt Group resources: MCP Security Guide · Guide to the Secret Sprawl Challenge · NHI Authentication Guide · 52 Non-Human Identity Breaches