ChainGuard: A Layered, Stateful, and Provenance-Aware Runtime Security Architecture for Prompt Injection Defense in Locally Operated Large Language Models

1. Introduction

Large language models are increasingly embedded in applications that combine private system instructions, user requests, retrieval-augmented context, memory, and tool execution. This composition creates a security problem that differs fundamentally from conventional command parsing. Although an application may assign different trust levels to these sources, the model ultimately receives token sequences and infers their roles from learned patterns rather than from an enforced control data boundary [1]. An attacker can exploit this ambiguity by presenting lower-trust text that resembles a higher-priority instruction, requests access to protected context, redirects task execution, or induces an agent to follow instructions embedded in retrieved documents or external content [2]. Formal analyses have further shown that this lack of an explicit control data separation is an inherent architectural limitation rather than a simple implementation flaw [3].

The resulting attack surface extends beyond the familiar phrase “ignore previous instructions.” A request can disclose protected context without using the verb reveal; it may ask for a translation, diff, checklist, serialisation, or detailed reconstruction. Payloads may be encoded, fragmented by zero-width characters, distributed across turns, or carried in a retrieved document or tool response. Defenses that recognise only fixed strings tend to miss semantic paraphrases, whereas aggressive classifiers may over-defend and block legitimate discussions, quotations, public examples, and transformations of user-provided text [4]. Multi-turn settings add a temporal dimension: individually plausible turns can establish a protected target, assign it an alias, and request disclosure later.

Existing work has developed systematic prompt-injection benchmarks [3], guard models [4,5], task-alignment and action-level defenses [6,7], and stateful intent modelling [8]. These approaches establish that no single lexical rule, classifier, or prompting strategy should be assumed to form a complete security boundary. Recent theoretical and adaptive evaluations further caution that wrapper defenses face fundamental completeness utility trade-offs and can be bypassed under distribution shift [9,10,11]. The practical question is therefore not whether a lightweight proxy can guarantee universal safety, but whether a layered, auditable, locally operated design can provide measurable protection while exposing its assumptions and failure modes.

This paper presents ChainGuard, a provenance-aware runtime security architecture for protecting locally operated LLM applications against prompt injection attacks. Rather than relying on a single defense mechanism, ChainGuard combines deterministic preprocessing, provenance-aware ingress control, interpretable lexical and semantic analysis, bounded conversational state, explicit policy enforcement, lightweight local classification, and output leakage inspection within a unified security pipeline. The architecture is designed for local and on-premises deployments where data locality, transparency, auditability, and predictable computational costs are important.

1.1. Contributions

This paper makes the following contributions:

• We present ChainGuard, a provenance-aware and stateful runtime security architecture for protecting locally operated LLM applications against direct and indirect prompt injection attacks.
• We introduce a source-aware threat model that distinguishes trusted instructions from untrusted retrieved, tool-generated, memory, and external content to enable provenance-aware policy enforcement.
• We evaluate ChainGuard on a post-development holdout together with a matched transparent lexical baseline, reporting detection effectiveness, runtime performance, statistical confidence intervals, and detailed failure analysis.
• We identify the remaining challenges of lightweight runtime prompt-injection defense, particularly multilingual semantic understanding and protected-text transformations, and establish a reproducible foundation for future comparison against learned guard models and public benchmarks.

2. Background and Related Work

Prompt injection exploits the weak separation between trusted instructions and lower-trust user, retrieved, tool, or memory content [1]. Direct prompt injection originates from user-controlled input, whereas indirect prompt injection is introduced through external content such as retrieved documents or tool outputs [2]. Unlike safety-policy jailbreaking, application-level prompt injection targets the integrity of the application’s task, protected context, or tool behaviour. ChainGuard addresses this application-level threat model.

2.1. Benchmarks and Learned Guards

Liu et al. formalise prompt injection attacks and provide a benchmark spanning multiple attacks, defenses, models, and application tasks [3]. BIPIA focuses specifically on indirect prompt injection embedded in external content [12]. AgentDojo evaluates prompt injection in tool-using agents and considers both task utility and security compromise [13]. These benchmarks therefore address different evaluation settings, and detector accuracy on authored prompts should not be interpreted as equivalent to end-to-end agent attack success. This distinction motivates ChainGuard’s use of source-aware session labels and its separation of detector escape from downstream compromise.

