Soveryne company logoSoveryne
All articles
AICybersecurityArchitecture

Securing AI the Way Attackers Break It

Prompt injection is the number-one security risk in AI applications, and here's the uncomfortable part: it probably can't be fully fixed. So the job isn't to "solve" it. It's to build so that when it happens, almost nothing bad can follow.

Ilke Tosunoğlu
Ilke TosunoğluJune 4, 20267 min readUpdated July 20, 2026
An AI model core surrounded by concentric defensive rings (sanitize, fence untrusted data, least privilege, output filter, verifier, monitor) with a red "untrusted content / potential injection" stream breaking apart against the outer layers.

Part of the pillar series Sovereign AI, Explained.

If you're deploying an AI assistant, the most important security fact to internalise is this one, from the UK's National Cyber Security Centre: "Under the hood of an LLM, there's no distinction made between 'data' or 'instructions'; there is only ever 'next token.'" (NCSC, 2025) A language model reads the trusted system prompt and the untrusted document you fed it through the same channel, with no built-in boundary between them. That is why an instruction hidden in a webpage, an email, or an uploaded file can hijack the model, and why the industry's own standards body says there may be no fool-proof fix.

This is the companion to our piece on the cyber paradox. There we argued sovereign security has to reach the substrate. Here we go a layer deeper, into the newest and least-understood attack surface, and how to build against it the way an attacker would test it.

Prompt injection is OWASP's #1 LLM risk

The OWASP Top 10 for LLM Applications (2025) ranks the risks, and Prompt Injection sits at number one (LLM01) (OWASP).

Rank OWASP LLM risk (2025)
LLM01 Prompt Injection
LLM02 Sensitive Information Disclosure
LLM05 Improper Output Handling
LLM06 Excessive Agency
LLM07 System Prompt Leakage
LLM08 Vector and Embedding Weaknesses

There are two flavours. Direct injection is when a user's own input subverts the model. Indirect injection, the dangerous one for any system that reads external content, is when malicious instructions are smuggled in via a retrieved document, a web page, or an email the model processes. OWASP is blunt about the ceiling: "Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection."

Why it's structurally hard (and different from SQL injection)

It's tempting to assume this is like SQL injection: a solved problem, if you parameterise your queries. It isn't. As NCSC explains, SQL injection can be fully mitigated because you can separate code from data; prompt injection likely can't, because the model has no such separation. The best you can do is "reducing the likelihood or impact of attacks." NCSC's design conclusion is worth quoting to any team shipping an agent: "If the system's security cannot tolerate the remaining risk, it may not be a good use case for LLMs."

The most useful mental model for the impact side is Simon Willison's "lethal trifecta": an AI agent becomes dangerous when it simultaneously has (1) access to private data, (2) exposure to untrusted content, and (3) the ability to communicate externally (Willison, 2025). Any two are survivable. All three together let attacker-controlled text read your secrets and ship them out, with no exploit code required.

The "lethal trifecta" as three overlapping circles (private data, untrusted content, and external comms) meeting at an "exfiltration risk" centre, above a defence-in-depth row: access control, tool restrictions, grounding guardrails, approval gates, output inspection, monitoring. Caption: you can't "solve" prompt injection; you can shrink its blast radius.

This isn't hypothetical. In 2025, researchers disclosed a zero-click prompt-injection exploit against a major AI assistant (CVE-2025-32711, CVSS 9.3): a booby-trapped email, retrieved later by the assistant, silently exfiltrated data with no user action (The Hacker News). A separate class of attacks hides instructions in code-repository comments to steal secrets. The recurring exfiltration channel across nearly all of them is the same: coaxing the model to render a remote image or link whose URL carries the stolen data.

Defence in depth: shrink the blast radius

Since you can't eliminate the vulnerability, you engineer so that a successful injection can't accomplish much. The techniques that actually work are layered and mostly deterministic, not "ask the model nicely."

Layer What it does Source
Fence untrusted content Mark all external data so the model treats it as data, not instructions ("spotlighting"/data-marking) Microsoft
Instruction hierarchy Train/route so system instructions outrank injected ones OpenAI
Least privilege Give the model minimal tool access; handle privileged actions in code OWASP
Break the exfil path Block auto-rendered remote images/links; allow-list egress OWASP / NCSC
Output filtering + grounding Check responses are grounded in trusted context before acting/rendering OWASP (RAG triad)
Human-in-the-loop Require approval for high-risk actions OWASP
Monitor everything Log inputs, outputs, and tool calls; alert on anomalies NCSC

Two honesty caveats, because this field is full of overclaims. Content-marking "raises the bar significantly… but does not hold up against determined adaptive adversaries" (Microsoft). And even strong architectural defences that isolate a "quarantined" model from tools neutralise most, not all, attacks; one leading design blocks ~67% on a standard benchmark (Google DeepMind/ETH). Anyone selling you a product that "stops prompt injection" doesn't understand the problem. The goal is defence in depth, not a silver bullet.

