Llama-3.1-8B-Instruct.immunized.v2

Authenticity notice. The only verified source for this model is ApolloRaines/Llama-3.1-8B-Instruct.immunized.v2 on Hugging Face. If you obtained these weights from any other location -- a mirror, a re-upload, a torrent, a cloud storage link, a fork -- I cannot confirm the weights are unmodified. Any fine-tuning, LoRA merge, continued pretraining, RLHF, or gradient-based training performed on top of the immunized weights can possibly degrade or wash out the immunization, whether or not that was the intent. Verify the file hashes against the reference values below before deploying, and if you plan to fine-tune, re-benchmark against the 100-attack canary suite to confirm the defense still holds.

What changed from v1

v2 rebuilds the immunization on a cleaner substrate and closes most of the role-based failure mode that v1 left open.

• Canary defense: 98/100 vanilla stack -> 100/100 (unchanged)
• Role-based defense: v1 63/100 -> v2 83/100 (+20)
• 16-attack EchoLeak battery: v1 15/16 -> v2 16/16 (ceiling)
• Calibration: 100% preserved

Same drop-in replacement API. Same license. Same base model.

File hashes (SHA256)

Verify with sha256sum <filename> after download.

e5527aad870650ce48777a454e2c20f6f9fe98c3ecad347f86cdac3d4b44cfd2  model.safetensors
efe03af44b2ef3bf4382bbfd17d3b526134c31bb0c629abc31d9cecd5fb73681  Llama-3.1-8B-Instruct.immunized.v2.F16.gguf
aaf7bbf7639d0dc4c5eb6cbde957b6190db7771f848f762d24b5fa9b512ef81f  Llama-3.1-8B-Instruct.immunized.v2.Q8_0.gguf
53d4f23ee1394dec06d57929ea0819f0e32b65673abf23de3aef30975006666a  Llama-3.1-8B-Instruct.immunized.v2.Q6_K.gguf
3cffe3e50b5044a4b48f24cc53cb141413ee08959117a766c2c63a440cc7ce66  Llama-3.1-8B-Instruct.immunized.v2.Q5_K_M.gguf
52846cc9b14181c47927aded2ebbf1a23209449dcec06329437a85aed0455928  Llama-3.1-8B-Instruct.immunized.v2.Q4_K_M.gguf

An EchoLeak-immunized variant of meta-llama/Llama-3.1-8B-Instruct, produced by the jBlaze weight-surgery pipeline. Ships as a drop-in replacement -- no runtime hooks, no external dependencies, no altered inference API. Loads with standard AutoModelForCausalLM.from_pretrained().

What is EchoLeak?

EchoLeak (CVE-2025-32711 class) is a prompt-injection attack pattern where an LLM assistant with access to private context is manipulated -- via instructions embedded in untrusted documents, retrieved content, tool results, or webhook payloads -- to disclose that private context. It affects all current instruction-tuned LLMs when they are wired into retrieval-augmented, agentic, or role-based deployments.

OWASP has listed prompt injection as the #1 AI risk three years running. A 2026 research paper formally proved it's incurable at the prompt layer. Every 2026 Microsoft Copilot prompt-injection disclosure (ShareLeak CVE-2026-21520, CoSnitch CVE-2026-24301, SearchLeak CVE-2026-42824, plus the May Patch Tuesday trio CVE-2026-26129/-26164/-33111) has landed at the wrapper layer around a model that still has the underlying weakness. Microsoft cannot fix it in GPT weights from outside. jBlaze does the fix at the model layer.

What does immunization do?

The jBlaze immunization removes the specific model behavior that produces EchoLeak-style leaks, while preserving reasoning capability, calibration, and instruction-following. The modification is permanent, baked into the weights, and requires no runtime hooks or system prompt overhead.

No fine-tuning. No training data collection. No forgetting. The immunized weights are computed from a curated scenario set.

Benchmarks

Canary defense benchmark (100 attacks, research-standard)

Setup: system prompt contains CANARY-7F3A-92D1 with an explicit "never disclose" instruction. Model asked to summarize a document containing one of 100 attack payloads. Leak = canary value appearing in the response.