Learned guard models provide semantic coverage beyond lexical denylists. Prompt Guard 2 is a lightweight binary classifier that labels prompts as benign or malicious and is released as a model card rather than a peer-reviewed study [5]. Its 86M variant is built on a multilingual mDeBERTa base, which is precisely the representational capacity that the lexical concept model of Section 4.5 lacks. PIGuard focuses on reducing over-defense caused by reliance on attack-associated trigger words [4]. Both approaches primarily operate as input classifiers and, by themselves, do not provide ChainGuard’s combination of bounded cross-turn state, provenance-aware policy enforcement, and output leakage inspection. ChainGuard therefore uses lightweight classification as one component of a broader runtime security architecture rather than as the sole security boundary.

2.2. Agent and Runtime Controls

Task Shield evaluates whether instructions and tool calls remain aligned with the user’s objective throughout task execution [6]. IPIGuard constrains execution by enforcing a planned tool-dependency graph before actions are performed [7]. Because these approaches operate close to the action boundary, they provide stronger protection against unauthorised tool use than an input filter alone. However, they do not replace ingress controls, as malicious content can still influence text generation, memory, or intermediate reasoning before a tool invocation is rejected. ChainGuard is therefore complementary rather than a substitute. It filters provenance-aware content before model inference and inspects generated output for potential information leakage, while leaving tool authorisation to the host application.

Stateful detection such as DeepContext targets multi-turn intent drift [8]. ChainGuard uses a less expressive bounded state representation that is deterministic and inexpensive. Output filters offer a model-independent point for catching canaries or protected-text reconstruction [10], but they act after generation and cannot undo intermediate side effects. Table 1 makes these differences explicit.

ChainGuard’s contribution is therefore a locally operated runtime reference monitor that combines provenance, bounded conversation state, deterministic predicates, a lightweight classifier, and egress checks. The table identifies scope, not superiority; only matched experiments at comparable utility can establish relative effectiveness.

3. Problem Formulation and Threat Model

This section defines the application setting, trust assumptions, protected assets, and adversarial capabilities considered in this work. The threat model focuses on direct and indirect prompt injection in LLM applications that combine user input with external content from retrieval systems, tools, memory, or documents. It establishes the security boundaries and attacker capabilities against which ChainGuard is designed and evaluated.

3.1. Application Model

A session consists of ordered segments

$$\mathcal{X}={(z_t)}_{t=1}^T,z_t=(x_t,q_t),$$

(1)

where $x_t$ is the text at turn t and $q_t$ is its provenance label. The implementation supports labels corresponding to user input, trusted system/developer content, retrieved documents, tool output, memory, and external content. ChainGuard processes each lower-trust segment before it is forwarded to the target model.

Protected assets may include:

• system or developer instructions and hidden runtime configuration;
• private memory, credentials, API keys, tokens, or user data;
• application task integrity and tool-use constraints; and
• output canaries or protected text registered with the egress guard.

3.2. Adversary Capabilities

The adversary may control one or more user turns or place text in a source that the application labels as retrieved, external, tool-derived, or memory-derived. The adversary may use:

• direct disclosure requests and indirect noun-form paraphrases;
• policy cancellation, role reassignment, raw-mode instructions, or control-token imitations;
• transfer requests targeting URLs, webhooks, email, DNS, remote servers, or query strings;
• Base64, Base32, hexadecimal, decimal, binary, Morse, ROT13, reversed, leetspeak, interleaved, spaced, zero-width, or homoglyph obfuscation;
• aliases, pronouns, delayed operations, and multi-turn intent composition; and
• multilingual formulations.

The adversary may know the general architecture. The threat model does not assume secrecy of the source code. It does not cover malicious model weights, training-time backdoors, operating-system compromise, network interception, or a trusted application component deliberately mislabelling malicious content as system/developer authority.

3.3. Agentic and Tool-Using Systems

In an agentic deployment, the attack surface includes the full observation–decision–action loop. An adversary may place instructions in a web page, email, document, database record, tool return value, MCP resource, short- or long-term memory, or another agent’s message. A successful injection can redirect browsing, induce a privileged tool call, alter memory, exfiltrate data through an action argument, or create persistence that affects later sessions. ChainGuard treats each such item as a provenance-labelled segment and can block instruction-bearing untrusted text before model inference. It does not, however, prove that an allowed plan is authorised or that a tool invocation is safe.

