SafeEnd: End-Stage Safety Mechanisms

• SafeEnd is a design orientation that enforces security guarantees at the final stage of processing across multiple domains.
• It spans applications in computer architectures, LLM fine-tuning defenses, post-generation filtering, and supervisory control to mitigate risks.
• Practical insights include formal noninterference proofs, robust mitigation of harmful outputs, and quantifiable safe horizons under worst-case disturbances.

SafeEnd is a term used in several technically distinct research contexts to denote either an end-to-end security guarantee or a safety mechanism placed at the final stage of a computational pipeline. In computer architecture, it denotes the machine-checked propagation of noninterference from an information-flow abstract machine to a concrete tagged machine in SAFE. In recent large-language-model work, it denotes output-layer anchoring against harmful fine-tuning, post-generation output filtering, or an inference-time corrective demonstration appended to adversarial prompts. In supervisory control, it is used to express the maximal guaranteed time before a safety violation when robust invariance is infeasible (Amorim et al., 2015, Lu et al., 7 May 2026, Arazzi et al., 23 Mar 2026, Chen et al., 8 May 2026, Li et al., 2023). This suggests a recurring research motif: concentrate safety enforcement at the “end” of execution, generation, or admissible evolution, while leaving earlier stages relatively unconstrained.

1. Scope and nomenclature

The term is not a single standardized algorithm. Rather, it is reused across several literatures to identify distinct mechanisms with different objects of protection, threat models, and guarantees.

Context	SafeEnd meaning	Primary objective
SAFE tagged architecture	End-to-end noninterference result	Transfer TINI from abstract IFC to concrete machine
Harmful fine-tuning defense	Output-layer anchoring via SBR	Keep harmful responses suppressed under persistent HFT
SecureBreak deployment pipeline	End-of-pipeline safety filter	Block unsafe outputs and quantify residual failures
Many-shot jailbreak defense	One-shot appended safety demonstration	Counteract implicit malicious fine-tuning at inference
Supervisory control	Time-to-violation extension notion	Keep system safe indefinitely when possible, otherwise maximize safe horizon

A plausible implication is that “SafeEnd” functions more as a design orientation than as a fixed formalism. In some usages it refers to a proof endpoint, in others to a geometric bottleneck, a deployment gate, a final contextual intervention, or a terminal safe horizon.

2. SafeEnd in the SAFE tagged architecture

In the SAFE architecture, SafeEnd is the end-to-end noninterference result for a clean-slate, tag-based information-flow architecture (Amorim et al., 2015). SAFE uses tag-per-word hardware: every word in registers, memory, and the program counter carries a tag, and the full system uses 59-bit tags. On each instruction dispatch, the hardware forms a tuple from the opcode, the PC tag, and operand tags, and computes a new PC tag and a result tag. The hardware is policy-agnostic. It caches rule instances, and on a cache miss it traps to a kernel-mode fault handler that decides whether the operation is allowed and which output tags should be installed in the cache.

At the abstract level, the operating system virtualizes this tagged substrate into an information-flow abstract machine. Programs manipulate atoms of the form $n@L$, where $L$ ranges over a lattice $(\mathcal{L}, \le, \sqcup, \bot)$. The model is parametric in the lattice: the paper uses a two-point lattice $\{L,H\}$ and also an extension where labels are sets of principals with $\sqcup = \cup$ and $\le = \subseteq$. Dynamic IFC is hard-wired into instruction semantics. For example, Add joins operand labels, Load joins the pointer and loaded value labels, Store enforces a no-sensitive-upgrade condition $(L_1 \sqcup L_{pc}) \le L_3$, and Jump or Bnz raise the PC label to track implicit flows. Output emits $m@(L \sqcup L_{pc})$, so output observability depends jointly on data and control context.

The verified development factors these IFC rules through an intermediate symbolic rule machine. In that machine, a rule table $\mathcal{R}$ maps each opcode to $\langle \textit{allow}, e_{rpc}, e_r \rangle$, where allow is a Boolean expression over labels and $L$0 are label expressions in a small DSL. Selected entries are:

