AI Coding Assistant Security and Vibe Coding Risks

AI coding assistant security is the practice of controlling the risks that appear when AI tools suggest, write, or even run code for your developers. Vibe coding is the far end of that use: the person describes what they want, the AI produces the architecture and code, and the person judges the result instead of reviewing the code in depth, as the UK NCSC describes it. This article explains where the risks come from, what OWASP and NIST say, and which controls work in practice.

Assistants and vibe coding are a spectrum

The NCSC's June 2026 blog on the "vibe coding spectrum" treats this as a range, not a yes-or-no choice. At one end you write the code and use AI only for suggestions you can accept or ignore, such as autocomplete. At the other end the AI controls the architecture, modules, and tests, and you judge the output and re-prompt. In between, AI might write specific functions while you design, or write code to pass tests you wrote.

The NCSC's advice is to choose your position by what you are building. Lean toward full vibe coding for prototypes, demos, internal tools with limited exposure, and projects with no sensitive data or security functions. Lean toward manual control for authentication and authorisation logic, sensitive personal data, secrets, tokens and credentials, and safety-critical systems.

Where the risks come from

The OWASP Top 10 for LLM Applications 2025 is a useful map. For coding assistants, five of its ten entries matter most:

• Insecure or wrong code (LLM05, Improper Output Handling): OWASP says to treat model output as untrusted input. Its scenario on generated code warns of SQL injection, insecure data handling, and hallucinated packages. The NCSC wrote in 2026 that the risks of AI-written code are likely outside most organisations' tolerance today
• Invented packages: a USENIX Security 2025 study of 16 code-generating models and 576,000 code samples found average hallucinated-package rates of at least 5.2% for commercial models and 21.7% for open-source models, with 205,474 unique invented names. An attacker who registers such a name, an attack called slopsquatting, can get malicious code installed
• Over-powerful agents (LLM06, Excessive Agency): an agent that can run shell commands, edit files, and call tools can take damaging actions on ambiguous or manipulated output. OWASP names three root causes: excessive functionality, excessive permissions, and excessive autonomy
• Prompt injection (LLM01): text in an issue, README, web page, or file that the assistant reads can carry instructions. Claude Code's documentation defines it as an attacker inserting text to override the assistant's instructions, and GitHub's notes that its coding agent filters hidden characters that could conceal harmful instructions
• Data leakage (LLM02, Sensitive Information Disclosure): secrets, customer data, and proprietary code can be pasted into prompts or exposed through context. GitHub's documentation warns that generated code and text drawn from issue or comment context could expose sensitive information if not reviewed. See Shadow AI: risks and response

The tools are also part of your supply chain. LLM03, Supply Chain, covers tampered models, data, and deployment platforms, and the same thinking applies to plugins and MCP servers. See MCP security guide.

What OWASP and NIST actually say

OWASP's entries cover LLM applications in general, but their prevention lists translate directly. For excessive agency, LLM06 recommends the minimum set of tools, avoiding open-ended ones such as arbitrary shell commands, minimum permissions, human approval for high-impact actions, and authorization enforced in downstream systems instead of trusting the model. For LLM05, it recommends validating output and using parameterized queries, treating the model like any other user.

NIST SP 800-218A, published in July 2024, is the SSDF Community Profile for generative AI and dual-use foundation models. Read its scope carefully: it extends SSDF version 1.1 (SP 800-218) with practices for AI model development, for producers of AI models, producers of AI systems that use them, and acquirers of those systems. It is not a guide for developers who use coding assistants. It helps in two indirect ways. As an acquirer, you can ask assistant vendors how they apply secure development practices to their models. And you can apply the base SSDF to AI-written code as to any third-party code: review and test it before release. NIST also released an initial public draft of SSDF version 1.2 (SP 800-218 Rev. 1) in December 2025, so check NIST for its current status.

Controls that work

Vendor documentation shows the kinds of controls to look for. These are examples, not endorsements. GitHub's documentation for its Copilot coding agent says only users with write access can trigger it, it can push only to its own branch and not the default branch, workflows it triggers need approval, it cannot access organization secrets, and a firewall is on by default. Claude Code's documentation says its manual mode starts read-only and asks before editing files or running commands, offers a sandboxed bash tool with filesystem and network isolation, and states that you are responsible for reviewing proposed code and commands.

The common theme is to limit what the agent can touch, keep a human approval at the high-impact steps, and keep a record. In practice:

• Approved tools only: choose sanctioned assistants, configure them centrally, and keep company code out of personal accounts
• Least privilege: scoped credentials, no production secrets, and a sandbox or dev container with restricted network access
• Human approval for high-impact actions: deleting data, deploying, changing permissions, or running unfamiliar commands
• Branch protection and required review: AI changes go through a pull request like anyone else's
• Automated checks in CI: static analysis, secret scanning, and dependency checks run whoever wrote the code. The NCSC favors deterministic controls enforced by rules and code, not one AI policing another
• Package verification: confirm a suggested dependency exists and is the one you intend, and pin versions with a lockfile
• Logging: record what agents did

Setting a policy by risk tier

Turn the NCSC spectrum into a short policy developers can follow without asking each time.

• Low risk (prototypes, demos, internal tools with no sensitive data): allow high autonomy, but still use a sandbox, no production credentials, and automated scans
• Medium risk (production features, customer-facing work): AI may write code, but a human who understands it reviews every change and all automated checks must pass
• High risk (authentication, authorisation, personal data, secrets handling, safety-critical code): keep manual control and use AI only for suggestions or as an additional reviewer

Connect this to your wider AI policy; see AI security and governance guide. If your teams use agents that act on their own, also read Agentic AI security.

Common mistakes

• Treating AI output as reviewed code: it is untrusted input until someone understands and tests it
• Giving the agent your own full-access credentials: use scoped, separate access
• Letting AI be the only reviewer: AI review helps, but sensitive code also needs deterministic controls and human review
• Installing suggested packages unchecked: verify first, and use a lockfile
• Using vibe coding for high-stakes code: authentication and secrets handling belong at the manual end of the spectrum
• No inventory: you cannot govern assistants you do not know about

Start today

• List the assistants and agents in use, including personal accounts, browser tools, and plugins
• Write the three risk tiers and name who approves exceptions
• Turn on CI checks: secret scanning, dependency checks, static analysis, and required reviews on protected branches
• Move agents to a least-privilege environment: sandbox or dev container, scoped tokens, restricted network
• Pilot with one team and measure review time and findings before expanding

To see where your organization's AI and development controls stand, try the self-assessment.

Code written with AI help should pass the same automated checks as human-written code; see DevSecOps: How to Use SAST, DAST and SCA.

References and further reading

• OWASP Top 10 for LLM Applications 2025: the ten risk categories and their IDs
• OWASP LLM06:2025 Excessive Agency: root causes and prevention for agents
• OWASP LLM05:2025 Improper Output Handling: treating model output as untrusted, including generated code
• NIST SP 800-218A: SSDF Community Profile for generative AI: scope is AI model development, for producers and acquirers
• NCSC: the vibe coding spectrum approach: where to sit on the spectrum by risk
• NCSC: Vibe check, AI may replace SaaS (but not for a while): the NCSC's view of risks and safeguards for AI-written code
• We Have a Package for You! Package hallucinations by code-generating LLMs: the USENIX Security 2025 study behind the figures above
• GitHub Docs: Copilot coding agent responsible use: one vendor's documented risks and protections
• Claude Code documentation: Security: another vendor's permission model and sandboxing