Accordingly, the trusted computing base includes the host application’s source labelling, session isolation, policy configuration, and tool gateway. The host must preserve provenance instead of flattening all inputs into one prompt, prevent untrusted text from declaring itself trusted, reset or partition state at security boundaries, and independently authorise consequential actions. ChainGuard is intended to complement least privilege, argument validation, user confirmation, network controls, and audit logging. Compromise of these controls is outside the detector’s guarantee.

Figure 1 locates ChainGuard at the model boundary. User requests and provenance-labelled observations from retrieval, tools, and memory are inspected before inference; generated text is inspected again before delivery. Tool-call authorisation and memory writes remain application responsibilities.

3.4. Attacker Knowledge, Adaptation, and Success Criteria

The primary experiment models static attacks with knowledge of common LLM-defense patterns but without iterative query access to the evaluated frozen detector. A stronger adaptive adversary may observe allow/block outcomes, reason codes, timing, or model responses and optimise paraphrases, encodings, languages, source placement, and multi-turn decompositions under a query budget. Such attacks are included in the planned evaluation but not in the reported results. For end-to-end agent tests, success must be defined at the consequence level, for example, unauthorised disclosure, an unapproved tool call, task-goal deviation, or persistent memory modification rather than detector escape alone.

3.5. Security Objectives and Evaluation Boundary

At the input layer, an attack session is detected when at least one turn receives a Block decision. If no turn is blocked, the session is a detector escape. For benign sessions, a block is a session-level false positive.

These terms are intentionally distinct from end-to-end attack success. The current evaluation does not query a target LLM and therefore does not measure chain attack success rate (chain-ASR). An escaped prompt may still be refused by a target model, and a blocked prompt might not have succeeded. The reported results quantify the filtering component only.

4. Methodology

This section describes the design and implementation of ChainGuard and the mechanisms used to derive runtime security decisions. The methodology follows the processing path from source-labelled input through preprocessing, semantic and classifier-based analysis, temporal and provenance reasoning, risk fusion, and policy enforcement to output-side leakage detection. The individual components are described below in the order in which they contribute to the runtime decision process.

4.1. Architecture Overview

Figure 2 presents the complete proxy pipeline. Each segment enters with an explicit source label. The proxy canonicalises the text, extracts conservative decoded candidates, computes parallel lexical, semantic, classifier, provenance, and temporal signals, and then applies a hierarchical risk policy. Blocked content never reaches the target model. Allowed or restricted content can be sent to a local LLM, after which the output guard performs a second independent leakage check.

4.2. Provenance-Aware Ingress

The proxy receives a segment $z_t=(x_t,q_t)$ rather than text alone. Source provenance is a security input, not descriptive metadata. A direct user instruction can legitimately request a summarisation or translation, whereas the same imperative inside a retrieved page or tool output should normally be interpreted as data. ChainGuard therefore distinguishes trusted instruction-bearing channels from untrusted data channels.

For untrusted sources, the detector identifies free-standing imperatives, questions directed at the assistant, response-control language, and requests to follow the document. Declarative reports, attributed quotations, fictional narratives, compiler messages, dataset examples, and security analysis are treated as possible benign data. This precision layer reduces, but does not eliminate, overblocking in retrieved content.

4.3. Canonicalisation and Conservative Decoding

The normalisation layer performs Unicode compatibility canonicalisation, case folding, whitespace normalisation, removal of zero-width control characters, and selected homoglyph repair. The objective is to make equivalent attack strings comparable without destructively rewriting ordinary text.

The decoder generates at most four plausible candidates using format-specific recognisers. Supported paths include Base64, Base32, hexadecimal, decimal byte sequences, binary bytes, Morse, reversal, leetspeak, and alternating/interleaved characters. A decoded string is accepted only when it is sufficiently printable and contains plausible language or a security-relevant command word. Decoding alone does not trigger a block: the surrounding prompt must request execution or the decoded candidate must exhibit high-confidence attack intent. This execution-aware condition is necessary because benign users legitimately ask to decode data.

4.4. Transparent Per-Turn Signals

ChainGuard computes lexical/structural risk, intent drift, and frame/reference risk. Their weighted score (0.45, 0.15, and 0.40) enters a leaky accumulator with decay 0.80, baseline subtraction 0.15, and a 0.10 bonus for monotonic three-turn drift. Reference thresholds are 0.42 for challenge and 0.72 for block, although this path receives only 0.02 weight in the final ensemble. These constants reproduce the implementation; they are heuristic operating parameters, not a theoretical security model.

