What are the top security risks of AI coding assistants in the enterprise?

Six risks dominate: prompt injection through context files, secret exposure into model context and commits, over-broad shell and tool permissions, unvetted MCP server connections, insecure or hallucinated dependencies in generated code, and an audit gap where nobody can reconstruct what the assistant did. The common factor is that a coding assistant is a new identity holding developer privileges with none of the controls applied to a developer.

Prompt injection lands first because coding agents read instruction files by design. CLAUDE.md, .cursor/rules, .github/copilot-instructions.md, README files, code comments, and issue bodies all enter context, and any of them can be edited by a contributor or a dependency. The agent cannot distinguish your instruction from text it read in a file.

Secret exposure runs both directions. The agent reads .env files into context and ships them to a model provider, and it writes credentials into code it commits. Both paths bypass the developer who would have caught it.

Permissions are the quiet one. Approving an agent to run shell commands once usually grants it every capability the developer shell has, including cloud CLI sessions already authenticated against production.

MCP servers extend that reach further, and their tool descriptions are executable instructions the agent trusts implicitly.

Akto Atlas covers the discovery and monitoring side, inventorying which AI coding tools are in use across the organization, what repositories and data they touch, and where usage falls outside sanctioned configuration.

Every one of these was exploitable before. What changed is that the exploit now runs at machine speed inside a trusted session.