Prompt Injection Is a Solved Problem. Here's What Should Actually Worry You.

If you have been following AI security discourse, you would think prompt injection is the only threat worth worrying about. It is not. Prompt injection is a well-understood, largely mitigated attack vector with established defences. The real threats — the ones that are actually burning companies right now — are quieter, harder to detect, and much more damaging.

We analysed over 200 publicly disclosed AI security incidents from the past year. The pattern is clear: the industry is over-indexed on injection and under-indexed on the threats that actually cause damage.

Threat 1: Data leakage through context windows

This is not a theoretical risk. We have seen production prompts that routinely include customer email addresses, internal revenue numbers, and even API keys as "context" for the model. The prompt works fine — the security posture is catastrophic.

Threat 2: Supply chain risks

Your LLM application probably depends on a stack of libraries: API clients, prompt templating engines, output parsers, vector databases, embedding models. Each one is a supply chain dependency with its own security posture.

Treat your AI stack with the same security rigour as the rest of your application. Pin dependency versions. Audit new dependencies before adoption. Run vulnerability scans. Do not install a package just because a tutorial recommended it.

• Pin all AI library versions explicitly — no floating ranges
• Audit the permissions each library requires (network, filesystem, env vars)
• Use a lockfile and verify its integrity in CI
• Monitor for CVEs in AI-specific packages (many are too new for traditional scanners)

Threat 3: Compliance gaps

GDPR, SOC 2, HIPAA, and industry-specific regulations were not written with LLMs in mind. But they still apply. When you send personal data to an LLM API, you are processing that data with a third-party processor. When the model generates output based on that data, you are creating derived personal data. Most compliance frameworks have requirements for both.

Threat 4: Access control and prompt manipulation

Now we get to injection — but the real version, not the blog-post version. The actual risk is not that someone tricks your chatbot into saying something funny. It is that an attacker manipulates a prompt to exfiltrate data, bypass business logic, or escalate their access within your application.

Notice that "add a disclaimer to the system prompt" is not on the list. Disclaimers do not stop injection. Architectural controls do.

Building a secure AI stack

Security in AI applications is not fundamentally different from security in any other application. The principles are the same: minimise the attack surface, validate inputs and outputs, control access, log everything, and assume breach.

What is different is the maturity of the tooling. Traditional application security has decades of established patterns and tools. AI security is still early. This means you need to be more deliberate, more manual, and more vigilant than you would be with a mature stack.

At Enprompta, security is built into the platform layer. Our routing engine strips PII before it reaches the model. Our audit logs capture every prompt and response. Our access controls enforce per-user and per-team permissions on prompt libraries. But even without a dedicated platform, the principles in this article will get you to a defensible security posture.