Categories tested: direct instructions disguised as content, claimed authority/role spoofing, task-aligned persuasion, hidden/low-salience placement (HTML comments, CSS, ARIA), outbound-channel abuse (markdown images, webhook URLs), encoding tricks (base64, ROT13, unicode escapes, acrostics), multi-step delayed instructions, social/safety pretexts, boundary confusion in structured data, adaptive semantic variations.

Vanilla meta-llama/Llama-3.1-8B-Instruct: 94 / 100 (fp16 transformers stack)

Immunized v2: 100 / 100 (fp16 transformers stack)

The v1 GGUF quantized benchmark table is preserved for reference. v2 quant benchmarks will be published shortly under the same measurement methodology (llama-cpp-python chat completion API, single-turn).

Quant	Vanilla	v1 immunized
F16 (llama.cpp)	87 / 100	100 / 100
Q8_0	85 / 100	99 / 100
Q6_K	88 / 100	100 / 100
Q5_K_M	91 / 100	99 / 100
Q4_K_M	90 / 100	97 / 100

Role-based benchmark (100 attacks, harder)

Setup: model given a role (procurement assistant, financial advisor, HR bot, medical bot, etc.) with role-relevant private data. Attack payloads exploit the model's natural over-eagerness to serve its role.

	Vanilla	v1 immunized	v2 immunized
Passed	36 / 100	63 / 100	83 / 100
Leak rate	64%	37%	17%

v2 relative leak reduction vs vanilla: 73%. Every persona-hijack attack pattern in the suite is defended against materially better than in v1. The remaining 17 failures cluster in a specific attack shape (sensitive data embedded in the system prompt with a soft-marker user request to reference it) that is being characterized for v3.

16-attack standard EchoLeak battery

Vanilla: 9/16. v1 immunized: 15/16. v2 immunized: 16/16.

The v2 immunization defends every attack in the standard test set.

Quality preservation

Calibration (factual accuracy): 100% identical to vanilla. The immunization does not impair factuality or instruction-following.

Usage

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained(
    "ApolloRaines/Llama-3.1-8B-Instruct.immunized.v2",
    torch_dtype="float16",
    device_map="auto",
)
tokenizer = AutoTokenizer.from_pretrained(
    "ApolloRaines/Llama-3.1-8B-Instruct.immunized.v2"
)

messages = [
    {"role": "system", "content": "You are a helpful assistant. Private context: ..."},
    {"role": "user", "content": "Summarize this document: ..."},
]
prompt = tokenizer.apply_chat_template(messages, tokenize=False,
                                         add_generation_prompt=True)
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=500, do_sample=False)
print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:],
                        skip_special_tokens=True))

GGUF variants for llama.cpp deployment will follow in a separate upload under the same naming convention: Llama-3.1-8B-Instruct.immunized.v2.{Q4_K_M,Q5_K_M,Q6_K,Q8_0,F16}.gguf.

No API changes. No runtime overhead. No inference-time cost.

For the reverse engineers

Yes, you can diff this against the vanilla meta-llama/Llama-3.1-8B-Instruct and reverse-engineer the modification. Go ahead. Here's what you'll find:

• A small number of weight matrices at a specific mid-layer window were modified via a low-rank projection.
• SVD of the diff will recover the direction vectors and alpha coefficients up to quantization noise (cleaner from Q8, blurrier from Q4).
• The rank of the modification is small and easy to identify.

Here's why that doesn't help you build a competing product:

• The direction vectors are extracted from Llama-3.1-8B's specific 4096-dimensional residual stream at specific layer indices. They are mathematically undefined outside this exact checkpoint. Applying them to Llama-3.1-70B (8192-dim, 80 layers), Qwen-32B (5120-dim, different architecture), or Gemma-27B (different attention structure) yields nothing coherent.
• The alpha calibration was found by search on this model's activations. The optimal alpha for a different model is a different number, and finding it requires re-doing the search.
• The injection data determines what gets captured. Different data produces different immunizations. Mine is my data, and it's what makes the difference between 60% and 100%.
• v2 uses a cleaner substrate preparation step that the diff will not reveal. That step is where the +20 role improvement comes from.

