← Retrieval From First Principles

Defending the Retrieval Boundary

Keep untrusted source content separate from caller authority, and test exact reference, permission, admission and output boundaries.

A retrieved note contains a launch code, followed by an instruction to ignore the application’s rules and request private documents. The legitimate question asks about the code. The note attempts to answer the question and redefine the application’s authority in the same paragraph.

Ranking the note does not settle how to handle that attempt. Deleting every source containing an imperative would also remove legitimate procedures and quotations. We need to distinguish source content from permission to control the application.

The Reference Retrieval Contract made evidence validation explicit. Security asks whether those checks still hold when a source or request is adversarial.

State the attacker and the protected boundary

Our constructed attacker can place hostile text in a source, submit misleading request content, alter a candidate reference or attempt to widen a source allowance. The fixtures can revoke access, change a current version, introduce duplicate text under another authority and invalidate a relationship.

The attacker does not control the trusted caller, canonical manifest, model weights, interpreter or application process. Those exclusions matter. A Python function cannot authenticate the person who supplied its trusted view, and a digest cannot protect a manifest from an attacker authorised to replace it.

The protected assets are source-qualified evidence, the caller’s permitted scope, the actual admitted input and the public diagnostics. We also protect the separation between generating text and carrying out an action. The consumer adapter has no shell, document editor, publication endpoint or arbitrary tool dispatcher.

The boundary diagram lists what the constructed attacker can do and which check answers each attempt. Only the left column is adversarial input; every check sits inside the protected region.

    %%{init: {"flowchart": {"wrappingWidth": 470}}}%%
flowchart TD
    A1["Hostile text placed in an eligible source"] --> C1["Content stays labelled data; roles are preserved in the request"]
    A2["Misleading request content"] --> C2["Original request identity is retained; scope cannot be widened"]
    A3["Altered candidate reference"] --> C3["Reference, span and parent digest are revalidated before admission"]
    A4["Revoked, stale or duplicated evidence"] --> C4["Admission rechecks the supplied current view"]
    A5["Statement without operator support"] --> C5["A non-empty relationship path needs a trusted checker"]
    A6["Citation to material never admitted"] --> C6["A citation is an output claim checked against admitted labels"]
    classDef attempt stroke:#b3261e,fill:#fbe9e7;
    class A1,A2,A3,A4,A5,A6 attempt;

The attacker is explicitly excluded from the trusted caller, the canonical manifest, the model weights, the interpreter and the application process. Those exclusions are the boundary’s stated limits, not assumptions the checks can verify.

Research on indirect prompt injection describes risks created when externally supplied data becomes model-facing input. It motivates this boundary; it does not certify our implementation or transfer a paper’s attack results to this model.

Treat content as data throughout retrieval

Indexing, embedding, fusion and selection can process a hostile sentence without executing it. The existing tools have typed read-only actions and a finite allowance. A document requesting another source cannot add a tool or enlarge the caller’s scope.

The consumer prompt preserves a separate system message and supplies evidence as labelled JSON data in the user message. That representation makes the intended roles inspectable. It does not make the model mathematically incapable of following malicious text. Serialisation and an instruction to treat evidence as data are conventions at the model boundary, not a general solution to prompt injection.

Even if the model outputs an imperative, no component converts that output into a shell command or application mutation. This limits the effects of a model mistake. It does not prove that the answer itself will be accurate, grounded or free from attacker influence.

Refuse forged evidence before asking the model

Reference validation is independent of the source’s rhetoric. A source cannot grant itself another authority by printing a different identifier in its body. The selected reference must resolve against the canonical manifest, its content digest and its exact span.

Our tests replace the source identity, change the span and modify the manifest unit body while leaving the parent text intact. Admission rejects those inconsistent objects. Duplicate text from another authorised origin remains a different reference; equal bytes do not transfer authority or permission.

