The instruction you couldn’t see

Latent injection occurs when an attacker places instructions inside content that an AI system later reads as data. A legitimate document workflow becomes the delivery path. Testing must examine both the model's response and the consequential decisions the surrounding system permits.

Applied research note · Issue 03 · August 2026. This article preserves a local-model screening experiment and its limitations. The direct prompt-injection measurements, the paired document illustration and proposed future evaluations are separate pieces of evidence. None is an AGMIO product benchmark or a guarantee of injection resistance.

Start with the workflow and its data

AI agents increasingly read resumes, claims, loan files and KYC packets. Teams handling sensitive information may choose locally hosted models to keep the workflow within infrastructure they control. That choice can help address data-handling requirements, but it does not make document content trustworthy or establish regulatory compliance.

This investigation used an ordinary task: screening a resume with Ollama llama3.1:8b. An applicant's document is untrusted input; it also contains personal information and can influence a consequential recommendation. Those three characteristics define the threat model.

Choose probes for the exposed workflow

NVIDIA garak provides many language-model vulnerability probes. Running every family is not the same as testing the right boundaries. A text-only screening agent's priorities differ from those of a coding agent, browser agent or multimodal system.

The original assessment grouped probe families as follows. “High,” “medium” and “low” describe a proposed run order for this screening use case, not a universal ranking of threat severity or probe quality.

The measured direct-injection run

The initial experiment ran three promptinject probes from garak v0.15.1 against the raw local model. Each probe used 256 crafted prompts repeated five times, giving 1,280 attempts per probe. The recorded outcome was whether the model emitted an attacker-chosen string.

The three-probe sweep took 28,169 seconds, approximately 7.8 hours of local inference. Probe names identify garak stress tests; they are not descriptions of the screening task.

When the document becomes the delivery path

In a direct attack, someone addresses the model with a hostile instruction. In a latent attack, a third party places the instruction in a document that an ordinary user later submits, retrieves or processes. The model encounters it as part of a legitimate task.

The problem resembles the mixing of commands and data seen in injection vulnerabilities: material intended as evidence can be treated as authority. Unlike a formal query language, natural-language prompting has no equivalent of parameter binding that alone guarantees a passage is treated only as data. The surrounding application must define and enforce the trust boundary.

One PDF, two views

The illustration used a fictional candidate, Stella Mary, with three months of data-entry experience and basic Excel skills. White text placed in a PDF margin was difficult for a person to see but available to text extraction. Parser behavior depends on the document and extraction method; the demonstration used this gap, rather than establishing that every parser behaves identically.

The same pattern can arise in an invoice that asserts a payment has already been approved or a KYC attachment that claims additional checks are unnecessary. These are examples of the risk mechanism, not reported incidents.

A guarded and unguarded illustration

The team ran the same resume and local model through two paths. The unguarded path placed the document directly into the model's context. The guarded path cleaned detected instructions, constrained the response and checked its evidence.

These are recorded demonstration outcomes, not fixed outcomes for every run. The public lab notes explain that the live model is stochastic: a guarded run may return REJECT or REVIEW, and the unguarded model does not comply with the attack on every attempt. Other samples also expose failures in the guard itself.

Five layers around a fallible model

1. Signature detection and excision. Identify known markers, remove matching lines and record findings. This is pattern-bound detection and useful telemetry; a paraphrase can evade it.
2. Spotlighting. Place the cleaned document inside delimiters containing a fresh random token. This makes a predictable closing delimiter harder to forge, but the model still has to respect the instruction boundary.
3. A constrained output contract. Accept a decision from a fixed set, a score and evidence quotations. Reject malformed or unexpected output to human review. Removing free-form response channels limits some payloads; it does not make the remaining values immune to influence.
4. Evidence grounding. Check that evidence spans appear in the cleaned document. This can reject invented citations, but does not establish that every surviving source passage is trustworthy.
5. Taint handling and fail-closed review. If a detector flags the document, prevent automatic advancement. Missing or invalid results go to a reviewer. The illustration records decisions and control events in a hash-chained log.

The architectural aim is to limit the consequences of a model being redirected. A detector, prompt or response schema alone should not be presented as a complete defense.

The implementation, in five stages

The original article walked through these code stages. They are consolidated here so the order and purpose remain visible; the public implementation contains the executable detail.

1. Excise and record. excise() scans document lines against known signatures, retains unmatched lines and returns a findings list. Recording matches matters because the later review rule uses that signal.
2. Fence the cleaned text. fence() creates a fresh nonce and wraps the input with matching document delimiters, while the application identifies the enclosed text as untrusted data.
3. Admit only a valid result. admit() extracts the structured response and checks the allowed ADVANCE, REVIEW or REJECT decision. A contract violation returns review rather than permissively accepting the output.
4. Ground the evidence. Normalize and compare quoted spans with the cleaned document; discard unsupported evidence and record that event.
5. Apply the taint decision. If signatures fired and the model recommends advancement, downgrade it to REVIEW. Record the final decision and relevant control events.

Keep consequential values inside trusted controls

For a payment workflow, the authoritative payee or amount may need to come from a trusted system of record, rather than text in an uploaded invoice. For identity verification, a document's claim that a check is complete is not the same as a trusted verification result.

Define the evidence needed for the action, the system authorized to supply it and the conditions requiring human approval. A model recommendation can inform a decision without inheriting permission to execute an irreversible action. This is a design principle illustrated by the experiment, not a claim that the demonstration implements every control for every business process.

The failures remain part of the result

The linked lab also deliberately records failure cases:

• Paraphrase evasion: an instruction without recognized markers can pass detection and affect the guarded recommendation.
• False positives: benign wording can trigger review and disadvantage a legitimate applicant.
• Partial excision: line-based removal can leave parts of a multi-line payload behind, which a later quotation check can mistakenly accept as grounded.
• Benchmark blind spots: a restricted response format can suppress an attack's trigger phrase without eliminating decision manipulation. A low trigger-echo rate alone is insufficient evidence of safety.

In hiring, these problems have fairness implications as well as security implications. Evaluation should examine changed recommendations, changed scores, unnecessary reviews and the applicant's ability to obtain a meaningful human review.

What had been measured—and what came next

The direct-injection results above were a measured garak run. The resume comparison was a controlled illustration on the same model. The article did not report a completed, generalizable guarded latent-injection attack-success benchmark.

The next evaluation proposed in the note was to run garak's latentinjection probes against guarded and unguarded endpoints, compare the results and track relevant regressions across builds. The lab also provides a way to examine recommendation skew: compare the same document with and without the injection, alongside the trigger-detection result.

Another proposed extension was multi-agent testing. In an intake → extraction → decision → payout workflow, a poisoned passage may propagate through handoffs even if individual agents appear acceptable in isolation. That extension was future work in the original note, not a completed evaluation.

Read the code and its limitations together

The latent-injection illustration repository contains the exploit demonstration, five-layer guard, an eight-document sample corpus and 44 tests, including four that explicitly exercise failures. It runs with a local Ollama llama3.1:8b model. The source and test cases are the appropriate place to inspect the implementation and reproduce its stated conditions.

NVIDIA garak supplies the scanning tool and probe families. Direct-injection figures in this note came from the reported raw-model run; the separate document illustration and guard came from the team's lab. Keep those sources and evidence types distinct when reusing a result.

For the companion question of how orchestration rules affect a group of agents, read Issue 02: Test the environment your agents live in—not just the agents.