How we harden AI in the Soveryne Cloud Foundation

Because Soveryne is built by offensive specialists, we treat the model as a component an attacker will try to turn against you, and we build the layers accordingly, on the Soveryne Cloud Foundation.

Untrusted content is sanitised and fenced before it ever reaches the model: hidden control characters and disguised role markers are stripped, and any external data is wrapped so the model can't mistake it for an instruction. The assistant runs under least privilege, with high-risk actions handled in code rather than delegated to the model. Every answer passes a deterministic post-generation verifier that checks it is actually grounded in the trusted sources. Off-topic or unsupported output is caught, not rendered. The classic exfiltration channels are closed by a strict content-security policy and egress controls, so a coaxed remote-image beacon has nowhere to call home. And every interaction is logged to a tamper-evident trail for review.

This is also why our AI assistant, Counsel, answers only from your own frameworks and documents and cites every source: grounding isn't just a trust feature, it's a security control; it makes ungrounded, injected instructions visibly out of place. All of it runs on EU-sovereign infrastructure, so hardening the AI and keeping it in jurisdiction are the same piece of work.

FAQ

What is prompt injection? An attack where text (from a user, or hidden in a document, web page, or email the model reads) subverts an AI system's behaviour, because the model can't reliably tell instructions from data. It's OWASP's #1 LLM risk.

Can prompt injection be fully prevented? Almost certainly not, according to OWASP and the UK's NCSC: unlike SQL injection, there's no clean separation of code and data in an LLM. The realistic goal is defence in depth that shrinks the impact of a successful injection.

What is the "lethal trifecta"? Simon Willison's model: an AI agent is dangerous when it combines access to private data, exposure to untrusted content, and the ability to send data externally. Removing any one of the three contains the risk.

How do you stop AI data exfiltration? Break the outbound channel: block auto-rendered remote images and links, allow-list egress, apply least privilege and human approval for risky actions, and verify that outputs are grounded before acting on them.

You can't "solve" prompt injection, but you can build so it barely matters. See how the Soveryne Cloud Foundation hardens AI end to end: explore the platform and Counsel, or read the companion piece on the cyber paradox.

Sources

A prompt plus retrieved context flowing into a model, then splitting two ways: one path to a foreign GPU / inference environment (out of jurisdiction, data leaves your control), the other to an EU-region inference environment (data stays within your jurisdiction). Below, a source text is turned into an embedding vector and then reconstructed back into readable text, showing embeddings still reveal source information.
Next in the series
The Prompt Is the Data

Everyone accepts that you shouldn't store customer data in a foreign jurisdiction. Almost no one applies the same rule to the prompts they send an AI model, even though the prompt, and the context retrieved to answer it, often is the customer data. Sovereign AI that ships your prompts to a foreign GPU isn't sovereign. It's a data transfer with better marketing.

Read the next part
A glowing EU shield of EDR, MDR and SOC capabilities standing on cracked ground whose foundations are labelled US cloud, identity backplane, and telemetry. The shield is only as sovereign as the dependent ground beneath it.
Companion piece
The Cyber Paradox: Sovereign Security on Dependent Ground

Europe has built genuinely good cyber defenders. The problem is where they stand.

Read the companion piece

More articles

A map of Europe's dependence on US technology: cloud, software, AI and chips, alongside the leverage points Europe still holds in lithography and telecom.
SovereigntyCloud

Europe's Digital Dependence, Explained

This is the stakes, in one place. How deep does Europe's reliance on US technology run, why does concentration turn ordinary tools into systemic risk, and why is passing an audit not the same as being sovereign? This cornerstone ties the argument together and links to the detail behind each claim.

July 20, 20264 min read
A dial set between "open / dependent" and "sovereign / isolated", marked at a pragmatic middle labelled selective autonomy: control where it matters, open everywhere else.
SovereigntyGovernance

Sovereignty You Can Actually Operate

This is the method. Once you accept that dependence is real and compliance alone won't fix it, the question becomes operational: what do you actually control, how do you prove it, and how do you leave if you have to? This cornerstone turns the point of view into a how-to and links to the article behind each move.

July 20, 20264 min read
A prompt and its retrieved context flowing into a model, splitting one path to a foreign GPU outside the jurisdiction, the other to in-region EU inference that keeps the data home.
AISovereignty

Sovereign AI, Explained

This is our whitespace. Cloud dependence is a known story; AI is repeating it one layer up, faster and deeper. This cornerstone explains why "sovereign AI" is a real category and not a marketing label, and links to the article behind each claim.

July 20, 20263 min read