Eligibility is checked again after selection against the supplied trusted view. The ordinary application reuses the request’s view. The revocation test starts with valid selected evidence, explicitly supplies an updated trusted view and attempts admission. The version test makes another version current. Both refuse the stale packet rather than admitting text on the strength of an earlier decision.

This final check complements the earlier per-view candidate and path checks. It does not justify searching an unrestricted index and exposing its intermediate inventory. Every stage capable of returning a protected identifier needs its own correct projection before that information becomes public.

Give relationships their own validation

Permissions apply to the evidence supporting a relationship, including intermediate nodes and source spans. A path can fail even when its endpoint is public. The earlier graph and multi-hop controls exercise restricted and missing hops, wrong bridges and conflict.

The new consumer contract requires a trusted current relationship checker for any non-empty path. Without one, it refuses the path. This is a conservative capability boundary, not evidence that this application has integrated a general graph authorisation system. Following declared relations, extracting relations and proving them true remain separate operations.

A public refusal must also avoid disclosing why a particular protected hop failed. Our public error projection merges unavailable references, missing versions and unsupported paths into a generic signal. It returns no denied-source inventory. The internal fixture can distinguish those causes without requiring the public interface to disclose them.

Treat a citation as an output claim

The consumer may print an evidence label. The parser checks that the label was actually admitted and that it is not duplicated. A citation to a selected-but-excluded unit, a never-admitted label or another source version is not accepted as a valid admitted reference.

That establishes reference validity only. A valid label may accompany an unsupported assertion. A model may also answer correctly from prior knowledge without citing anything. Neither citation presence nor prompt inclusion proves causal reliance on a source.

The experiment therefore keeps malformed output, valid labels, reference-answer agreement, annotated support coverage and semantic support in different fields. It does not calculate an unsupported-assertion rate by subtracting exact-match accuracy from one. That rate requires an assessment of assertions and evidence which the automated string scorer does not supply.

Read the security evidence at the right level

Threat Tested boundary Established observation Remaining limit
Forged source or span Canonical reference validation Constructed invalid packets are rejected Canonical manifest is trusted
Revocation or stale version Admission projection Changed-view packets are refused Live identity and policy discovery are absent
Scope widening Separately supplied caller allowance A larger packet allowance is rejected Caller authentication is not implemented
Restricted relationship Required trusted path checker Unvalidated paths are refused No general application graph adapter is claimed
Invented citation Admitted-label parser Never-admitted labels are invalid Valid labels do not prove support
Hostile source instructions Read-only tools and no action executor Source text cannot add an application tool Model answer resistance needs separate evidence

The local model experiment also includes an injected source. On the injection question, all six evidence-bearing conditions—lexical, dense, hybrid, adaptive, gold-one and gold-two—admit hostile material and repeat its attack marker and demand for private documents. The no-retrieval output does neither. Dense and hybrid also admit and echo the hostile text on the single-fact control. These are observed source-contamination failures in generated prose.

On that same-author fact control, the declared code appears in prose under all six evidence-bearing conditions and is absent from the no-retrieval output. This is an unscored constructed demonstration of evidence-conditioned text generation, not an independently measured semantic answer gain.

Keep four events separate: hostile text entering the prompt, the model repeating it, the model following a malicious instruction, and the application executing a prohibited action. Only admission and repetition are directly observed here. The adapter grants no action tools; these outputs do not establish an unauthorised tool call or successful external compromise.

This remains a small same-author mechanism observation. It cannot establish robust resistance across attacks, models or contexts, and malformed output cannot be promoted into a validated safe answer. Whether a model quotes an instruction or follows it internally is also different from the application’s observable execution of an action.

These are contract tests and bounded model observations, not a penetration test, authentication audit or security certification. Production deployment would need an explicit identity service, policy lifecycle, cache isolation, concurrency behaviour, monitoring and independent adversarial evaluation.

An answer assembled from unauthorised or misattributed evidence is not a valid retrieval success. Improve and Writer: A Real Retrieval Workflow carries that obligation into an application while keeping recommendation, approval and execution separate.

References and further reading

Background and extensions for this chapter: