What is actually new in AI security

Much of what is sold as AI security is ordinary security with a new label.

One part is genuinely new, and it looks like one of the oldest bugs on the web. The rest is access control, least privilege, logging and data governance. Poisoned training data is a supplier problem; shadow AI is an inventory problem.

SQL injection slips instructions into a field meant for data, and the database runs them. The structural fix is parameterized queries, which send code and data separately so a bound value is never read as a command. In March 2024, CISA and the FBI were still urging software makers to use them, after SQL injection in a file transfer product affected thousands of organizations. The alert noted the flaw had been called “unforgivable” since at least 2007.¹

It is a vulnerability whose fix is older than some of the engineers still shipping it.

Prompt injection makes the same move against a language model. Someone emails your support inbox; hidden in white text is a line telling the assistant to reply with the last fifty customers’ phone numbers. If your AI tool can read that email and send replies, it might. OWASP ranks it first among risks to language-model applications and says “it is unclear if there are fool-proof methods of prevention.”²

The resemblance is where the UK’s National Cyber Security Centre starts. Its December 2025 post, “Prompt injection is not SQL injection (it may be worse),” explains why: inside the model, “there’s no distinction made between 'data’ or 'instructions’; there is only ever 'next token’.” It judges it “very possible” that prompt injection attacks “may never be totally mitigated in the way that SQL injection attacks can be.”³

That is the new part: an old attack with no old fix. Nothing yet does for a language model what parameterized queries do for a database.

So the defense returns to fundamentals, built around the model. Assume it can be talked into anything and limit what it can reach. Give it its own narrowly scoped identity, never broader than the person it acts for. Require a person’s approval before anything irreversible or anything that sends data out, and keep those approvals rare enough to be read. OWASP recommends least privilege and human approval for high-risk actions;² NCSC adds deterministic limits on what the system can do, and monitoring.³ EC-Council’s Adopt-Defend-Govern framework, released in May 2026, lands in the same place: a register of the tools an agent may call, a tier in which “a human approves every output before it takes effect,” and monitoring for “data leakage.”⁴ None of those are AI controls. They are controls.

That is the test for any AI security pitch. If it teaches access control, approvals and logging, it is your existing program under a new label. If it promises the model itself can be made immune to injection, it is claiming more than OWASP or NCSC will. ISO/IEC 42001, the AI management-system standard, stays on the honest side of that line: ISO describes what it specifies as “policies and objectives, as well as processes to achieve those objectives.”⁵

If a customer questionnaire asks whether your AI is immune to prompt injection, the accurate answer is no, followed by what it can reach and who approves what it sends.

Before the next AI deployment, ask two questions. If this model obeyed the worst instruction hidden in the next document it reads, what could it do? And if the answer is “anything its service account can,” who decided it needed that much?