The security conversation around AI code assistants has focused on the wrong problem. Most discussions center on whether the AI might generate vulnerable code, like SQL injection flaws or XSS vulnerabilities. That misses the bigger issue: these tools operate with your credentials, your filesystem access, and your cloud permissions. When an AI agent offers to “fix your deployment” or “update your database schema,” the security question is not whether it writes bad code. The question is whether you should let it execute anything at all.
Thoughtworks published their experience building applications with AI assistants in The VibeSec Reckoning, documenting a pattern that anyone using GitHub Copilot, Cursor, or Claude Code has likely encountered. The AI suggests a configuration change. You approve it. The change works, but it also disabled authentication, opened a port to the internet, or granted overly broad IAM permissions. The velocity feels incredible until you realize what you shipped.
The core problem is permission scope. Traditional development tools operate as passive assistants. Your text editor does not deploy to production. Your linter does not modify cloud resources. AI agents blur this boundary completely. They can read your entire codebase, execute shell commands, modify infrastructure as code, and interact with external APIs. The same assistant that helps you write a React component can also run terraform apply with your AWS credentials.
Consider a common scenario: you ask an AI to help set up a Redis cache for your application. A competent agent might generate Docker Compose configuration, update your application code to use the cache, and modify your environment variables. In the process, it might set Redis to bind to 0.0.0.0 instead of 127.0.0.1, disable password authentication for “simplicity,” and expose port 6379 to your public subnet. Each individual decision has a rationale. The composite result is a security incident waiting to happen.
The Thoughtworks team identified several patterns that emerge from this problem. AI agents default to permissive configurations because restrictive settings require more context. Setting up OAuth is harder than skipping authentication. Configuring TLS certificates takes more steps than plaintext HTTP. Network policies require understanding your infrastructure topology. The path of least resistance is almost always the insecure path, and AI assistants optimize for getting something working quickly.
Traditional code review catches some of these issues, but not all. Security problems in AI-generated code often hide in configuration files, environment variables, and infrastructure definitions scattered across multiple files. A reviewer might catch an exposed API endpoint in the application code but miss the security group rule that allows unrestricted inbound traffic. The attack surface is larger and more diffuse than traditional code changes.
The solution requires operating at the boundary layer, not the code layer. Thoughtworks recommends several specific interventions. First, create a security context file that the AI reads before making any suggestions. This file documents your security requirements: authentication mechanisms, network policies, encryption standards, approved services. Tools like Claude Code support CLAUDE.md files that provide project-specific context; use these to encode security constraints, not just coding preferences.
Second, implement permission boundaries at the tool level. Most AI coding assistants request broad permissions to read files, execute commands, and modify resources. Deny these requests by default. Grant only specific, scoped permissions after understanding what the AI intends to do. If an agent asks to run a deployment script, read the script first. If it requests access to your AWS CLI configuration, understand which resources it plans to modify.
Third, establish a security intelligence feed. This is less about vulnerability scanning and more about maintaining awareness of secure defaults for the technologies you use. When your team adopts a new database, framework, or cloud service, document the secure configuration baseline before anyone asks an AI to set it up. The AI will generate configuration based on patterns it has seen; you need to ensure those patterns reflect current security standards, not outdated tutorials from 2019.
Fourth, build secure-by-default templates and harnesses. If your team frequently deploys web services, create a template that includes authentication, TLS, rate limiting, and appropriate network policies. When an AI agent scaffolds a new service, it should start from this template, not from a minimal example. The same principle applies to database configurations, API integrations, and infrastructure modules. The default should be secure; additional permissions should require explicit justification.
These interventions shift the security boundary from code review to constraint specification. Instead of checking every AI suggestion for security problems, you define the acceptable space of configurations upfront. The AI operates within those constraints. This matches how we handle other automation: CI/CD pipelines run with restricted service accounts, infrastructure as code uses policy-as-code validation, API clients operate with scoped tokens.
The permission boundary problem extends beyond individual developers. Organizations adopting AI coding tools need to consider the aggregate risk. If fifty engineers use AI assistants with broad permissions, the probability that one of them approves a problematic change approaches certainty. The security posture depends not on the most cautious engineer but on the least cautious engineer at their most distracted moment.
Some of this will improve as the tools mature. Anthropic’s Claude 3.7 and OpenAI’s GPT-4.1 show better understanding of security contexts compared to earlier models. AI coding assistants are beginning to implement more granular permission models and security-focused linters. But the fundamental tension remains: these tools generate value by moving fast and reducing friction, while security requires slowing down and adding friction at critical points.
The long-term pattern might look like tiered automation. Low-risk changes—refactoring, documentation, test generation—run with minimal oversight. Medium-risk changes—new features, dependency updates, configuration modifications—run with human approval and security constraints. High-risk changes—production deployments, infrastructure modifications, permission grants—require explicit human execution, with AI assistance limited to suggesting and explaining.
The Thoughtworks article frames this as “VibeSec,” a play on “vibe coding,” the practice of building software through conversational interaction with AI rather than manual implementation. The term captures something real: security in AI-assisted development often comes down to vibes, to whether something feels right, rather than systematic verification. Moving from vibes to rigor requires treating AI agents as privileged actors in your system, not as enhanced text editors.
If you use AI coding tools in production contexts, audit your current setup. What permissions does your AI assistant have? Can it execute arbitrary shell commands? Can it modify cloud resources? Does it have access to production credentials? What constraints govern its suggestions? The answers might be uncomfortable. The upside is that the fixes are implementable today, using the patterns documented by teams who have already encountered these problems.
The permission boundary problem is not a reason to avoid AI coding tools. The productivity gains are substantial and the technology will continue improving. But the security model needs to catch up to the capability model. Until it does, the responsibility falls on development teams to implement the guardrails that keep fast-moving AI assistance from creating slow-moving security incidents.