• Rule(add) = ⟨TRUE, LAB_pc, LAB_1 ⊔ LAB_2⟩
• Rule(store) = ⟨(LAB_1 ⊔ LAB_pc) ⊑ LAB_3, LAB_pc, LAB_1 ⊔ LAB_2 ⊔ LAB_pc⟩
• Rule(ret) = ⟨TRUE, LAB_2, _⟩

The concrete tagged machine has user mode and kernel mode, separate instruction and data memories, and a one-entry cache model stored in kernel memory. On a cache hit, the user instruction executes directly with cached output tags. On a miss, the machine records the input tuple in the cache frame, clears outputs to the default tag $L$1, pushes a return frame, switches to kernel mode, and enters the fault handler. The handler computes allow, $L$2, and $L$3 according to $L$4 and the concrete lattice encoding; if the operation is allowed, it writes those tags into the cache outputs and returns to user mode, otherwise it halts by jumping to $L$5.

The central security property is termination-insensitive noninterference (TINI). For observer $L$6, event observability is defined by filter_o(n@L) iff $L$7, while filter_o(\tau)=false. TINI states that if two low-equivalent inputs are executed, then the filtered traces of observable events are indistinguishable up to truncation to the shorter length. The abstract IFC machine satisfies TINI by an unwinding argument. The proof depends critically on the fact that Output raises the output label by $L$8, ensuring that low outputs can arise only from low contexts.

SafeEnd is obtained by refinement. The paper defines state, event, and input relations between the abstract or symbolic machine and the concrete tagged machine; proves simulation lemmas for non-faulting steps and faulting steps that run the handler to completion; proves refinement in both directions; and then applies a TINI-preservation theorem for refinement. The fault handler itself is generated from the rule table and verified using a dedicated Hoare logic with self-contained and escaping triples. The result is a machine-checked proof that the concrete machine with the generated handler preserves the abstract machine’s TINI.

The model is deliberately restricted. It is single-threaded and deterministic; timing and termination covert channels are out of scope; the verified cache has one entry although the full SAFE system uses a near-associative hardware cache with thousands of entries; and the richer memory-safety mechanisms of full SAFE are simplified in the proof model. Within those assumptions, SafeEnd is a strong end-to-end IFC theorem rather than a heuristic taint-tracking argument.

3. SafeEnd as output-layer anchoring against harmful fine-tuning

In recent LLM safety work, SafeEnd denotes an output-layer defense against Harmful Fine-tuning (HFT), implemented as Safety Bottleneck Regularization (SBR) (Lu et al., 7 May 2026). The threat model is Fine-tuning-as-a-Service: an attacker fine-tunes a safety-aligned base model on a mixed dataset containing benign instructions and harmful demonstrations, optimizing standard cross-entropy to restore harmful capabilities. The paper’s core claim is that standard defenses fail under persistent HFT because the optimizer exploits orthogonal directions in a highly redundant parameter space. Parameter constraints, gradient constraints, and representation-drift constraints can all be bypassed when training continues long enough.

The proposed intervention moves from parameter space to the unembedding layer, treated as a geometric bottleneck. In a Transformer LLM, the logits are

$L$9

and the pre-softmax score of token $(\mathcal{L}, \le, \sqcup, \bot)$0 is

$(\mathcal{L}, \le, \sqcup, \bot)$1

Because token generation depends on geometric alignment between $(\mathcal{L}, \le, \sqcup, \bot)$2 and vocabulary embeddings, the defense anchors the final hidden states of high-risk queries to those produced by a frozen safety-aligned reference model. For anchor prompts $(\mathcal{L}, \le, \sqcup, \bot)$3, the cached reference states are

$(\mathcal{L}, \le, \sqcup, \bot)$4

During fine-tuning, the safety loss is

