開発現場のAIセキュリティを見直す This article re-examines AI security risks in software development environments and offers…

AI coding assistants and agentic tooling have moved from novelty to daily infrastructure inside many engineering teams, and that shift is forcing a fresh look at the security assumptions that surround them. As models gain the ability to read repositories, execute commands, and reach external systems through standards such as the Model Context Protocol (MCP), the boundary between a helpful assistant and an unmonitored actor with broad access has become harder to define. Re-examining these risks is worthwhile because the convenience of AI in development often outpaces the controls placed around it.

The core concern is that AI tools now sit deep inside the software delivery pipeline. A modern assistant may have visibility into source code, environment variables, configuration files, ticket systems, and cloud consoles. MCP, an open standard originally introduced by Anthropic and since adopted across a range of clients and servers, formalizes how a model connects to these data sources and tools. It defines a client-server pattern in which an MCP server exposes capabilities—file access, database queries, API calls—that the model can invoke. This design is powerful, but it also means that granting an assistant one connection can effectively delegate meaningful authority to an automated system whose behavior is probabilistic rather than deterministic.

Several risk categories deserve attention. Prompt injection remains the most discussed: untrusted content pulled from a web page, an issue comment, or a dependency's documentation can contain instructions that the model treats as legitimate, potentially causing it to leak secrets or take unintended actions. When an assistant has both the ability to read sensitive data and the ability to send outbound requests, injection can escalate into data exfiltration. Over-permissioning is a related issue; MCP servers and tokens are frequently configured with broad scopes for convenience, so a compromised or manipulated tool can reach far beyond its intended function. Supply chain exposure is also relevant, because third-party MCP servers, plugins, and extensions may be installed with limited scrutiny of their code or the endpoints they contact.

The practical guidance emerging around these tools tends to emphasize least privilege and clear boundaries. That includes scoping credentials narrowly, issuing read-only access where write access is not required, and separating development, staging, and production contexts so an assistant cannot accidentally touch live systems. Reviewing which MCP servers are installed, where they send data, and what permissions they hold is a reasonable baseline. Teams are also advised to keep humans in the loop for consequential actions—such as deleting resources, merging code, or running deployment commands—rather than allowing fully autonomous execution. Logging and auditing of tool calls help reconstruct what an assistant did and why, which is difficult to do after the fact if no record exists.

Handling of secrets and source code is a persistent theme. Sensitive values should ideally be kept out of prompts and out of any context the model can read, and organizations increasingly rely on secret managers rather than plaintext environment files. Where code is sent to a hosted model, data-retention and training-use policies matter, which is one reason some teams evaluate self-hosted or enterprise tiers that offer contractual assurances or local inference. These choices involve trade-offs between capability, cost, and control that each team must weigh.

The broader context is an industry still maturing its practices. Established application security concepts—threat modeling, the principle of least privilege, zero-trust boundaries, and dependency review—apply directly to AI-assisted development, but the tooling to enforce them is comparatively new. Frameworks such as the OWASP Top 10 for Large Language Model Applications attempt to catalog these failure modes, and vendors are gradually adding permission prompts, sandboxing, and allowlists to their clients. Adjacent developments, including agent frameworks and IDE integrations that chain multiple tools together, appear likely to increase both the utility and the attack surface of these systems.

The overall message is not that AI tooling should be avoided, but that it should be governed with the same rigor applied to any component holding access to code and infrastructure. Treating an assistant as a privileged identity, constraining what it can see and do, and maintaining visibility into its actions are pragmatic steps. As MCP and similar standards continue to spread, revisiting these controls periodically is likely to remain a necessary part of secure engineering practice.