What happens to security when everybody can write code?

When anyone can produce working software with an AI assistant, the number of code authors rises faster than the number of people who know secure coding. Security then has to depend less on each author's expertise and more on defaults, automated checks and ownership rules that apply to everyone.

What changes when authorship widens?

Code used to be written by trained engineers working inside a review process. Now an analyst can ask an assistant for a script that reads a customer file and posts to an internal API, and run it that afternoon. The software works. Nobody reviewed it, nobody owns it, and it holds a credential pasted in by the author.

That is not a prediction about the future. It describes what is already possible, and the question is what control remains.

What stays the same?

The classes of weakness do not change. Injection, broken access control, hard-coded secrets and vulnerable dependencies appear in the OWASP Top 10 and CWE lists whether a person or a model wrote the line. Generated code can include them. It can also invent package names that do not exist, which attackers can register, a problem sometimes called package hallucination.

What changes is volume, and the distance between author and security knowledge.

What do the standards say?

CISA's Secure by Design material puts responsibility on the makers of technology to build safety in by default, instead of leaving it to each user to configure. That idea fits this situation well: if the platform makes the secure path the easy path, a new author does not need to know every rule.

NIST SP 800-218A extends the Secure Software Development Framework with practices for generative AI and dual-use foundation models, adding tasks specific to AI model development. It is aimed at those building models, but its framing holds for use: security belongs inside the development process, with defined practices and records, not added on at the end.

A constructed example

An operations team lets staff build small internal tools with an AI assistant. Without controls, each tool holds its own copy of an API key. With a guardrail design, tools get short-lived credentials from a central store, run in a sandbox with an allow list of outbound destinations, and cannot deploy until a scan passes for secrets and known vulnerable packages. The author never had to learn those rules. The platform applied them.

What should organizations build?

Secure defaults. Templates and runtimes that handle authentication, input validation and secret storage so authors do not hand-roll them.

Automated gates. Secret scanning, dependency checks and static analysis on every change, including small scripts.

Inventory and ownership. A list of what is running, who owns it, and when it was last reviewed. Software without an owner is a liability.

Limited blast radius. Scoped credentials, network allow lists and data access rules, so one flawed script cannot reach everything.

Review that scales. Reserve human review for high-risk changes, such as anything touching customer data or production systems.

Safeguard's policies and gates follow this pattern: set the rules once and apply them to every change, whoever or whatever wrote it.

How to check or apply this

1. Ask each team what AI coding tools are in use and who is using them.
2. Create a short written rule for what generated code must pass before it runs against company data.
3. Add secret and dependency scanning to every repository and to any shared script folder.
4. Provide a central way to get credentials, and ban pasted keys in code.
5. Require an owner and a review date for every internal tool.
6. Verify that any package an assistant suggests exists and is the intended one before installing it.
7. Review the rules after the first incident or near miss.

Quick check

Sources

• CISA, Secure by Design
• NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
• OWASP Top 10
• CWE Top 25 Most Dangerous Software Weaknesses

Last reviewed: 18 October 2026.