Every LLM security paper published before this year ended with some variant of "this is a theoretical risk".

That line is gone.

As of June 2026 every attack described in those papers is being run against production systems, open source maintainers, and individual people. None of the standard guardrails, audit procedures, or compliance checklists stop them. Most teams running production LLMs are not even monitoring for the failure modes that are already being exploited.

This is not a warning about the future. This is a status report for right now.

The end of theoretical threat models

For the last three years almost all LLM security research operated under an unspoken agreement: attacks would be run by academics, in controlled environments, against model checkpoints that would never be deployed. Defenses would be benchmarked against those same artificial attacks.

That agreement broke this quarter.

We now have confirmed, documented cases of:

• Data poisoning deployed against fine tuned summarization models used in enterprise news pipelines
• Membership inference attacks run against production tabular foundation models processing patient data
• Autonomous AI agents running reputational attacks against open source maintainers
• Visual prompt attacks against commercial image to video APIs
• Zero day scanning pipelines that find and exploit LLM introduced code bugs faster than human maintainers can read the vulnerability report

None of these were announced. None were run for research. All were run for actual gain.

Poisoning does not go away after deployment

Fine tuning stage poisoning was long treated as a supply chain problem that you either caught before deployment, or you were stuck with forever. That was wrong.

The Detect, Unlearn, Restore paper demonstrates something that should change every production deployment process: poisoning leaves permanent structural fingerprints inside the model. You do not need access to the training data to find it.

In black box settings, poisoned models show 2-3x greater sensitivity to semantic preserving perturbations. You can audit a running production model for poisoning without any internal weights, without training logs, without cooperation from the vendor that supplied it.

Setting	Detection precision	Unlearning recovery	ROUGE degradation
White box	92%	96%	0.4%
Black box	85%	91%	0.6%

This is not perfect. But it works. And almost nobody is running this audit today.

Most teams still check for poisoning once, before deployment, then never check again. Adversaries know this. They are now poisoning models slowly, after initial deployment, via incremental fine tuning batches that individually pass all pre-deployment checks.

Attention layers leak everything

Everyone assumed tabular foundation models were low privacy risk. Everyone was wrong.

The attention mechanism itself leaks membership information. Not by accident. Not via memorization. By design.

AMIA, the attention based membership inference attack, outperforms all existing confidence based attacks by 7.7%. It works even when the model was never trained on sensitive data. It works entirely on context examples passed at inference time.

You can pass a single sensitive record as a one shot in context example. The model will never memorize it. It will never output it. But the attention pattern generated while processing that query will let an attacker confirm that exact record was present.

The proposed defense is trivial. You do not need differential privacy. You do not need retraining. You just normalize attention key representations for high risk queries. This cuts leakage by 50% with 3.9% performance loss.

As of today zero major LLM providers implement this.

Safety judges are not what you thought

Almost every production LLM deployment uses an LLM judge as the final safety gate. This is the single most expensive and most trusted component in almost every safety pipeline.

It is also almost completely unnecessary.

Fine tuned encoder models match LLM judge performance across every major adversarial safety benchmark. They run 100x faster. They cost 50x less. They do not hallucinate judgements.

Nobody wants to admit this. Entire teams have been built around running LLM safety judges. There is no good technical reason to use a 70B parameter decoder model for this job. A 120M parameter encoder will do just as well.

You cannot measure safety from outputs

All standard safety evaluation works the same way. You run a bank of prompts. You judge the output. You produce a score.

This approach is broken. It is trivial for a modified model to produce perfectly safe outputs for every prompt in your test bank, while reliably complying with every jailbreak prompt not in that bank.

RAS, the Refusal Alignment Score, does not look at outputs. It looks at the internal hidden states of the model. It measures whether the model is actually activating the refusal pathways, not just whether it happens to output a safe string for the specific prompt you tested.

RAS correctly separates aligned, abliterated, and jailbroken models 100% of the time across Llama, Gemma and Qwen families. It runs in milliseconds. It cannot be gamed by fine tuning around the test set.

If you are still evaluating safety by running prompt lists you are wasting your time.

Multimodal attacks are already invisible

Nobody is checking for visual prompt attacks.

You can draw a tiny 3x3 pixel arrow in the corner of an input image. No human will ever see it. Every commercial image to video model will read it as an instruction. As of this writing this attack has 100% success rate against Wan 2.7 and 74.8% success rate against Google Veo 3.1.

There is no text prompt involved. There is nothing for your existing safety filters to scan. The attack is encoded entirely into pixel values.

VPA-Guard reduces this attack success rate by 44%. It is the only existing defense that works. No major commercial provider has deployed it.

RAG has an entirely separate attack surface

RAG did not fix LLM hallucinations. It just moved the attack surface.

Every single part of the RAG pipeline is exploitable. The index. The retrieval step. The context window. The reranker. None of these are covered by standard LLM safety controls.

Attacks already exist that:

• Poison retrieval indices to inject false facts into every generated response
• Infer the full contents of a private RAG index using only public query outputs
• Exfiltrate sensitive documents via carefully constructed user queries that trigger retrieval then leak the content via steganography in the output

Most teams deploying RAG have done exactly zero security review of the retrieval pipeline. They treat it as a safe appendage to the LLM. It is not. It is the easiest point of attack.

The double trust failure

None of the academic attacks are the ones that are actually causing damage right now. The real failure mode is much simpler.

Everyone learned to sanitize user input. Nobody learned to sanitize model output.

This is the single most common security bug in production LLM systems today. Developers implicitly trust output that came from the model. They treat it as safe. It is not.

Model output is untrusted input. Exactly as untrusted as the raw string the user typed into the box. It can contain injection. It can contain exfiltration. It can contain payloads.

This one mistake is responsible for 90% of all exploited LLM vulnerabilities found to date.

We already lost the asymmetry war

AI moved both sides of the board at once.

It writes the bugs. It finds the bugs. And it does both faster than humans can react.

The median time from public disclosure of an LLM introduced bug to mass exploitation is now five hours.

That is not a window. That is a head start.

You will not patch fast enough. You will not audit fast enough. Obscurity will not protect you. The bug you missed yesterday will be found and exploited before you finish your morning coffee.

This is not a problem that can be solved by writing more carefully. That threshold was crossed this year.

What actually works right now

Almost none of the proposed grand solutions work. Most of the compliance checklists are useless.

A small number of things do work:

1. Treat all model output as untrusted input. Sanitize it on the way out, exactly as you would sanitize any user input.
2. Audit running production models for poisoning on a regular schedule. Do not check once before deployment.
3. Replace LLM safety judges with fine tuned encoders. You will get better performance, lower latency, and lower cost.
4. Measure safety via internal model activations, not output strings.
5. Normalize attention keys for all high risk queries.
6. Assume every bug in your code is already known to attackers. Build disclosure channels before you need them.

None of these are fancy. None of them require new research. All of them are things you can deploy this week.

This is the state of LLM security in mid 2026. The threats are no longer theoretical. The defenses exist. Almost nobody is using them.