Adoption is a settled question: 84% of developers use or plan to use AI tools, half of professionals use them daily, and a meaningful share of merged code is now AI-authored. We covered what that does to team workflows — faster drafts, review as the new bottleneck. This is the security companion: what can actually go wrong, and the controls that prevent it.
The four attack surfaces
1. The generated code. Independent analyses put AI-generated code at roughly 2.7× more vulnerabilities than human-written code, with almost half of tested samples failing security checks — while fewer than half of developers say they always review generated code before committing it. The failure mode is rarely dramatic; it is plausible-looking code with a subtle injection flaw or a hard-coded secret.
2. The dependency chain. Assistants hallucinate package names, and attackers register those names with malicious payloads — "slopsquatting". A generated import that resolves on the first try deserves the same suspicion as an unsolicited attachment.
3. The assistant itself. This is the 2026 development. The "DuneSlide" vulnerabilities demonstrated zero-click prompt-injection attacks escaping the Cursor editor's sandbox to execute arbitrary code, and researchers keep showing that agentic tools can be steered by content they merely read — a poisoned README, a malicious rules file, a compromised MCP server. An agent with shell access and repository write permissions is a privileged identity, and it is persuadable.
4. The data path. Prompts carry source code, credentials and customer data to someone else's infrastructure. Personal-tier tools often train on your inputs; business tiers usually do not. That difference is a one-line policy with outsized consequences.
The control checklist
Policy layer
- One sanctioned tool per team, on business accounts, with training on your code disabled.
- Bright lines: no secrets or customer data in prompts; generated code gets the same review as human code; whoever commits it owns it.
Pipeline layer
- Secret scanning, SAST and dependency verification on every pull request — no AI exceptions.
- New dependencies must be verified to exist, with provenance and download history checked; pin versions.
- Tag AI-authored changes so you can measure their defect and incident rates separately.
Assistant hardening
- Least privilege for agentic modes: no unattended shell access, scoped repository permissions, limited network egress.
- Treat configuration as code under review: rules files, prompt templates and MCP server definitions are executable instructions — a poisoned rules file is a supply-chain compromise.
- Patch assistants and IDE plugins like production software; sandbox escapes get fixed in updates that only help the instances that install them.
Human layer
- Review discipline calibrated to AI volume: reviewers verify behaviour, not plausibility.
- Train developers on prompt hygiene and output verification — OWASP's Top 10 for LLM applications, with prompt injection at number one, is a free and solid syllabus.
What to measure
Escaped defects and security findings on AI-tagged code versus your baseline; time-to-remediation for dependency alerts; the share of pull requests passing gates on the first attempt. If the assistant programme is working, quality holds while cycle time drops. If quality slides, you have automated the creation of technical debt.
Where Educatifu fits
We help engineering teams adopt AI tooling without inheriting its risks — usage policy, pipeline gates, agent permission design and security review of assistant configurations. If your team already ships AI-assisted code and the controls have not caught up, get in touch — that gap is very closable.