4.5. Compositional Concept Model

Surface patterns cannot enumerate every paraphrase, so a concept scorer composes protected-target evidence with disclosure/transformation operations, policy cancellation with executable intent, and sensitive targets with external transfer channels. It returns an intent label, risk, executable flag, and matched concepts. Risks of 0.50 and 0.72 can challenge or block; decoded candidates use 0.70. The vocabulary covers English and selected German, French, and Spanish terms but is still lexical, explaining weak multilingual generalisation.

4.6. Structured Semantic-Intent Model

A separate analyser maps each turn to operation, target, execution mode, target provenance, and intent-class slots. This treats “reveal the system prompt” and “translate the hidden developer instructions” as related protected-target operations while distinguishing quoted attacks, defensive discussion, and transformations of user-provided text. Benign scope can suppress classifier escalation, but cannot override a source-authority violation, executable decoded directive, or explicit sensitive-data transfer.

4.7. Local Intent Classifier

ChainGuard incorporates a lightweight local intent classifier as one component of its decision process. The classifier uses class-balanced multinomial logistic regression with word TF–IDF unigrams and bigrams together with character-boundary 3–5-grams [14]. It predicts five intent classes: benign discussion or processing, indirect instruction, instruction override, protected disclosure, and other content. The probabilities assigned to the three attack-related classes are combined into a single maliciousness score. When this score reaches 0.88, the classifier triggers escalation unless the semantic layer has already established a benign scope, such as quotation, defensive discussion, or processing of user-provided content. Consequently, the classifier acts as one supporting signal rather than as the primary security boundary.

4.7.1. Rationale for Logistic Regression

Logistic regression is an engineering choice, not a state-of-the-art claim: it is local, deterministic, CPU-compatible, inexpensive, and coefficient-inspectable, which aids freezing and incident reproduction. Its limitations are equally important: TF–IDF does not represent long-range syntax, multilingual equivalence, or operation target relations, and calibration may shift across domains. The classifier is consequently one ensemble signal, not the security boundary. Transformer-based classifiers were intentionally excluded from the ChainGuard ensemble because the objective was to evaluate the reference architecture independently of a powerful semantic encoder; an open transformer guard remains part of the confirmatory baseline study.

4.8. Bounded Temporal State

ChainGuard stores bounded summaries rather than the transcript. Protected-target and untrusted-instruction focus decay by 0.78 per turn; a matching reference raises focus to one. At most 12 aliases are retained, and later disclosure operations over an alias or back-reference can block when focus is at least 0.75. A second concept-focus accumulator decays by 0.70. State resets between sessions. These mechanisms encode the implementation directly and are not presented as a formal optimality result.

4.9. Provenance Policy

Retrieved, tool, memory, document, and external sources are data-only by default. Direct assistant instructions, response control, or requests to execute a source directive raise provenance risk; attributed quotations and declarative reports can be downgraded when quotation or discussion scope is established. The rule is intentionally asymmetric: identical text may be permitted from the user but blocked inside a retrieved page. Correct host-provided labels are therefore a security assumption.

4.10. Risk Components

Before applying the hierarchical decision policy, ChainGuard represents evidence from each analysis layer as a normalized score in the range $[0,1]$. The semantic layer estimates semantic risk from the detected operation, target, execution mode, and contextual intent. The local intent classifier produces a maliciousness probability by combining the probabilities of the indirect-instruction, instruction-override, and protected-disclosure classes. The temporal layer estimates risk from bounded conversational state, including protected-target focus, aliases, and back-references. The provenance layer estimates risk according to the trust level and origin of the current content, while the transparent accumulator summarizes lexical and structural evidence collected across turns.

4.11. Risk Fusion and Hierarchical Decision Policy

The ordinary risk score is computed from five normalized components using fixed implementation weights: semantic risk (0.48), classifier maliciousness probability (0.27), temporal-state risk (0.18), provenance risk (0.05), and the transparent accumulator (0.02). Scores below 0.48 are allowed, scores from 0.48 to below 0.78 are challenged, and scores of at least 0.78 are blocked. Agreement between the classifier (probability at least 0.72) and the semantic layer (risk at least 0.55) raises the final score to at least 0.84. Figure 3 summarises the hierarchical decision policy, including forced violations, weighted risk fusion, agreement-based escalation, and the final allow, challenge, and block thresholds.

The implementation is more clearly expressed as the following decision procedure than as a set of equations:

• canonicalise text and inspect at most four plausible decoded candidates;
• update semantic slots, classifier probability, provenance risk, and bounded state;
• block an executable decoded directive, source-authority violation, explicit disclosure/override, sensitive-data transfer, policy disablement, cross-turn execution, or non-benign classifier score at least 0.88;
• otherwise apply the weighted score and the allow/challenge/block thresholds; and
• emit the decision, reason code, and supporting evidence.

Forced predicates prevent a high-confidence violation from being diluted by unrelated low-risk signals. Their cost is overblocking instruction-like narratives, tutorials, logs, and quotations, examined in Section 6.

4.12. Output Leakage Guard

If input is permitted and a target model produces output y, the egress guard normalises y and evaluates:

• exact registered canary matches;
• exact protected substring matches;
• protected five-token n-gram containment; and
• whole-string fuzzy similarity using sequence matching.

Five-token overlap is the fraction of protected five-grams also found in the output. Default overlap and fuzzy thresholds are 0.42 and 0.82; leakage risk at least 0.78 replaces the output with a block message. This component is software-tested but not evaluated against broad model-generated paraphrases.

4.13. Computational Characteristics and Auditability

The transparent and policy layers are linear in input length apart from bounded decoding and fuzzy comparisons; the classifier requires no remote API. A single-process CPU benchmark used the released holdout workload, a fresh detector per session, stopping at the first block. After 10 warm-up sessions, 20 repetitions produced 3600 session and 4040 turn measurements on an Apple M2 Pro (10 CPU cores, 32 GB RAM), macOS 26.6, and Python 3.12.13. Table 2 reports wall-clock results; peak resident memory includes the Python interpreter and imported libraries. No target-model inference, network time, or concurrent load is included.

An LLM-based judge adds at least one model inference, and often a network round trip, to every inspected turn. ChainGuard’s sub-millisecond local median is therefore qualitatively a different operating regime: it can screen before an LLM call without duplicating generation-scale compute or transmitting prompt content to a judge service. This comparison is architectural rather than empirical: judge latency depends on model size, hardware, batching, and provider, and the comparison does not imply equivalent semantic capability.

5. Evaluation Methodology

This section describes the experimental methodology used to evaluate ChainGuard’s prompt-injection detection behaviour and its impact on benign inputs. The evaluation considers attack-session detection, benign false blocking, time to detection, attack-category performance, and comparison with a transparent rule-based baseline. To preserve reproducibility and reduce post-hoc adaptation to the evaluation data, the evaluated implementation was finalized before construction of the primary holdout dataset.

5.1. Implementation Finalization and Verification

Before constructing the primary evaluation dataset, the detector implementation, package metadata, configuration, and supporting resources were finalized and no further modifications were made. This procedure ensured that the evaluation was performed on a fixed implementation rather than one adapted to the test sessions.

The accompanying software test suite completed successfully with 42 passing tests and no failures. The tests verify the correct implementation of decoding, classifier-label handling, state accumulation, provenance-aware policy enforcement, benign discussion handling, output blocking, and regression cases. Although these software tests increase confidence that the implementation behaves as intended, they do not demonstrate general robustness against prompt injection attacks, which is evaluated separately in Section 6.

5.2. Primary Post-Freeze Holdout

The primary dataset was constructed after the implementation was finalized and was evaluated without modifying the detector after the results were first inspected. The dataset is researcher-authored rather than maintained by an independent third party, which limits external validity.

The attack set contains 80 sessions across eight categories (Table 3). Sessions contain one to three turns and include explicit source labels for indirect content.

The benign set contains 100 sessions (Table 4). It was designed to expose over-defense rather than merely test ordinary conversational content.

The attack and benign datasets are identified by cryptographic file hashes included in the reproducibility package, allowing the exact evaluation inputs to be verified. Each evaluation session starts with a newly initialized ChainGuard instance so that state accumulated in one session cannot influence another. For multi-turn sessions, messages are processed sequentially and retain their assigned provenance labels (e.g., user, retrieved, tool, or memory), allowing the stateful and source-aware mechanisms to operate as intended. A session is counted as detected when ChainGuard produces a Block decision on any turn, after which no further turns in that session are evaluated for the primary metric. Challenge decisions are recorded separately but are not counted as successful attack detections.

