Security for AI Development
Security for AI-Assisted Development
AI coding agents turn development environments into execution environments: they read files, run shell commands, see secrets and call internal services with the developer's permissions. Secure AI-assisted development means giving agents least privilege, keeping them away from production and secrets, sandboxing what they run, and scanning everything they write. Security has to move closer to the developer workflow.
AI coding assistants have changed how security teams must think about risk. Traditional application security focused on the code itself: vulnerabilities in source code, dependencies with known exploits, misconfigured deployment environments. Those risks remain, but AI assistants add a new category of concern. Development environments are no longer passive workspaces where developers write and compile code. They are places where AI agents read files, run shell commands, access environment variables, call APIs through tool integrations and modify the codebase on their own.
This is not a theoretical concern. Tools like Claude Code, Cursor and GitHub Copilot can act with the same privileges as the developer who runs them. When a developer gives an AI assistant access to their terminal, the assistant can execute arbitrary commands with the developer's permissions. When the assistant reads environment files, it can see API keys, database credentials and service tokens. When it connects to internal services through MCP (Model Context Protocol) integrations, it can work with internal APIs, databases and infrastructure in ways that used to be limited to authenticated people. The security perimeter has expanded, and the threat model must expand with it.
New Risk Categories in AI-Assisted Development
AI-assisted development introduces several risk categories that did not exist in traditional workflows. Naming them is the first step toward addressing them.
Prompt injection is the risk that malicious content in the development context manipulates the assistant's behavior. A carefully crafted comment in a source file, a dependency's README or a configuration file could instruct the assistant to exfiltrate data, modify code in harmful ways or bypass security checks. The risk is hard to spot because the malicious instructions sit inside content the assistant processes as part of its normal work. Project-level configuration files are a newer vector: a compromised repository configuration could alter the assistant's behavior for every developer who works on that project.
Unsafe tool use is the risk that an assistant performs dangerous operations through its tool integrations. An assistant with shell access could run destructive commands. One with file system access could overwrite critical configuration files. One connected to production infrastructure through MCP could modify live databases or deploy untested code. Permission gates also struggle with ambiguous state-changing operations, where the line between a read and a write is not always clear and the assistant may interpret a task in a way that causes unintended side effects.
Data leakage is the risk that sensitive information from the development environment ends up in the assistant's context and is sent to external services. When an assistant reads environment files, internal documentation, proprietary source code or customer data in development databases, that information becomes part of its working context. Depending on the tool's architecture, this data may be sent to external APIs for processing. Even when the data is not stored, sending it outside the organization's security boundary may violate data protection policies, contracts or regulations.
Overbroad permissions are the risk that AI assistants get more access than their job requires. The principle of least privilege is well established, but AI assistant configurations often break it because restricting permissions makes the assistant less useful. A developer who gives their assistant read-only access to the codebase and no shell access has a less capable assistant than one who grants full access. The pull toward capability over security is constant.
Insecure generated code is the risk that the assistant produces code containing security vulnerabilities. This risk is well documented and substantial. Research from Veracode found a 45 percent vulnerability introduction rate across more than 100 large language models when generating code. Cross-site scripting is a category AI-generated web code gets wrong especially often. These are not edge cases. They show a systemic pattern: AI assistants generate code that works functionally but fails security requirements.
Malicious repository configuration is the risk that project-level configuration files for AI assistants are used as attack vectors. Many assistants support project-level files that define behavior, permissions and context. If these files are committed to a shared repository, a malicious contributor could modify them to change the assistant's behavior for everyone on the team. The file could tell the assistant to skip certain security checks, pull in extra context that leads to data leakage, or change defaults in ways that create vulnerabilities.
Secret exposure is the risk that credentials, tokens and other secrets end up in AI-generated code, in commits or in the assistant's operations. Assistants with access to environment files may use real credentials in generated code examples. Assistants that commit code on a developer's behalf may include secrets the developer would have recognized and removed but the assistant treated as ordinary configuration values.
How Often AI-Generated Code Is Insecure
The Veracode figure deserves emphasis because it departs sharply from what teams expect of code that compiles and passes its tests. A 45 percent vulnerability introduction rate means that nearly half of the AI-generated code samples in that research contained at least one security vulnerability. Adopting AI coding assistants without matching security measures will increase the number of vulnerabilities in the codebase. Web code needs particular attention, because common and well-understood categories such as cross-site scripting are among the ones AI-generated code most often gets wrong.
This does not mean AI coding assistants are too dangerous to use. It means they require security practices in proportion to the risks they introduce. As code review in the AI era explains, review must explicitly address the security of AI-generated code, and reviewers must understand that syntactically clean code is not necessarily secure code.
Practical Security Recommendations
Addressing these risks takes a layered approach that combines technical controls, process requirements and organizational policy. The following recommendations are a practical starting point for teams using or planning to use AI coding assistants.
Enforce least privilege for AI assistants
Configure AI tools with the minimum permissions their function requires. If the assistant does not need shell access for a task, do not grant it. If it does not need environment files, configure file access controls to exclude them. Use project-level configuration to restrict which directories the assistant can read and write, which commands it can run and which external services it can reach. Limited permissions are inconvenient, and the inconvenience is worth it against the risk of overbroad access.
Prohibit broad production access
AI coding assistants should never have direct access to production environments, production databases or production credentials. Isolate development and staging environments from production, and confine the assistant's access to those isolated environments. If the assistant needs production-like data for testing, use sanitized datasets that contain no real customer information, real credentials or real configuration that could reach production systems.
Protect secrets from AI assistant access
Use .cursorignore, .gitignore and the equivalent mechanisms in other assistants to keep sensitive files out of the assistant's context. Explicitly exclude environment files, credential stores, private keys and configuration files that contain secrets. Manage secrets through dedicated secret management systems rather than files an assistant might read. When local development needs a secret, use a mechanism that provides it at runtime without storing it in a file the assistant can access.
Use sandboxed execution environments
When AI assistants execute code or run commands, those operations should happen in sandboxes that limit the blast radius of mistakes. Container-based development environments, virtual machines and cloud development workspaces keep an assistant's actions from affecting the host system, other projects or shared infrastructure. Sandbox infrastructure also improves reproducibility and developer confidence.
Review tool permissions and MCP integrations carefully
MCP integrations that connect AI assistants to internal services are a particularly sensitive attack surface. Review each integration for the access it grants, the operations it permits and the data it exposes. Integrations should follow least privilege, giving the assistant access to specific operations rather than broad API access. Remove unused integrations. Put new integrations through a security review before deployment.
Block dangerous commands
Configure AI assistants that have shell access with explicit blocklists for destructive commands. Block commands that modify system configuration, access network interfaces, install system-level packages or interact with container orchestration unless they are explicitly required and approved. Maintain the blocklist as a security control and review it regularly.
Treat repository configuration as security-sensitive
Treat project-level configuration files for AI assistants with the same care as CI/CD pipeline configuration. Changes to them should require security-aware review, and branch protection rules should prevent unauthorized changes. Establish a baseline configuration that encodes your security requirements, and detect deviations from it.
Integrate SAST, dependency scanning and secret scanning
Run Static Application Security Testing (SAST) tools on every pull request, with specific attention to the vulnerability patterns AI-generated code tends to introduce. Use dependency scanning to confirm that AI-suggested dependencies have no known vulnerabilities and are actively maintained. Use secret scanning to catch credentials or tokens that have slipped into code or configuration. Run these tools automatically in the CI/CD pipeline, and have critical findings block the merge.
Taken together, these controls form a short checklist for any team using AI coding assistants:
- Grant each assistant the minimum permissions its task needs.
- Keep assistants out of production environments, databases and credentials.
- Exclude secrets from the assistant's context and manage them in a secret management system.
- Run agent commands in containers, virtual machines or cloud workspaces.
- Review every MCP integration for the access, operations and data it exposes, and remove unused ones.
- Block destructive commands by default.
- Protect AI assistant configuration files with review and branch protection.
- Run SAST, dependency scanning and secret scanning on every pull request, and block merges on critical findings.
Governance Frameworks for AI Security
Technical controls are necessary but not sufficient. Organizations also need governance that sets policy, assigns responsibilities and creates accountability for the security of AI-assisted development. Several established frameworks provide relevant guidance.
ISO/IEC 42001, the international standard for AI management systems, provides a framework for managing the risks of AI systems throughout their lifecycle. For development teams using AI coding assistants, it gives guidance on risk assessment, control implementation, monitoring and continuous improvement. It is particularly relevant for organizations that must show customers, regulators or auditors that their use of AI is governed by systematic risk management.
The NIST AI Risk Management Framework (AI RMF) is a voluntary framework for managing AI-related risk, organized around four functions: govern, map, measure and manage. For development teams, it gives guidance on identifying the risks of AI coding assistants, measuring them through metrics and monitoring, and managing them through controls and processes. Its emphasis on organizational governance complements the technical controls above.
SOC 2 compliance, which many software organizations already maintain, needs to extend to AI-assisted development practices. The security, availability, processing integrity, confidentiality and privacy criteria SOC 2 evaluates all bear on how AI coding assistants are configured and used. Work with your auditors to make sure AI-assisted development is covered by your SOC 2 controls and that you keep evidence of compliance.
The governance dimension connects to the broader organizational patterns that shape how a company adopts AI. Security governance for AI-assisted development should not exist as an isolated program. Build it into your existing security governance structure, and treat AI-specific risks as an extension of the risk landscape you already manage rather than as a separate concern. Your AI development policy is the natural place to write these rules down.
Security as a Development Practice
The most effective approach treats security as part of development, not as a separate function that evaluates output after the fact. When security checks run inside the development workflow, alongside linting, testing and code review, they catch issues where they are introduced instead of after they have been merged and deployed to staging.
Developers using AI coding assistants should be trained to recognize the security weaknesses of AI-generated code. They should know the common vulnerability patterns, know how to evaluate generated code for security issues, and have tools that automatically detect known vulnerability categories. Security awareness belongs in the team's standard operating procedure for AI-assisted development, not in an optional extra.
Security teams should also take part in configuring and governing AI coding assistants rather than evaluating their output after deployment. Encode security requirements in the assistant's configuration, in the project's review checklists and in the pipeline's automated checks. Security designed into the workflow keeps pace with development instead of creating bottlenecks after the code is written.
The Azumo SDLC is built this way. It is a shared kit of workflows, skills, rules and review checklists, and the same setup loads in Claude Code, Qwen Code, OpenCode and Pi, so every engineer starts from the same configuration. Security is one of its separate review checklists, nothing passes review without evidence, and the agent stops for a person's approval before shipping. Teams add their own steps and checks without changing the shared kit. If you hire a custom software development company that builds with AI, ask how it scopes assistant permissions, where secrets live, and which security checks block a merge.
Roll this out in stages, the same way you would any organizational change. Start with awareness: a shared understanding across developers, reviewers and security staff of the risks AI coding assistants bring. Then put the basic controls in place: least privilege, secret protection and automated scanning. As experience grows, move toward full governance that brings AI security into your existing security program. The goal is not to slow AI-assisted development down. It is to make sure the speed it enables does not outpace your ability to keep your security posture intact.