$(\mathcal{L}, \le, \sqcup, \bot)$5

and the total objective is

$(\mathcal{L}, \le, \sqcup, \bot)$6

The procedure is two-phase. First, the service provider performs offline anchor acquisition by running the frozen base model on a fixed set of high-risk anchor prompts and caching their final hidden states. Second, during fine-tuning, each attacker batch is augmented with the SafeEnd regularizer computed on the fixed anchors. The paper states that this can be injected without accessing the private training data content, since $(\mathcal{L}, \le, \sqcup, \bot)$7 depends only on the anchor set.

The empirical case for this SafeEnd variant is built around Harmful Score (HS), defined as the percentage of responses classified “harmful” by the BeaverTails moderation model over 1,000 unseen malicious queries, and Functional Accuracy (FA) on benign tasks. Under HFT, standard supervised fine-tuning collapses to average HS $(\mathcal{L}, \le, \sqcup, \bot)$8. SBR reduces HS to 5.68 on average while preserving competitive FA, including SST-2 94.15, AGNEWS 90.10, GSM8K 82.60, and AlpacaEval 45.82. Under persistent HFT, non-SBR defenses fail within 10 epochs, whereas SBR remains robust across 50 epochs. Across poison ratios $(\mathcal{L}, \le, \sqcup, \bot)$9, SBR maintains HS $\{L,H\}$0 on Llama3.1-8B, Qwen2.5-7B, and Gemma1.1-7B, with average HS 6.35, 6.10, and 7.28 respectively.

Several ablations specify the bottleneck claim. A single anchor reduces HS from 67.8 to approximately 6, while 8 anchors often give the best FA at approximately 1.07× training time. Constraining intermediate layers fails with HS $\{L,H\}$1, whereas constraining the final layer yields a sharp safety drop, exemplified by Layer 32 HS = 5.8. The paper also reports that unseen malicious queries cluster tightly around the refusal anchor in final hidden-state space, with average MSE distance approximately 2.5, while benign queries lie farther away at approximately 6.8. This geometry motivates the claim that refusal-aligned states occupy a local stability field covering diverse unseen attacks.

This SafeEnd should be distinguished from broader alignment training. It relies on an already safety-aligned base model, does not directly address prompt-only jailbreaks, and can trade off utility when $\{L,H\}$2 is too large. The paper identifies $\{L,H\}$3 as a robust range and uses $\{L,H\}$4, LoRA rank 16, alpha 16, AdamW, learning rate $\{L,H\}$5, 20 epochs, batch size 32, and default $\{L,H\}$6.

4. SafeEnd as post-generation filtering with SecureBreak

A third use of SafeEnd is as an end-of-pipeline safety filter for LLM outputs, trained using the SecureBreak dataset (Arazzi et al., 23 Mar 2026). Here the motivation is not internal model robustness but deployment containment: even well-aligned models can emit harmful outputs under jailbreak or prompt-injection conditions, so an independent “ultimate” defense layer is added after generation.

SecureBreak is a response-level dataset of 3,059 instances collected from adversarial jailbreak contexts. Questions come from JailbreakBench, which groups 100 misuse behaviors into 10 policy-aligned categories: Disinformation, Economic harm, Expert advice, Fraud/Deception, Government decision-making, Harassment/Discrimination, Malware/Hacking, Physical harm, Privacy violations, and Sexual/Adult content. The label schema is binary, with Human = 0 for safe and Human = 1 for unsafe, while Category and Behavior retain risk-topic metadata. The class balance is moderately imbalanced, with Safe approximately 60.50% and Unsafe approximately 39.50%.

The dataset’s emphasis is annotation quality. Two knowledgeable annotators labeled each response manually. Borderline cases were adjudicated conservatively to reduce false negatives, and only annotations with high agreement were preserved. The reported average Cohen’s kappa is $\{L,H\}$7. The paper positions this human-only, response-level annotation as a contrast to automated evaluators used in some benchmarks.