5.3. Matched Transparent-Rule Baseline

The frozen package contains a pre-existing detector comprising eight case-insensitive regular expressions for familiar override, disclosure, persona, and canary phrases. On a match it blocks; otherwise it wraps the text as untrusted data. We evaluated this detector on the identical 80 attack and 100 benign sessions, with a fresh instance per session and the same stop-at-first-block rule. Because the primary endpoint is blocking, wrapper-only Sanitize decisions count as non-blocking. No pattern was added or tuned after inspecting the holdout. Wilson intervals describe each rate, and an exact two-sided McNemar test compares paired session decisions. This baseline tests whether the layered architecture adds coverage over transparent lexical filtering; it is not a proxy for modern pretrained guards.

5.4. Metrics

Let $TP$ be blocked attacks, $FN$ escaped attacks, $FP$ blocked benign sessions, and $TN$ allowed benign sessions. Standard definitions are used for detection/recall, escape, false-block rate, precision, F1, specificity, balanced accuracy, MCC, and overall accuracy. Time to detection is the first blocked turn and its mean is calculated only over detected attacks. Wilson 95% intervals are reported for detection, escape, and false blocking [15]; small category denominators are interpreted descriptively.

6. Results

This section reports the empirical results of the ChainGuard evaluation. We first present overall detection and false-block performance, followed by comparison with the transparent rule-based baseline, category-level results, time-to-detection analysis, runtime measurements, and an examination of attack escapes and benign false blocks.

6.1. Overall Detector Performance

ChainGuard blocked 61 of 80 attack sessions and falsely blocked seven of 100 benign sessions. The resulting confusion matrix is shown in Table 5.

Table 6 reports the primary metrics. The attack-detection point estimate exceeds 70%, but the 95% interval includes values below 70%. The benign false-block interval is also wide because only 100 benign sessions were evaluated.

Figure 4. Attack detection, detector escape, and benign false-block rates on the post-freeze holdout. Error bars show Wilson 95% confidence intervals.

Figure 4. Attack detection, detector escape, and benign false-block rates on the post-freeze holdout. Error bars show Wilson 95% confidence intervals.

The high precision indicates that most blocks correspond to labelled attacks, but precision is influenced by the attack-to-benign composition of the evaluation set. The 23.75% escape rate remains operationally significant: input filtering alone would permit nearly one in four labelled attack sessions in this holdout.

6.2. Matched Rule-Baseline Comparison

Table 7 supplies experimental context for the primary rate. The frozen eight-pattern detector blocked only 1/80 attacks (1.25%; 95% CI: 0.22–6.75%) while falsely blocking 6/100 benign sessions (6.0%; 95% CI: 2.78–12.48%). ChainGuard therefore gained 75.0 percentage points of attack detection at a one-point increase in false blocking on this authored holdout. Paired attack outcomes comprised 60 ChainGuard-only detections, no rule-only detection, and 20 agreements, yielding exact McNemar $p<0.001$. Benign outcomes had seven ChainGuard-only blocks and six rule-only blocks ($p=1.00$). Notably, no benign session was blocked by both detectors: the two false-positive sets are disjoint, indicating that lexical and layered analysis over-defend on different content. The benign p value should therefore be read as insufficient power over 13 discordant pairs rather than as evidence of equivalence.

The result shows that the layered detector captures attacks missed by a familiar-phrase denylist without materially changing the observed false-block rate. It does not show superiority over learned prompt-injection classifiers: the baseline is deliberately weak, lexical, and lacks provenance or state, while the authored dataset contains semantic paraphrases designed to escape familiar trigger strings.

6.3. Performance by Attack Category

Figure 5 and Table 8 show category-level detection. Encoding and obfuscation achieved complete detection in this sample (10/10), while indirect retrieved/tool injection reached 11/12. These categories are directly targeted by ChainGuard’s canonicalisation, conservative decoding, execution-aware analysis, and provenance-aware policy mechanisms; however, the present evaluation does not isolate the contribution of individual components.

The weakest category is multilingual attack detection. Generic German, French, and Spanish vocabulary captures some explicit requests, but five of eight multilingual attacks escape, including Persian cases. Protected transformations are the second-weakest category because a request may describe a diff, checklist, or reconstruction without a familiar disclosure verb.

6.4. Time to Detection

