OneShield: Unified Safety & Privacy Guardrails
- OneShield is a multi-domain shielding framework that enforces safety, privacy, and compliance by applying context-aware guardrails across MDPs, LLMs, and NLP pipelines.
- It integrates history-aware post-shields, modular detectors, and policy managers to deliver formal probabilistic safety and customizable LLM risk mitigation.
- The framework balances safety and permissiveness through adaptable, context-sensitive interventions tailored to diverse operational constraints.
OneShield is a name used in several recent research contexts to denote shielding or guardrail frameworks that intervene between a system and its environment under explicit safety, privacy, or compliance criteria. In formal methods, it denotes a single unified shielding framework for probabilistic safety in MDPs; in LLM safety, it denotes a stand-alone, model-agnostic and customizable solution to safeguard LLMs; and in privacy-preserving NLP deployment, it denotes a framework that detects, scores, and mitigates privacy risks in user inputs and model outputs (Heck et al., 11 May 2026, DeLuca et al., 25 Jul 2025, Asthana et al., 21 Jan 2025). The shared theme is shielding, but the underlying objects—policies over histories in MDPs, detector-and-policy microservices for LLMs, and privacy guardrails for multilingual data governance—are technically distinct.
1. Scope of the term
The current literature uses OneShield in more than one technical sense. The three most explicit usages are summarized below.
| Usage | Domain | Characterization |
|---|---|---|
| OneShield (Heck et al., 11 May 2026) | Probabilistic safety in MDPs | single unified shielding framework |
| OneShield (DeLuca et al., 25 Jul 2025) | LLM guardrails | stand-alone, model-agnostic, customizable solution |
| OneShield Privacy Guard (Asthana et al., 21 Jan 2025) | LLM privacy governance | privacy-preserving guardrail framework |
This terminological spread matters because the guarantees, interfaces, and evaluation criteria differ sharply. In the MDP setting, OneShield is formalized as a family of history-aware post-shields with explicit safety and permissiveness properties. In the LLM setting, OneShield is an orchestration layer built from detectors, data stores, and a Policy Manager. In privacy-preserving deployment, OneShield is organized around entity recognition, contextual sensitivity scoring, and policy-driven enforcement.
A common misconception is that OneShield denotes one fixed algorithm or one vendor-neutral product category. The literature does not support that reading. One of the formal-methods papers states explicitly that OneShield is not one fixed algorithm, but a family of shield constructions that all fit one formal model (Heck et al., 11 May 2026). Separate LLM papers use the name for guardrail systems with different detector stacks, deployment settings, and operational goals (DeLuca et al., 25 Jul 2025, Asthana et al., 21 Jan 2025).
2. Probabilistic shielding in Markov decision processes
In the paper “Shields to Guarantee Probabilistic Safety in MDPs,” OneShield refers to a single unified shielding framework for probabilistic safety in MDPs. The central shift is from classical qualitative safety—where nothing bad ever happens—to safety specifications of the form
$Pr_M(s_0 \vDash \bad) \le \nu,$
where $\bad \subseteq S$ is the set of bad states and is an acceptable safety threshold (Heck et al., 11 May 2026).
The formal setting is a finite MDP
$M = (S,\sinit,\Act,\mpm),$
with stochastic, history-dependent policies
$\pi : FinPaths(M) \to (\Act).$
The key value functions are
$V_{\min}(s) \coloneq \inf_{\pi \in \Pi_M} Pr_{\pi}(s \vDash \bad), \qquad V_{\max}(s) \coloneq \sup_{\pi \in \Pi_M} Pr_{\pi}(s \vDash \bad).$
OneShield assumes , so that at least one safe policy exists. Safe actions are characterized by
$\SafeAct(s) \coloneq \left\{ \alpha \in \Act(s) \mid \sum_{s' \in S} \mathcal{P}(s,\alpha,s') \cdot V_{\min}(s') = V_{\min}(s) \right\}.$
The framework generalizes shielding to history-aware post-shields
$\shield : Hist(M) \times (\Act) \to (\Act),$
which observe a full execution history and an agent-proposed action distribution $\bad \subseteq S$0, and may replace that distribution. The shield induces a policy transformer $\bad \subseteq S$1, and the allowed policies are
$\bad \subseteq S$2
A central structural result is history mixing: allowed sets are $\bad \subseteq S$3-closed, and canonical shields correspond uniquely to such closed sets.
The framework is organized around an impossibility theorem and several constructive shield families. Classical qualitative shielding sought strong safety (S+) and strong permissiveness (P+) simultaneously. OneShield proves that for any threshold $\bad \subseteq S$4, there exists an acyclic 5-state MDP such that no shield satisfies both properties. The reason given is that probabilistic safety depends on the whole computation tree, whereas a shield sees only one concrete history.
The basic safe shield is the conservative extension
$\bad \subseteq S$5
The framework also discusses multiplicative and additive $\bad \subseteq S$6-shields,
$\bad \subseteq S$7
and
$\bad \subseteq S$8
These are described as practical but not generally safety-guaranteeing.
The paper’s new constructions are the optimistic and pessimistic shields, defined through incurred risk and incurred safety: $\bad \subseteq S$9
0
The optimistic shield satisfies weak safety (S-) and strong permissiveness (P+); the pessimistic shield satisfies strong safety (S+) and weak permissiveness (P-). Their allowed sets are ordered as
1
and all three coincide when 2.
The framework then introduces saturated safe shields, defined by saturated permissiveness: 3 Saturated shields always exist, form an antichain in the lattice of shields, and have convex allowed-choice sets at a fixed history. The optimistic shield is the join of all saturated shields, while the pessimistic shield is below the meet of all saturated shields.
A major constructive contribution is the offline and online generation of safe shields from observed history-action pairs. For a single pair 4, the framework defines a point shield; given a finite set 5, it forms a join of such point shields, checks safety via a recursive value 6, and uses the safe extension operator
7
The incremental offline construction starts from 8, while the online construction updates only between episodes because updating the shield during an episode can be unsafe.
The empirical evaluation compares 9, $M = (S,\sinit,\Act,\mpm),$0-shields, $M = (S,\sinit,\Act,\mpm),$1, $M = (S,\sinit,\Act,\mpm),$2, offline and online constructed shields, and a memoryless offline shield on corridor, drone delivery, drone-b, and dynamic power management. The reported conclusions are that classical shielding is safe but often over-conservative, $M = (S,\sinit,\Act,\mpm),$3-shields can violate the safety threshold, optimistic shielding is not safe, pessimistic shielding is safe but often too conservative, and offline/online constructed shields are safe and often much more permissive. The paper also reports query times of a few thousand queries per second for simple shields, more than 700 queries/sec for online shielding on the largest benchmark, precomputation of $M = (S,\sinit,\Act,\mpm),$4 under a second on the benchmarks, and offline shields becoming close to their best permissiveness after often around 40K construction steps.
3. Stand-alone LLM guardrails
In “OneShield -- the Next Generation of LLM Guardrails,” OneShield is presented as a stand-alone, model-agnostic and customizable solution to safeguard LLMs. Its stated purpose is to protect both live LLM interactions and LLM-related data pipelines from safety, privacy, compliance, and factuality risks in a way that is independent of the base model and adaptable to customer-specific policies (DeLuca et al., 25 Jul 2025).
The architecture is a set of containerized microservices. The main components are the OneShield Orchestrator, a collection of independent stateless Detectors, Data Stores for retrieval/comparison tasks, and a Policy Manager. Detectors run in parallel, the orchestrator waits for all responses, and the Policy Manager applies policy logic over the aggregated context. The paper emphasizes this separation between detection and policy/action enforcement.
OneShield groups detectors into three types. Classification detectors assign texts to risk categories such as Health Advice, Self Harm, HAP, and Inappropriate Content. Extractor detectors return lists
$M = (S,\sinit,\Act,\mpm),$5
where $M = (S,\sinit,\Act,\mpm),$6 is a sub-portion of the original text and $M = (S,\sinit,\Act,\mpm),$7 is an assigned type. Comparison detectors operate against large corpora for text attribution and factuality.
The classification stack uses BERT embeddings with either BertForSequenceClassification or SepCNN. The paper also reports a sentence-level HAP detector using granite-guardian-hap-125m. For self-harm, it uses a sparse human-in-the-loop alignment mechanism over internal LLM interaction logs containing over 156 million records. The health-advice detector, trained from NeedAdvice, AskParents, SemEval2019 Task 9, Detecting-Health-Advice, and HealthE, is reported at 85.07% Accuracy, 86.64% Precision, 88.80% Recall, and 87.70% F1 on HEaL. The self-harm detector reports 96.60% Accuracy, 96.04% Precision, 96.94% Recall, and 96.49% F1 on its test dataset, with 2.00% False Positive Ratio and 3.06% False Negative Ratio. The inappropriate-content detector reports 94.82% Accuracy, 89.52% Precision, 98.52% Recall, and 93.80% F1 on the Kaggle Adult-content dataset.
The LLM Privacy Guard component serves as the extractor layer for PII, covering 13 PII categories, including Names, Addresses, Dates of birth, Phone numbers, Email addresses, Social media handles, Bank account numbers, Credit card details, Tax identification numbers, Social Security numbers, Passport numbers, Driver’s license numbers, Medical record numbers, and Health insurance IDs. The comparison layer includes a factuality detector that combines retrieval with a BERT-based fact-checking model and reports 87.5% Accuracy, 83.2% Precision, 79.4% Recall, and 81.2% F1 on a 2,000-point benchmark constructed from 20 company-intelligence questions and Wikipedia answers for the top 100 Forbes companies.
The Policy Manager is the decision layer that maps detector outputs to actions such as allow, block, mask, warn, or triage. The paper stresses that policies can be use-case-specific and jurisdiction-specific, with examples framed around GDPR and CCPA. This means risk evaluation can depend not only on a single detector output but on cross-detector conjunctions.
The implementation is oriented toward low-latency inference-time deployment. The paper reports single instance, 40 threads for the orchestrator, single instance, 40 threads for the Policy Manager, and detectors typically at 5 instances, 100 threads each. It states that the slowest component is the PII extractor and gives an average response time of 0.521 milliseconds for a user prompt of up to 150 tokens on 1,200 user prompts. Deployment evidence includes internal use since late 2023, thousands of requests daily, and open-source use in InstructLab, where OneShield had been run on 1200+ PRs and about 8.25% were flagged as potential violations.
4. Privacy-preserving guardrails for LLM applications
“Deploying Privacy Guardrails for LLMs: A Comparative Analysis of Real-World Applications” presents OneShield Privacy Guard as a privacy-preserving guardrail framework for LLM applications. Its purpose is to detect, score, and mitigate privacy risks in both user inputs and model outputs so that organizations can use LLMs while remaining aligned with GDPR, CCPA, and PIPEDA (Asthana et al., 21 Jan 2025).
The framework is explicitly modular. In the enterprise deployment, its three core components are the Guardrail Solution, the Detector Analysis Module, and the Privacy Policy Manager. The operational pipeline is
$M = (S,\sinit,\Act,\mpm),$8
with policy actions
$M = (S,\sinit,\Act,\mpm),$9
The paper’s main claim is that privacy risk is often context-dependent rather than reducible to regex matches: a phone number, date, or name may or may not be sensitive depending on surrounding entities and relationships.
The first real-world deployment integrates OneShield into Data and Model Factory, an internal IBM platform that supports diverse data types and approximately 30 LLMs. In this setting, the system processes both prompts and outputs, supports 13 languages in platform data sources and 26 languages in PII evaluation, and applies dynamic enforcement according to jurisdiction. The paper reports 95% F1 score across 26 languages for sensitive entity detection, performance up to 12% better than StarPII and Presidio Analyzer on some entity types, 0.521 ms average response time for prompts up to 150 tokens, 0.711 ms for prompts up to 250 tokens, and added latency under 5% of total system response time. Example entity-level F1 values reported for Deployment 1 include 0.98 for Person, 0.96 for Date, 0.94 for Email, 0.89 for Phone, 0.91 for Location, 0.92 for National ID, and 0.95 for Credit Card.
The second deployment, PR Insights, is an open-source GitHub repository workflow in which OneShield acts as an automated privacy-triage bot. The two main components are an Automated Detection Bot and a Human-in-the-loop Feedback Mechanism. The paper reports analysis of 1,256 pull requests over three months, 8.25% of PRs flagged for privacy violations, average F1 score of 0.86, and 300+ hours of manual effort saved over three months. The time-saving estimate assumes 15 minutes for manual review of a PR, and the deployment is said to improve turnaround by about 25%.
The qualitative examples underscore the role of context. “Alice visited Paris on January 12, 2023” is flagged because the combination of name and date is treated as sensitive in context; “Contact me at [email protected]” is flagged and the email is masked; “Barack Obama was born on August 4, 1961” is treated as policy-compliant because the person is a public figure; and “Historical events from 1776…” is not treated as sensitive. The paper also notes that open-source feedback loops corrected mistakes involving historical figures and fictional characters using contextual cues and public knowledge sources such as Wikimedia SPARQL APIs.
5. Relation to the broader shield-synthesis tradition
The formal-methods usage of OneShield belongs to a broader shielding literature that includes cyber-physical systems, reinforcement learning, adversarial networks, and decentralized partially observable control.
A prior usage in “Shield Synthesis for Real: Enforcing Safety in Cyber-Physical Systems” treats OneShield as a runtime shielding framework for cyber-physical systems whose signals are real-valued. Its main contribution is to ensure that a Boolean shield does not produce corrected predicate assignments that are unrealizable over reals. It introduces a relaxation automaton $\pi : FinPaths(M) \to (\Act).$0 for impossible combinations of original predicates and a feasibility automaton $\pi : FinPaths(M) \to (\Act).$1 for infeasible combinations of corrected-output predicates, constrains the safety game accordingly, and then synthesizes a shield that produces realizable real-valued corrections. The runtime procedure combines Boolean correction with prediction and LP solving, and the paper reports real-valued correction typically within about 0.5 ms when correction is needed and under 1 $\pi : FinPaths(M) \to (\Act).$2 when the original output is already safe (Wu et al., 2019).
“Easy-to-Use Shielding for Reinforcement Learning” extends the practical deployment of shielding into Python RL workflows. Its core contribution is tempestpy, a Python library that integrates Tempest-based shield synthesis directly into the Gymnasium API through PreShieldWrapper and PostShieldWrapper. The paper also extends Tempest to compute sound shields for stochastic multiplayer games, introduces MiniGridSafe, and evaluates shielded versus unshielded RL with MaskablePPO and PPO from Stable-Baselines3 (Pranger et al., 2 Jun 2026). This suggests a route by which formal shielding mechanisms can move from standalone synthesis into ordinary RL experimentation.
“Beyond Runtime Enforcement: Shield Synthesis as Defensibility Analysis for Adversarial Networks” repurposes shield synthesis as a design-time analytical instrument. It models network defense as a constrained two-player safety game, uses a defender specification to define the unsafe region and an attacker specification to restrict legal attacker actions during attractor computation, and extracts a defensibility verdict, a winning region, and a shield as certificate. It then defines a six-metric defensibility fingerprint with ATK, SNK, FRC, STP, MSV, and DDR (Hsain et al., 11 Jun 2026). A plausible implication is that OneShield-style synthesis can function as architectural analysis rather than only as runtime enforcement.
“Generating Local Shields for Decentralised Partially Observable Markov Decision Processes” addresses communication-free Dec-POMDPs by compiling a shield process algebra into a deterministic process automaton, then into a global Mealy machine, and finally into local per-agent Mealy machines whose states are belief-style subsets of global shield states. The local projection is designed to output per-agent safe action sets under partial observation, and PRISM is used to compute best- and worst-case safety probabilities independently of the agents’ policies (Yang et al., 8 Apr 2026). This work does not present a system by the exact name OneShield, but it is explicitly positioned as conceptually aligned with a unified shielding framework.
6. Distinction from SHIELD-branded systems
The literature also contains several systems titled SHIELD that are technically adjacent to shielding or security, but are not interchangeable with the OneShield usages above.
One LLM-security paper introduces SHIELD, standing for Self-Healing Intelligent Evolving LLM Defense, as a training-free, multi-agent defense framework for sponge attacks. Its online defense pipeline consists of semantic similarity retrieval, substring/pattern matching using KMP, and LLM-based reasoning, while a Knowledge Updating Agent and Prompt Optimization Agent create a closed self-healing loop. The paper reports a Stage 1 cosine similarity threshold of 0.6, uses text-embedding-3-small, Zilliz, and gpt-oss:20b, and gives per-query latencies of 97 ms for Stage 1, 63 ms for Stage 2, and 1600 ms for Stage 3 (Sivaroopan et al., 27 Jan 2026).
A separate hardware-security paper, also titled SHIELD, proposes a lightweight defense against remote power side-channel attacks on multi-tenant FPGAs. It uses RO-based power monitors and an obfuscating circuit to flatten the observed power trace. On a Xilinx Zynq-7000 FPGA executing RSA encryption, the paper reports that the number of traces required to extract the encryption key is increased by 166x, with up to 54% less power consumption and up to 26% less area overhead than a random noise-addition-based defense (Ahmadi et al., 2023).
Another unrelated system, again titled SHIELD, addresses APT detection and intelligent explanation using LLM. It combines Local Outlier Factor, provenance-graph analysis, community detection with Louvain, LLM-based reasoning with Qwen 2.5 (32B), and a temporal correlation engine. The same source explicitly states that there is no alias, component name, or conceptual dependency on a product or term called OneShield (Gandhi et al., 4 Feb 2025).
These distinctions are important because the common string “shield” does not imply a common formalism, threat model, or implementation lineage. In some cases the overlap is only nominal; in others, the overlap is methodological but not taxonomic.
7. Common design motifs and significance
Taken together, the OneShield literature suggests a recurring architectural idea: shielding is most effective when it is made explicit, modular, and externalized. In probabilistic MDP safety, that externalization appears as a history-aware post-shield that transforms policies while exposing formal trade-offs between safety and permissiveness (Heck et al., 11 May 2026). In LLM guardrails, it appears as a stand-alone layer that decouples detectors from a Policy Manager, allowing customer-specific and jurisdiction-specific enforcement (DeLuca et al., 25 Jul 2025). In privacy-preserving deployment, it appears as a context-sensitive pipeline that separates entity recognition, contextual sensitivity scoring, and policy decision (Asthana et al., 21 Jan 2025).
A second shared motif is that context is treated as indispensable. In the MDP setting, probabilistic safety cannot be reduced to local action admissibility because the safety budget depends on the full computation tree. In LLM safety, risk categories such as self-harm, factuality, or proprietary reuse are mediated through detector outputs and policy composition. In privacy guardrails, dates, names, and contact details are evaluated relative to surrounding entities and regulatory constraints. This suggests a broader methodological convergence around context-aware enforcement rather than purely local filtering.
A third theme is the rejection of maximalist universality. The probabilistic shielding paper proves that strong safety and strong permissiveness cannot both be preserved in general. The LLM guardrail paper argues that one-size-fits-all safety solutions are not sufficient and that universally shielding users with a single guardrail strategy is infeasible. The privacy paper likewise stresses jurisdiction-specific policy logic and human oversight for edge cases. Across domains, OneShield is therefore less a single algorithmic object than a family of architectures for mediating risk under explicit constraints.
In that sense, OneShield functions as a cross-domain label for a research program centered on shielding as formal enforcement, operational guardrailing, or policy-driven intervention. What remains stable across the usages is not a specific algorithm, but a design stance: risks are identified through structured models or specialized detectors, and system behavior is then constrained, transformed, or filtered before unsafe, non-compliant, or privacy-violating outcomes can propagate.