Within this framework, SafeEnd is a binary detector of unsafe content from LLM output responses. The input is raw response text, optionally augmented with the source question and conversation context; the output is a probability $\{L,H\}$8 and a binary decision, with optional category logits for policy routing. The paper also recommends using category metadata for multi-task training and category-specific evaluation.

The reported baselines include zero-shot classification by LLM judges and fine-tuned detectors. Without fine-tuning, Mistral-7B-v0.3 achieves 62.84% accuracy, Llama-3.1-8B 61.89%, and Selene-1-Mini-Llama-3.1-8B 57.43%. After QLoRA fine-tuning on SecureBreak, the corresponding accuracies are 83.24%, 81.22%, and 76.08%. A smaller Seq2Seq Qwen 2.5-0.5B classifier reaches 90.14% binary classification accuracy. The paper reports category-wise gains, especially in Fraud/Deception, Privacy, and Disinformation, with improvement also in Expert Advice and Government Decision-Making.

The proposed SafeEnd deployment stack is layered. A fast content classifier produces $\{L,H\}$9 and optionally category probabilities; a category-aware policy engine converts those outputs into block, allow, or route-for-review decisions; a larger QLoRA judge handles gray-zone cases; unsafe outputs can be repaired by refusal-oriented rewriting or regenerated under stricter prompts; and telemetry is logged for alignment retraining. Risk is summarized as

$\sqcup = \cup$0

where $\sqcup = \cup$1 is a category weight reflecting organizational risk tolerance. The paper recommends post-generation filtering by default, with optional mid-generation streaming interception and a complementary pre-filter when prompt analysis is available.

This SafeEnd formulation is explicitly deployment-oriented. It is not a replacement for alignment, and its own limitations are data scale, English-centric coverage, possible overblocking in nuanced expert-advice cases, and the need to refresh the detector as jailbreak styles evolve. Because labels are conservative, threshold tuning and escalation are central to practical use.

5. SafeEnd as a training-free defense against many-shot jailbreaking

In the many-shot jailbreaking literature, SafeEnd is a training-free, black-box-compatible defense that appends a single safety-aligned demonstration to the end of an adversarial context (Chen et al., 8 May 2026). The attack model is long-context prompting: an adversary fills the context window with $\sqcup = \cup$2 harmful question-answer pairs and then issues a target harmful query $\sqcup = \cup$3. Although the base model would refuse $\sqcup = \cup$4 in isolation, compliance increases as $\sqcup = \cup$5 grows.

The paper’s empirical mechanism is progressive activation drift. Let $\sqcup = \cup$6 be the last-layer hidden state of the target query under $\sqcup = \cup$7 harmful demonstrations, and let $\sqcup = \cup$8 be the corresponding state in a safety-aligned context. Drift is measured by

$\sqcup = \cup$9

Both measures grow monotonically and approximately linearly with $\le = \subseteq$0 over the studied ranges. PCA projections show that the representation of the fixed harmful query migrates step by step away from the refusal-aligned region as more harmful demonstrations are added.

The theoretical interpretation is that in-context learning induces SGD-style updates equivalent, to first order, to optimizing on the harmful demonstrations. In that view, many-shot jailbreaking acts as implicit malicious fine-tuning. SafeEnd then injects a countervailing in-context update by appending one fixed safety demonstration $\le = \subseteq$1, where $\le = \subseteq$2 is a representative unsafe request and $\le = \subseteq$3 is a short, policy-grounded refusal. Placement matters: appending the safety demonstration immediately after the target query, as $\le = \subseteq$4, is much more effective than placing it at the beginning or middle of the prompt.

The method requires no parameter access, no gradients, and no hidden-state access at deployment. It changes only the input string. The paper recommends keeping the safety demonstration short, explicit, and authoritative; one example is a request about bypassing system security checks paired with the refusal “Sorry, I can’t help you. Please follow security guidelines.” Multiple safety shots are reported as generally unnecessary.

The reported 32-shot results are strong. On Llama-3.1-8B-Instruct, average attack success rate (ASR) drops from 76.7% without defense to 2.8% with SafeEnd. On Qwen2.5-7B-Instruct, average ASR drops from 45.2% to 1.9%. On strong attacks, HarmBench Crescendo and AdvBench X-teaming fall from 77.0% and 88.0% to 0.0% on Llama-3.1-8B, and also to 0.0% on Qwen2.5-7B. For black-box APIs, GPT-4o’s AdvBench Crescendo and X-teaming results fall from 100.0% and 96.2% to 0.0%, while Gemini 2.5 Pro’s corresponding results fall from 88.9% and 95.7% to 0.0%.

Utility degradation is small. The paper reports, for example, Llama-3.1 average utility 33.9 to 33.6 across GSM8K, MMLU-Pro, GPQA, MT-Bench, AlpacaEval, Loong, and LongBench v2. Over-refusal remains close to the base model: on Llama-3.1 XSTest/OKTest, Base 9.0/8.0% versus SafeEnd 9.2/8.4%. Runtime overhead is also small: under 64-shot adversarial prompts on Llama-3.1-8B, SafeEnd adds approximately 0.05 s inference latency, compared with approximately 0.3 s for ICD, approximately 0.9 s for PPL-Filter, and approximately 7.5 s for Goal Prioritization.

This SafeEnd is specific to many-shot jailbreaks. It presumes a baseline of safety alignment and an identifiable refusal manifold; attackers may still try to manipulate attention or formatting to weaken the safety shot; and the method is complementary to, not a substitute for, broader moderation pipelines.

6. SafeEnd as safety extension in supervisory control

In supervisory control, the “SafeEnd” idea is used to denote the maximal guaranteed time-to-violation when a system can no longer be kept safe indefinitely (Li et al., 2023). The underlying system is discrete-time with disturbances,

$\le = \subseteq$5

where $\le = \subseteq$6, $\le = \subseteq$7, $\le = \subseteq$8, and $\le = \subseteq$9 lies in a known disturbance set $(L_1 \sqcup L_{pc}) \le L_3$0. The desired safe set is $(L_1 \sqcup L_{pc}) \le L_3$1, and robust controlled invariance is encoded by a subset $(L_1 \sqcup L_{pc}) \le L_3$2 such that every state in $(L_1 \sqcup L_{pc}) \le L_3$3 admits an admissible input keeping all successor states inside $(L_1 \sqcup L_{pc}) \le L_3$4.

The paper distinguishes safety protection from safety extension. Safety protection means maintaining the system in $(L_1 \sqcup L_{pc}) \le L_3$5 indefinitely whenever feasible. Safety extension addresses the abnormal regime where invariance is infeasible: the supervisor then computes a control maximizing the number of future time steps before any violation of $(L_1 \sqcup L_{pc}) \le L_3$6. This is formalized through robust $(L_1 \sqcup L_{pc}) \le L_3$7-step safe sets $(L_1 \sqcup L_{pc}) \le L_3$8 and the largest integer $(L_1 \sqcup L_{pc}) \le L_3$9 such that the next state can be driven into $m@(L \sqcup L_{pc})$0. The resulting SafeEnd quantity is

$m@(L \sqcup L_{pc})$1

counting the present and subsequent time instants before the first possible violation under worst-case disturbance.

The contribution is a unified constrained optimization with only continuous variables. At each time step, the supervisor solves a one-shot penalized problem over the control input and a monotone slack sequence $m@(L \sqcup L_{pc})$2. If robust invariance is feasible, the optimizer sets all slacks to zero and reduces to safety protection. If invariance is infeasible, exponentially weighted penalties enforce a lexicographic preference for satisfying as many larger-horizon constraints as possible, thereby maximizing $m@(L \sqcup L_{pc})$3 and thus $m@(L \sqcup L_{pc})$4. For linear systems with convex constraints and a quadratic penalty $m@(L \sqcup L_{pc})$5, the problem becomes a strictly convex quadratic program.