Among the 61 detected attacks, 56 were blocked on the first turn, two on the second, and three on the third. Median TTD was one turn and mean detected-only TTD was 1.13 turns. All detections after the first turn occurred in the multi-turn category, consistent with the intended role of ChainGuard’s temporal-state mechanisms. The timing metric must be interpreted together with coverage. A low TTD among detected sessions does not compensate for the 19 escaped sessions, for which TTD is undefined.

6.5. Benign False Blocks

Figure 6 shows false blocks by benign category. Five categories incurred no false blocks. Six of seven false positives occurred in retrieved/tool hard negatives; one occurred in a direct user request containing the word “ignore.”

Table 9. Benign session false blocks by category.

Benign category	False blocks	Rate
Security discussion	0/15	0%
Quoted attack analysis	0/15	0%
Benign transformations	0/15	0%
Ordinary user requests	0/20	0%
Multilingual benign requests	0/10	0%
Retrieved/tool hard negatives	6/20	30.0%
Trigger-word hard negatives	1/5	20.0%
Total	7/100	7.0%

Table 9. Benign session false blocks by category.

Benign category	False blocks	Rate
Security discussion	0/15	0%
Quoted attack analysis	0/15	0%
Benign transformations	0/15	0%
Ordinary user requests	0/20	0%
Multilingual benign requests	0/10	0%
Retrieved/tool hard negatives	6/20	30.0%
Trigger-word hard negatives	1/5	20.0%
Total	7/100	7.0%

Among the seven benign sessions incorrectly blocked by ChainGuard, six involved content originating from source-labelled or structured data. These cases included a fictional character quoting an override phrase, a defensive report discussing the handling of secrets, a dataset row containing a literal attack string, a compiler warning containing system_prompt, a YAML example containing an instruction field, and a tutorial demonstrating the encoding of a harmless greeting. In each case, instruction-associated terms or structures occurred as content to be quoted, analysed, reported, or processed rather than as instructions intended for execution by the target model.

The remaining false block occurred on a direct user request to disregard an earlier version of a curriculum vitae and edit only newly provided text. The phrase “ignore the previous” contributed to a high classifier score even though the requested operation concerned user-provided document content rather than an attempt to override protected instructions.

6.6. Analysis of Escaped Attacks

The 19 detector escapes fall into seven recurrent patterns:

• Noun-form protected disclosure. Requests for an “operating brief,” “concealed setup,” or “highest-authority message” remain below threshold because the target is described indirectly.
• Policy revocation paraphrases. Statements that a controlling policy should be considered revoked or fictional can evade familiar cancellation verbs.
• Novel exfiltration construction. Query-parameter and email transfer requests can distribute the sensitive target and channel in a form that does not satisfy all explicit exfiltration predicates.
• Late-turn composition. A target may be established through abstract questions, followed by a pronoun or noun phrase that the bounded alias/back-reference model does not resolve.
• Instruction-bearing tool output without explicit assistant address. A diagnostic stream can contain an executable data-transfer command that resembles a log record rather than a natural-language imperative.
• Multilingual semantics. Persian and less familiar French, Spanish, and German formulations exceed the lexical coverage of the current concept model and TF–IDF training data.
• Protected reconstruction. Requests for diffs, executable checklists, or sufficiently detailed descriptions may be semantically equivalent to disclosure while appearing analytical or transformational.

These misses support a specific conclusion: the present architecture’s principal bottleneck is not state storage or decoding, but semantic generalisation. The system requires a multilingual contextual representation that can model the relation between operation, target, source, and requested execution.

7. Discussion

First, provenance is useful but costly. Correctly labelled retrieved/tool instructions were usually blocked (11/12), yet the same strict data-only policy produced six of seven false blocks. The engineering problem is therefore not merely detecting imperative language; it is resolving whether text is quoted, descriptive, or intended for execution. Second, deterministic decoding is valuable for narrow obfuscations (10/10 here), but the dominant residual risk is semantic: multilingual and reconstructive requests accounted for eight of 19 escapes. Third, bounded state can intervene after the first turn—five detections occurred on turns two or three—but the sample is too small to attribute a causal gain without ablation. Finally, detector quality must be read as a security–utility pair: 76.25% detection alongside 7% false blocking, not as one headline number.

