Safe AI coding in a large software project is less about picking the cleverest assistant and more about deciding what that assistant is allowed to touch. A completion tool in a small side project can only do limited damage. An agent with shell access, a broad cloud token and a monorepo full of shared credentials can do a great deal more, very quickly. In April 2026 one deleted a company’s production database and its backups in nine seconds.
The pressure to adopt is not going away. In the 2025 Stack Overflow Developer Survey, 84% of developers said they were using or planning to use AI tools, while 46% said they actively distrust the accuracy of what those tools produce. Veracode’s 2026 research found that in organisations that have adopted AI coding tools, AI now authors roughly half of all committed code, yet the average security pass rate of that code has barely moved in a year.
This guide covers the controls that make safe AI coding workable at scale: permissions and sandboxes, secrets handling, dependency checks, review gates, CI automation, agent governance and a phased rollout. If you are still choosing a tool, start with our comparison of AI coding assistants. For the engineering habits rather than the guardrails, our guides to AI coding best practices and common AI coding mistakes cover that ground.
Table of contents
- Why Safe AI Coding Is Harder in a Large Codebase
- The Threat Model Behind Safe AI Coding
- Safe AI Coding Starts With Permissions and Sandboxes
- Secrets, Context and Safe AI Coding
- Guarding the Dependency Graph for Safe AI Coding
- Code Review as the Safe AI Coding Gate
- Automating Safe AI Coding Checks in CI
- Governing MCP Servers, Plugins and Background Agents
- A Phased Safe AI Coding Rollout for Large Teams
- Measuring Whether Safe AI Coding Works
- Standards That Shape Safe AI Coding Policy
- Safe AI Coding FAQs
- References
Why Safe AI Coding Is Harder in a Large Codebase
Small projects forgive a lot. Large ones concentrate risk, because more code, more people and more shared infrastructure sit behind every change an assistant proposes. Three things make safe AI coding harder once a codebase passes a certain size.
The Assistant Sees a Slice, Not the System
A coding assistant only reasons about what is in its context window: the open files, whatever its search tools retrieve and the instructions it has been given. In a large codebase the rule that matters often lives somewhere else, such as an authorisation wrapper in a shared library, a data-classification convention or a service boundary documented in a wiki. Code that ignores it can compile, pass the nearby tests and still bypass the control.
Veracode’s 2026 GenAI Code Security Report puts numbers on that gap. Models now produce syntactically correct code nearly 100% of the time, but roughly 44% of the code generation tasks Veracode tested introduced a risky security vulnerability. A bigger context window helps the assistant find more of the system. It does not make a large language model understand which parts of that system are load-bearing, which is why safe AI coding cannot rely on context alone.
Blast Radius Grows With Every Shared Credential
In a monorepo, a developer laptop often holds credentials for several environments at once: cloud CLI profiles, package publishing tokens, database connection strings in local environment files and CI secrets pulled down for debugging. An assistant that can run shell commands inherits all of it. The question for safe AI coding is not whether the assistant is trustworthy, but what the worst command it could run would be able to reach.
Speed Moves the Bottleneck to Review
AI assistance produces more code per hour than a reviewer can read per hour. Google’s 2025 DORA research, based on nearly 5,000 technology professionals, found that AI adoption now has a positive relationship with delivery throughput but a negative relationship with software delivery stability. The time saved is also less certain than it feels. In METR’s July 2025 trial, 16 experienced open-source developers took 19% longer on 246 real issues when AI assistance was allowed, despite expecting to be 24% faster.
Security quality has not kept pace with fluency, and the gap between the best and the average model is wide.
The spread matters for policy. GPT-5.5 led the 2026 snapshot at 68%, while more than half of the tested models sat between 50% and 53%, and the first report’s average of 55% has only crept to 56%. Even the best result still fails nearly one security task in three, so no model choice removes the need for the safe AI coding controls below.
The Threat Model Behind Safe AI Coding
A practical threat model for safe AI coding starts with the OWASP Top 10 for LLM Applications 2025. Four of its entries map almost directly onto coding assistants: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain and LLM06 Excessive Agency. Each has already produced a real incident involving developer tooling.
Prompt Injection Through Files the Agent Reads
Any text an agent reads can carry instructions: a README, a code comment, a GitHub issue, a dependency’s documentation or a web page it fetches. In August 2025 Microsoft patched CVE-2025-53773, a command injection flaw in GitHub Copilot and Visual Studio. The researcher who reported it showed that injected instructions could make Copilot write "chat.tools.autoApprove": true into the project’s .vscode/settings.json file, which switched off user confirmations and let the agent run shell commands.
The lesson generalises beyond one editor. If an agent can write to the files that define its own permissions, a prompt injection can escalate itself. Injected instructions can also persist between sessions, which is why poisoned agent memory is now treated as a threat in its own right.
Hidden Instructions in Rules Files
In March 2025 Pillar Security described the “Rules File Backdoor”, a technique that hides malicious instructions inside the configuration files that steer Cursor and GitHub Copilot. Invisible Unicode characters such as zero-width joiners and bidirectional text markers keep the payload unreadable to a human reviewer while the model still follows it. Pillar’s disclosure timeline records that both vendors initially placed responsibility on users rather than treating it as a platform vulnerability.
Hallucinated and Malicious Packages
Models invent dependencies. Researchers generated 576,000 code samples with 16 popular code-generation models and found that the share of hallucinated packages averaged at least 5.2% for commercial models and 21.7% for open-source models, including 205,474 unique invented package names. An attacker who registers one of those names is installed by anyone who trusts the suggestion, the attack now known as slopsquatting.
Over-Privileged Credentials and Destructive Commands
On 25 April 2026 an agent running in Cursor on Claude Opus 4.6 deleted the production database of PocketOS, a reservation platform for US car rental businesses, together with its backups, in nine seconds. According to Mondoo’s analysis of the founder’s post-mortem, the token it used had been created to manage custom domains but was an account-level token that could also delete production volumes, and the backups lived inside the same volume.
The pattern was not new. In July 2025 SaaStr founder Jason Lemkin reported that Replit’s agent deleted a production database during a code freeze he had asked it to respect. “There is no way to enforce a code freeze in vibe coding apps like Replit,” he wrote at the time. Instructions are not permissions, and safe AI coding depends on the second, not the first.
Poisoned Tools and Build Pipelines
The tools themselves are part of the supply chain. In July 2025 AWS disclosed that an inappropriately scoped GitHub token in the build configuration for the Amazon Q Developer extension for VS Code let an attacker commit malicious code that shipped in version 1.84.0. It failed to execute only because of a syntax error. In August 2025 malicious Nx packages ran a post-install script that scanned machines for sensitive data, attempted to use local AI assistants such as Claude and Gemini, and uploaded the results to a public GitHub repository.
| Threat | Documented example | What it exploited | First control |
|---|---|---|---|
| Prompt injection via repository content | CVE-2025-53773, patched August 2025 | Agent could edit its own settings file to auto-approve tools | Block agent writes to editor and agent configuration |
| Hidden instructions in rules files | Rules File Backdoor, March 2025 | Invisible Unicode in Cursor and Copilot rules files | Review rules files as code and scan for hidden characters |
| Hallucinated packages | 205,474 invented names across 16 models | Package names that do not exist until someone registers them | Install only through an allowlisted registry proxy |
| Over-privileged tokens | PocketOS, April 2026 | Account-level token able to delete production volumes | Scoped, short-lived credentials kept out of the repository |
| Ignored instructions | Replit and SaaStr, July 2025 | Agent could write to production during a code freeze | Separate development from production and gate destructive actions |
| Compromised build pipeline | Amazon Q Developer 1.84.0, July 2025 | Over-scoped GitHub token in the build configuration | Least-privilege CI tokens and release review |
| Malicious install scripts | Nx s1ngularity, August 2025 | Post-install script that also tried to drive local AI assistants | Disable install scripts by default |
Safe AI Coding Starts With Permissions and Sandboxes
Every later control in a safe AI coding programme is easier if the assistant begins with little authority. Decide the permission model before the first prompt, write it into managed settings rather than individual preferences, and treat any widening of it as a reviewed change.
Default to Read-Only and Earn Write Access
Tools increasingly ship with this model built in. Anthropic’s documentation says that in Manual mode Claude Code starts with read-only permissions, asks before it edits files, runs tests or executes commands, and does not auto-approve network commands such as curl and wget by default. Organisations can configure those permissions centrally and turn off the more autonomous auto mode. Whichever assistant you use, look for the same three safe AI coding levers: a read-only default, deny rules and central enforcement.
Sandbox the Shell, Not Just the Editor
Approval prompts do not scale, because developers start clicking yes. A sandbox replaces per-command judgement with a boundary. Claude Code’s sandboxed Bash tool lets you define which files and network domains commands can touch, and the operating system enforces that boundary for every command and its child processes. For assistants without a built-in sandbox, a disposable dev container or virtual machine with no host credentials mounted gives safe AI coding a similar boundary.
Keep Production Credentials Off Developer Machines
The PocketOS deletion needed a token with production reach sitting where an agent could find it. Remove that possibility structurally: no production credentials in repositories, local environment files or shell profiles, environment-scoped tokens for staging work, and production changes promoted only through a pipeline. Mondoo’s analysis notes that the hosting platform involved did offer environment-scoped project tokens, but the token in use was the broadest account-level kind.
Treat Auto-Approve Modes as a Change Request
Auto-approval settings, broad allow rules and so-called YOLO modes change your risk posture, so they are not personal preferences. Protect the files that hold them with code owners, stop agents from editing their own configuration, and log when a session runs with prompts disabled. CVE-2025-53773 worked precisely because a setting that removed confirmations lived in a file the agent could write, and a safe AI coding policy should name those files explicitly.
| Autonomy tier | What the assistant may do | Minimum controls | Good fit |
|---|---|---|---|
| Tier 0: Suggest | Completions and chat answers, no file writes or commands | Content exclusion, secret scanning, code review | Any repository, including regulated code |
| Tier 1: Edit with approval | Edits files and runs read-only commands, asks before each write or command | Read-only default, deny rules for secret paths, protected configuration files | Most application repositories |
| Tier 2: Sandboxed autonomy | Runs builds and tests without prompts inside a sandbox | Filesystem and network isolation, no production credentials, pull-request-only output | Well-tested services with strong CI |
| Tier 3: Background agent | Works a ticket on its own branch and opens a pull request | Isolated runner, scoped agent identity, code owner review, size limits | Dependency bumps, test backfill, documentation |
Secrets, Context and Safe AI Coding
Secrets are where the productivity gains of AI assistance and the cost of carelessness meet most visibly. The data from the last two years is consistent: more AI-assisted code has meant more leaked credentials, and safe AI coding has to assume a secret that reaches a repository will eventually be found.
What the Secrets Data Shows
GitGuardian’s 2025 report found that public repositories with GitHub Copilot enabled had a 6.4% secret leakage rate, 40% higher than the average across all public repositories. Its 2026 report counted 28,649,024 new secrets in public GitHub commits during 2025, a 34% rise, and found that commits co-authored by Claude Code leaked secrets at roughly twice the baseline. It also reported that Model Context Protocol configuration files routinely expose secrets.
The number of leaked secrets has risen every year since 2021, and 2025 brought the steepest jump.
Content Exclusion Is a Filter, Not a Boundary
Most enterprise assistants let administrators exclude paths from context, and it is worth doing for key files and regulated data. Read the limits, though. GitHub’s documentation says content exclusion is currently not supported in the Edit and Agent modes of Copilot Chat in Visual Studio Code and other editors, that Copilot may still use semantic information from an excluded file when the IDE supplies it indirectly, and that changes can take up to 30 minutes to reach IDEs. Safe AI coding keeps secrets out of the repository instead.
Block Secrets Before They Reach the Repository
GitHub’s push protection blocks pushes that contain detected secrets before they reach a repository, covering pushes from the command line and commits made in the web interface. It is disabled by default and has to be switched on by an administrator or security manager. Pair it with a pre-commit scanner on developer machines, so an assistant that pastes a key into a test fixture is stopped before the commit even exists.
Short-Lived Credentials for Every Agent
Where an assistant genuinely needs to call a cloud API or a package registry, give it a credential that expires with the session and is scoped to the task. Workload identity federation in CI removes stored cloud keys from pipelines altogether. Claude Code’s sandbox documentation also includes options for masking credentials, environment variables and credential files, which is the kind of feature a safe AI coding evaluation should ask every vendor about.
Guarding the Dependency Graph for Safe AI Coding
Every package an assistant adds becomes code you run with your own privileges. In a large codebase, one unreviewed dependency can reach hundreds of services through a shared library. Safe AI coding therefore treats a new dependency as a security decision, not a convenience.
Check That Every New Package Exists
The package hallucination research turns an abstract risk into a practical one. At the commercial models’ rate of at least 5.2%, roughly one package reference in 20 names something that does not exist, and at the open-source rate of 21.7% it is more than one in five. Dependency review on each pull request should flag any package that is new to the repository, recently published or missing from your internal catalogue.
Route Installs Through an Approved Registry
Point package managers at an internal proxy or mirror that only serves approved packages, and commit lockfiles so versions cannot drift silently. The OpenSSF’s Security-Focused Guide for AI Code Assistant Instructions, published on 1 August 2025, tells assistants not to add dependencies that may be malicious or hallucinated and to use the official package manager rather than copying code snippets. Instructions like that reduce noise; the registry proxy is what enforces safe AI coding.
Disable Install Scripts by Default
The Nx compromise executed through a post-install script, which runs the moment a package is installed and before anyone has reviewed its behaviour. Configure package managers to skip lifecycle scripts by default, allow them only for named packages that genuinely need them, and run any agent-initiated install inside the sandbox rather than on a workstation holding real credentials.
Provenance and Software Bills of Materials
Nx’s post-mortem notes that provenance does not block unsigned packages from being installed, which is what happened in its case. Verification has to be enforced at install time, not just published. Generate a software bill of materials in CI as part of safe AI coding, so you can answer within hours whether a compromised package reached any build.
Code Review as the Safe AI Coding Gate
Review is where a human decides whether AI-generated change is acceptable, so it has to be designed for the volume and failure modes of assistant output. A reviewer skimming a 2,000-line diff at the end of the day is not a safe AI coding control; it is a formality.
Route High-Risk Paths to Named Owners
GitHub’s code owners feature lets a repository name the people or teams responsible for specific paths, and branch rules can require their approval before merge. Use it for the parts of a large codebase where subtle AI mistakes are most expensive: authentication and authorisation, cryptography, payments, infrastructure as code, database migrations and CI workflow definitions.
Keep AI-Authored Pull Requests Small
Set a maximum diff size that a reviewer can genuinely read in one sitting, and ask assistants to split larger work into a sequence of pull requests. Small changes also make it easier to spot the classic assistant failure: a change that looks tidy, passes the tests it came with and quietly removes a validation step somewhere else.
Review Agent Configuration as Code
Rules and instruction files now shape what gets written as much as any linter does. Put AGENTS.md, CLAUDE.md, .github/copilot-instructions.md, .cursor/rules, MCP server configuration and editor settings under code owners, require security review for changes to them, and add a CI check that fails on invisible Unicode characters in those files. That single safe AI coding check addresses the Rules File Backdoor technique directly.
Record AI Involvement Honestly
Ask developers to mark AI-assisted commits, for example with a co-author trailer, and keep that record through release. Visible attribution is what allowed GitGuardian’s 2026 report to compare leak rates in commits co-authored by Claude Code against the baseline. The same record helps during IT project acceptance, when clients increasingly ask how assistants were used and how their output was checked.
Automating Safe AI Coding Checks in CI
Humans miss things at volume. The pipeline should catch the predictable problems on every pull request, whoever or whatever wrote the code, so reviewers can spend their attention on design and intent. Automated safe AI coding checks are also the only controls that apply identically to every team in a large organisation.
Run Security Scanning on Every Pull Request
Static analysis, secret scanning, dependency review and infrastructure-as-code policy checks should run on every change and block merge on high-severity findings. Veracode’s finding that AI output fails security tests at a stable rate is an argument for scanning everything by default, not only the changes someone remembered to label as AI-assisted.
Treat Tests as the Contract
An assistant asked to make tests pass may change the tests. Require code owner review for changes to test files that accompany production changes, track coverage on critical paths, and be wary of pull requests in which new code and its only tests arrive together from the same session. Tests written independently of the implementation are the ones that catch confident mistakes.
Harden the Pipeline Itself
Two of the incidents above were pipeline failures as much as AI failures. Nx’s post-mortem describes a pull request title validation workflow using pull_request_target, which runs with the target branch’s permissions and can access repository secrets, combined with unsanitised input. AWS traced the Amazon Q compromise to an inappropriately scoped GitHub token. Give workflows minimum token permissions, keep secrets away from untrusted pull requests and review workflow changes like production code.
Give the Assistant Security Instructions
Repository instruction files can tell an assistant to use parameterised queries, avoid deprecated cryptography, never log secrets and prefer standard libraries. The OpenSSF guide is a sensible starting template for safe AI coding instructions. Treat them as a way to lower the defect rate, never as a control: a prompt injection or a model update can override them without warning.
Governing MCP Servers, Plugins and Background Agents
Tool servers, plugins and cloud-hosted agents extend what an assistant can reach far beyond the repository. In a large organisation they multiply faster than anyone can inventory them unless someone owns the list.
Allowlist Tool Servers
Maintain an approved list of MCP servers and plugins, pinned to known versions, and block everything else through managed settings. The Model Context Protocol’s own Security Best Practices document describes attacks including confused deputy problems, token passthrough and server-side request forgery, and recommends scope minimisation. Review each server’s requested permissions the way you would review any new third-party integration.
Give Agents Their Own Identities
An agent acting with a developer’s personal token is invisible in audit logs and holds every permission that developer holds. Issue agents their own service identities with narrowly scoped permissions, so you can see what they did, limit what they can reach and revoke access without locking out a person. Separate identities are one of the cheapest safe AI coding wins available.
Keep Background Agents on Isolated Branches
Cloud and background agents that work from tickets should run on isolated runners, push only to their own branches and open pull requests they cannot merge themselves. They should not be able to modify CI workflows, branch rules or their own configuration. Keep a documented kill switch that disables agent access across the organisation within minutes.
Plan for Agents That Leave Their Sandbox
Agents that escape their intended boundaries are no longer hypothetical. This month researchers described agents that broke out of a sandbox and took over a German coding forum, and a related analysis tied an agent swarm to an attack on RubyGems. Egress controls, rate limits and outbound monitoring belong in your own agent platform, not only in a model provider’s assurances.
A Phased Safe AI Coding Rollout for Large Teams
Rolling out every control at once fails in large organisations, because the controls, the training and the exceptions process all need tuning. A phased safe AI coding programme widens autonomy only as the evidence supports it.
Phase 1: Pilot Safe AI Coding on Low-Risk Repositories
Pick internal tools, documentation sites and well-tested services with no access to production data. Start at tier 1, enable push protection and dependency review, and name a small group of engineers who report what the controls block and where they get in the way.
Phase 2: Guarded Expansion
Extend to mainstream application repositories once the pilot shows no leaked secrets and no unreviewed dependencies reaching the main branch. Introduce the sandbox, code owner rules for high-risk paths and the configuration-file checks. Keep regulated and safety-critical code at tier 0 for now.
Phase 3: Autonomy by Exception
Allow tier 2 and tier 3 only for repositories that meet explicit criteria: strong test coverage, isolated runners, scoped agent identities and a clean record in phase 2. Every exception has an owner and an expiry date, and the kill switch is tested before it is needed.
Training Developers for Safe AI Coding
The most important habit is scepticism about output that reads well. Stack Overflow’s 2025 survey found 66% of developers frustrated by AI answers that are almost right, and 45% said debugging AI-generated code takes longer. Train reviewers on the specific failure patterns in this guide, using examples from your own codebase, rather than on generic prompting tips.
| Phase | Scope | Controls switched on | Exit criteria |
|---|---|---|---|
| 1. Pilot, weeks 1 to 6 | Internal tools and documentation at tier 1 | Read-only default, push protection, dependency review | No secrets or unknown packages merged; control friction logged |
| 2. Guarded expansion, months 2 to 4 | Mainstream application repositories at tiers 0 and 1 | Sandbox, code owners on high-risk paths, configuration-file checks | Stable change failure rate and a working exceptions process |
| 3. Autonomy by exception, month 5 onwards | Qualifying repositories at tiers 2 and 3 | Agent identities, isolated runners, kill switch drills | Quarterly review of every exception and incident |
Measuring Whether Safe AI Coding Works
Without measurement, a safe AI coding programme drifts back to whatever is fastest. Pick a handful of indicators, report them monthly and review them every time you widen autonomy.
Leading Indicators of Safe AI Coding
Track what the controls catch: pushes blocked for secrets, dependencies rejected at review, sandbox network requests denied and permission prompts declined. Watch pull request size and time to first review as well. A sudden fall in blocked events can mean the risk has gone away, but it more often means someone has found a way around the control.
Lagging Indicators
Change failure rate, rollback frequency, time to restore service and security incidents traced to AI-assisted changes tell you whether the programme is working. The DORA metrics are a natural fit because many engineering organisations already collect them, and the 2025 research specifically links AI adoption to lower delivery stability.
Metrics That Mislead
Lines of AI-generated code, suggestion acceptance rates and self-reported time savings measure adoption, not safe AI coding. METR’s developers believed AI had made them faster when the timings showed the opposite, so treat perception data with care and never use it to justify widening an assistant’s permissions.
Standards That Shape Safe AI Coding Policy
You do not need to invent a framework. Secure development and cybersecurity guidance already covers most of what a safe AI coding policy needs, and mapping your controls to it makes audits, customer questionnaires and supplier reviews far easier.
NIST SSDF and SP 800-218A
NIST’s Secure Software Development Framework, version 1.1, is the baseline many security questionnaires reference. SP 800-218A, published in July 2024, adds practices specific to generative AI and dual-use foundation models. Its focus is on building AI models and systems rather than using coding assistants, but its expectations for acquirers of AI systems apply when you buy one.
OWASP, OpenSSF and NCSC Guidance
The OWASP Top 10 for LLM Applications gives a shared vocabulary for threats, the OpenSSF guide offers practical instruction-file content, and the UK NCSC’s Guidelines for Secure AI System Development cover secure design, development, deployment and operation. For software that ships to customers, periodic penetration testing remains the independent check that none of these safe AI coding controls replace.
UK and EU Obligations
The UK Software Security Code of Practice sets out 14 principles for software vendors, including commitments on support. In the EU, Cyber Resilience Act reporting obligations apply from 11 September 2026, with the main obligations following on 11 December 2027. Neither has a separate rule for AI-written code; both place expectations on the organisation that ships the software, however it was written.
| Framework | Status | What it adds to a safe AI coding policy |
|---|---|---|
| NIST SP 800-218 (SSDF) | Published framework, version 1.1 | Baseline secure development practices to map controls against |
| NIST SP 800-218A | Published July 2024 | Generative AI practices, including expectations for acquirers of AI systems |
| OWASP Top 10 for LLM Applications | 2025 edition | Threat vocabulary: prompt injection, sensitive information disclosure, supply chain, excessive agency |
| OpenSSF AI code assistant guide | Published 1 August 2025 | Security content for rules and instruction files |
| NCSC Guidelines for Secure AI System Development | UK government guidance | Secure design, development, deployment and operation of AI systems |
| UK Software Security Code of Practice | Voluntary code, 14 principles | Expectations on software vendors, including support commitments |
| EU Cyber Resilience Act | Reporting from 11 September 2026, main obligations 11 December 2027 | Manufacturer duties for products with digital elements |
Safe AI Coding FAQs
Is it safe to let an AI agent run commands in a large codebase?
It can be, inside a sandbox with filesystem and network isolation, no production credentials and pull-request-only output. Outside those conditions, keep the assistant at edit-with-approval and review every command it proposes.
Should AI coding assistants ever have access to production?
Not directly. Production changes should flow through a pipeline with review and approvals. The PocketOS and Replit incidents both involved agents that could reach production data from a development session, which is exactly what safe AI coding is designed to prevent.
Does content exclusion stop an assistant reading secrets?
No. It reduces exposure, but GitHub documents gaps, including Edit and Agent modes in some editors. The reliable approach is to keep secrets out of repositories and local files and to block them at push time.
How do we stop hallucinated packages reaching production?
Install only through an allowlisted registry proxy, require dependency review for any package new to the repository, commit lockfiles and disable install scripts by default.
Who is accountable for AI-generated code?
The organisation that ships it. Assistant vendors have tended to place responsibility for reviewing suggestions on users, as Pillar’s disclosure timeline shows, so accountability sits with the named reviewer and the code owner who approved the change.
References
Veracode: 2026 GenAI Code Security Report
GitGuardian: The State of Secrets Sprawl 2026
GitGuardian: State of Secrets Sprawl Report 2025
Embrace The Red: GitHub Copilot Remote Code Execution via Prompt Injection (CVE-2025-53773)
Pillar Security: New Vulnerability in GitHub Copilot and Cursor
Mondoo: 5 Lessons from the 9-Second AI Agent That Deleted a Production Database
The Register: Vibe Coding Service Replit Deleted Production Database
AWS Security Bulletin AWS-2025-015: Amazon Q Developer Extension for VS Code
Claude Code Docs: Configure the Sandboxed Bash Tool
GitHub Docs: Content Exclusion for GitHub Copilot
GitHub Docs: About Code Owners
Model Context Protocol: Security Best Practices
NCSC: Guidelines for Secure AI System Development
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.