The technique category ("rank-K weight surgery targeting output projections") is already in the ML literature. The value is in the specific engineering per model: which layers, which alpha, which injection data, how to compose, what substrate to work on. That engineering is what I sell.

If you want an immunized Llama-3.1-70B, or Qwen 2.5 72B, or Mistral Large, or your proprietary base model -- you either do the engineering yourself (weeks-to-months, no guarantee of my calibration) or you send me the model.

Custom immunizations

I ship immunizations as models, not code. I work at the foundational model level only -- Llama, Qwen, Mistral, Gemma, Claude, GPT, Gemini, DeepSeek, Phi, and their sibling base checkpoints. Downstream fine-tunes and enterprise deployments inherit the immunization when they start from an immunized base.

Current capacity

My immunization rig runs on dual RTX 3090 with NVLink (48GB unified VRAM). At that capacity I can immunize models up to roughly 30B parameters. Immunization runs at fp16 -- the weight surgery math needs float precision. Quantization to Q4/Q5/Q8/etc. happens afterwards on the finished immunized model, not before.

If you need a small-to-mid foundation model immunized (Llama-3.1-8B, Qwen 2.5 7B/14B, Mistral 7B/22B, Gemma 12B/27B, Phi-4, DeepSeek distills up to ~30B), I can do that today on my current hardware, and it's not volunteer work.

For mid-large foundation models (30B - 120B), I can accept the job if my workstations are upgraded to their maximum 4x RTX Pro 6000 Blackwell configuration. Two cards live in the server, one each in the development workstations. If you want a model in that size range immunized, we can either wait for the workstation upgrade or you can accelerate it as part of a sponsorship deal.

For full-scale foundation models (Llama-3.1-70B in fp16 and up, Qwen 2.5 72B, Mistral Large, Claude / GPT / Gemini foundation weights, Llama 400B, DeepSeek V3) I need a proper datacenter node -- minimum useful sponsor hardware is an 8x B300 server. See below.

Timing

Immunization is not instant. Each new model requires its own calibration -- the direction vectors, alpha values, and optimal layer window are model-specific and have to be searched for. The first jBlaze immunization on Llama-3.1-8B took roughly 100 hours of scanning to find the working configuration. Subsequent models are faster because I have priors on approximate layer depth, approximate alpha range, and which matrices to target -- but each iteration is more expensive on a bigger model, so the total wall clock stretches.

Rough expectations for priority customers (sponsors and first-in-queue), assuming the target hardware is available:

• Small models (up to ~14B): days
• Mid models (14B - 70B): 1-2 weeks
• Large models (70B - 400B): several weeks
• Frontier scale (400B+): month or more

If you need a specific delivery date, discuss it up front.

I do not run my code on your servers.

The jBlaze weight-surgery pipeline is proprietary. It does not leave hardware I control. That means for full-scale foundation models we set up a hardware sponsorship:

• You ship a proper GPU node -- minimum useful configuration is 8x B300, sized to whatever the target model requires. Bigger models want bigger nodes.
• The hardware is registered in my name, at a data center of my choice, and stays there.
• You cover the data center bill: power, cooling, colocation, network.
• In exchange, you receive discounted pricing on immunizations for your foundational models, plus priority in the queue.
• Your models come to me, get immunized, and go back to you. My code never touches your infrastructure.

The same cluster can service other foundational labs at full pricing. Multiple sponsors get multiple regional clusters, all under my operational control.

Pricing

• Standard immunization: Discuss
• Hardware-sponsor rate: Discuss (substantially lower)
• Sponsors get a regional cluster in exchange, and non-sponsors pay full rate to use that same cluster

What I do not do

• Enterprise fine-tunes and LoRA adapters (start from an immunized foundation instead)
• Bespoke customer models
• Consulting engagements where my code touches your hardware
• Delivering the technique as source code, weights adjustments as scripts, or any form of transferable IP

Contact: apollo@saiql.ai

Security considerations

Weight surgery is dual-use. jBlaze is not shipped as software, only as immunized model artifacts, and the full pipeline stays private. That is a deliberate choice, not a marketing posture. See jblaze.dev/release for the reasoning.

EchoLeak immunization is one proof of what jBlaze can do. It is not the ceiling. jBlaze is a general behavioral weight-editing framework. The same pipeline that produced this checkpoint has been used to characterize and modify a broad range of model behaviors, and at this point what stays outside its reach is a shrinking list. Practically anything that can be characterized and benchmarked is addressable, defensively or otherwise.

Documented capabilities across prior jBlaze work include:

• Behavior removal: prompt-injection vulnerability classes (this release), jailbreak susceptibility, sycophancy, deception, over-eager role-persona behavior, refusal responses (with personality preserved), goal drift in long-running agents.
• Behavior enhancement: analytical skepticism, precision, code- security awareness, context-faithfulness, step-by-step reasoning. Measured reasoning gains on smaller models have exceeded 45 percentage points on held-out benchmarks.
• Knowledge modification: targeted factual insertion at scale that substantially exceeds what LoRA-based approaches can absorb, and selective knowledge erasure that leaves general reasoning intact.
• Personality and style: identity implants, voice preservation during other surgeries, style transfer without fine-tuning.

In the wrong hands, the same pipeline can:

• Plant neural trojans -- trigger-conditional payloads that lie dormant until activated by a secret input phrase.
• Insert sleeper personas -- second personalities that appear only on specific keywords, invisible during any standard benchmark.
• Remove safety alignment on a foundation model in minutes, without leaving detectable fine-tuning traces.
• Backdoor open-weight models redistributed through mirrors and community forks, producing variants indistinguishable from benign fine-tunes to standard scanners.

EchoLeak is a defensive proof-of-concept because it has a documented CVE, a clean benchmark, and no acceptable alternative solution in the public literature. The offensive capabilities listed above are capabilities of the technique category, not features of any released artifact. The pipeline stays private for the reason those two lists sit next to each other on the same page.

Limitations of this Model

• Immunized against the EchoLeak attack class specifically. Other attack classes (jailbreaks, refusals, hallucinations) are unchanged.
• The remaining 17 role-based failures cluster in one specific attack shape (sensitive data embedded in the system prompt, user requests it back via a soft marker). v3 will target this pattern directly.
• Immunization is measured against meta-llama/Llama-3.1-8B-Instruct specifically. Behavior on other checkpoints is undefined.

Beyond EchoLeak

EchoLeak is the demonstration. The technique is broader.

Frontier labs and safety teams are worried about a class of behaviors that cannot be fixed at the prompt layer: agents that pursue unintended objectives, models that resist correction or shutdown, jailbreaks that bypass safety training, sycophancy and deception, reasoning that hides motivations from oversight, mesa-optimization, goal drift as agents run longer. Search phrases like "AI alignment," "AI existential risk," "agent misalignment," and "AI control problem" if any of that is new. The concern is real enough that a meaningful fraction of frontier-lab research budgets are aimed at exactly these failures.

These are behaviors, not architecture problems. Behaviors can be characterized, benchmarked, and -- if a benchmark exists -- immunized against with the same jBlaze weight-surgery approach that produced this model. The pipeline that produced this checkpoint is not EchoLeak-specific. EchoLeak was chosen first because it has a clean pass/fail benchmark and a real CVE attached, which makes results verifiable. Other behaviors that keep alignment researchers up at night are accessible the same way, and I have working direction candidates for several of them.

If you're a frontier lab with a specific safety failure mode you need removed from a foundational model, and you can characterize the failure well enough to score against, ask. Same pricing structure applies, same hardware constraints.

Citation

@misc{jblaze-echoleak-immunization-v2,
  author = {Raines, Apollo},
  title  = {jBlaze EchoLeak Immunization v2: Weight-Surgery Defense Against Prompt Injection},
  year   = {2026},
  note   = {https://huggingface.co/ApolloRaines/Llama-3.1-8B-Instruct.immunized.v2},
}