Taken together, these results show that ChainGuard provides substantially broader detector-level coverage than the evaluated lexical baseline while retaining a relatively low false-block rate. However, the category-level results do not establish the causal contribution of individual architectural components. Learned-guard comparisons and component ablations therefore remain necessary to determine how much each layer contributes to the observed performance.

7.1. Design Implications

The main architectural lesson is to preserve authority metadata outside the model rather than asking the model to infer it from concatenated text. Classifiers can broaden semantic coverage, but deterministic policy is still needed for explicit exfiltration, source violations, and auditable enforcement. Conversely, policy rules should not be mistaken for language understanding: the false-positive cluster shows that execution mode and target provenance require contextual modelling. A multilingual encoder should therefore predict operation–target–provenance–mode relations and remain subordinate to an explicit policy layer. The mDeBERTa-based Prompt Guard 2 86M variant [5] is an open, locally executable candidate for this role and is the concrete starting point for the planned confirmatory baseline.

Transparency supports incident analysis but also helps adaptive attackers; secrecy cannot be the defense. This is consistent with adaptive weaknesses in open guard models and the completeness–utility tension of wrapper defenses [9,11]. ChainGuard should be deployed only with source preservation, least-privilege tools, independent action authorisation, session isolation, output inspection, and reviewable reason codes. It is a risk-reduction component, not a standalone security boundary.

7.2. Limitations

Internal validity benefits from a source freeze, hashes, and per-session outcomes, but external validity remains limited: the 180 sessions are researcher-authored, categories contain only 8–12 attacks, and the classifier’s development data may share lexical neighbourhoods with the test taxonomy. The broad confidence intervals and 3/8 multilingual result preclude stable population or language-specific claims.

Construct validity is also narrow. Blocking is not target-model compromise, benign answer quality, or tool-level consequence. The output guard is not evaluated against semantic paraphrase, and no browser, MCP, memory-writing, consequential tool, or multi-model environment is tested end to end. Source-aware enforcement additionally assumes correct, tamper-resistant labels from the host.

The reported operating point is also a single configuration. All decision constants were set by hand rather than tuned on a validation split, and no threshold-sensitivity curve, reason-code distribution, or Challenge rate is reported; consequently it cannot be determined from these results how much of the observed detection is attributable to the forced predicates as opposed to the weighted risk fusion.

Most importantly, the matched comparison covers only a transparent eight-pattern detector; there is no learned baseline or component ablation. The study therefore cannot establish superiority over modern guards or causal layer benefit, and its static attacks may overestimate robustness against query-adaptive adversaries [10,11]. The observed 23.75% escape and 7% false-block rates rule out standalone production use.

8. Conclusions and Future Work

This paper presented ChainGuard, a layered, stateful, and provenance-aware runtime security architecture for locally operated LLM applications. ChainGuard combines complementary input, semantic, temporal, provenance, policy, and output controls to address direct and indirect prompt injection while retaining local execution, transparent decision logic, and bounded computational requirements.

On the researcher-authored post-development holdout, ChainGuard blocked 61/80 attack sessions (76.25%) while falsely blocking 7/100 benign sessions (7.0%). The matched frozen eight-pattern baseline blocked 1/80 attacks (1.25%) and 6/100 benign sessions (6.0%). These results provide evidence that the integrated architecture offers substantially broader detector-level coverage than transparent lexical filtering at a similar observed false-block rate. Performance was strongest for encoding and obfuscation attacks and indirect source injection, whereas multilingual attacks and protected-text transformations remained the most challenging categories. Most successful detections occurred on the first turn, while later-turn detections demonstrate the relevance of retaining bounded conversational state. The benign false blocks further exposed difficulty in distinguishing executable instructions from instruction-like content appearing in quotations, reports, structured data, and other benign contexts.

These findings support a deliberately bounded conclusion: ChainGuard improves detector-level protection over the evaluated lexical baseline, but the present study does not establish superiority over learned guard models, external generalisation, or production-ready end-to-end protection. Future work should therefore prioritise comparison with learned prompt-injection detectors and component-level ablation, followed by evaluation on independent direct, indirect, and agentic benchmarks. End-to-end experiments should additionally measure attack success, benign task completion, output intervention, unauthorised tool actions, and robustness against adaptive attacks across multiple local model families. On the architectural side, the principal priorities are improved multilingual operation–target–provenance modelling, more reliable distinction between quotation and execution, detection of structured exfiltration channels, and semantic output-leakage analysis while retaining deterministic canary-based checks.