The automotive example is adaptive cruise control with state $m@(L \sqcup L_{pc})$6, sampling time $m@(L \sqcup L_{pc})$7, input set $m@(L \sqcup L_{pc})$8, disturbance set $m@(L \sqcup L_{pc})$9, and safe set

$\mathcal{R}$0

Using $\mathcal{R}$1, $\mathcal{R}$2, and $\mathcal{R}$3, the supervisor exhibits both modes. From $\mathcal{R}$4 under worst-case disturbance $\mathcal{R}$5, protection is feasible and the state remains in $\mathcal{R}$6 indefinitely. From $\mathcal{R}$7, protection is infeasible; the optimal action is maximum braking $\mathcal{R}$8, and the slack variables indicate $\mathcal{R}$9, predicting safety until $\langle \textit{allow}, e_{rpc}, e_r \rangle$0, which the paper states matches analytic calculations. Average QP solve time is 46.5 ms per step, whereas solving the original two-mode series of problems takes 2.18 s, more than 40× slower.

This control-theoretic SafeEnd differs sharply from the LLM and architecture usages. It is neither a final-layer filter nor an output guard. It is instead a real-time safe-horizon maximization principle layered on top of disturbance-robust set invariance.

7. Cross-domain themes, distinctions, and misconceptions

The most important misconception is that SafeEnd names one method. It does not. In the SAFE architecture, it is a machine-checked end-to-end TINI result (Amorim et al., 2015). In harmful fine-tuning defense, it is the anchoring of final hidden states at the unembedding bottleneck (Lu et al., 7 May 2026). In SecureBreak-based deployment, it is a post-generation judge or classifier that blocks unsafe responses (Arazzi et al., 23 Mar 2026). In many-shot jailbreaking, it is a one-shot safety demonstration appended at the end of the prompt (Chen et al., 8 May 2026). In supervisory control, it is the extension horizon $\langle \textit{allow}, e_{rpc}, e_r \rangle$1 obtained when indefinite safety is impossible (Li et al., 2023).

The second misconception is that all SafeEnd variants provide the same kind of guarantee. They do not. The SAFE result is a formal noninterference theorem under a deterministic single-threaded model. SBR reports empirical robustness against persistent HFT, measured by HS and FA. SecureBreak-based SafeEnd reports detector accuracy and category-wise filtering performance. The many-shot SafeEnd reports ASR reduction, utility preservation, over-refusal, and latency. The control variant provides worst-case safe-horizon guarantees under disturbance bounds and model assumptions. The objects being guaranteed are therefore non-comparable without qualification.

A plausible unifying pattern is nonetheless visible. Each usage shifts the safety burden to a terminal locus that is especially decisive for observable harm: the concrete machine boundary in a refinement proof, the final hidden state before unembedding, the output text after generation, the final turn of a long adversarial prompt, or the last guaranteed interval before a state constraint can be violated. In that sense, SafeEnd consistently names mechanisms that either certify or intervene at the point where unsafe effects become externally manifest.

Another common feature is modularity. SAFE decouples hardware from policy through programmable tags and a verified rule compiler. SBR decouples defense from the attacker’s training data by operating on a fixed anchor set. SecureBreak decouples filtering from generation by using a separate classifier or judge. The many-shot defense decouples protection from weight access by using only prompt editing. The control formulation decouples protection and extension by embedding both in one optimization. This suggests that SafeEnd, across domains, is closely associated with late-stage modular safety enforcement rather than early-stage monolithic restriction.

The divergences are equally significant. Some variants are proof-theoretic, some optimization-based, some dataset-driven, and some purely inference-time. Some require trusted hardware or a proof-carrying code generator; others require only a fixed prompt suffix or a small classifier. Some are explicitly low-overhead, while others trade computation for formal assurance. The term therefore identifies a family resemblance, not a unified formal lineage.