Sentinel-src: Multifaceted Research Systems

• Sentinel-src is a multifaceted research label that denotes distinct systems in domains like machine translation, cybersecurity monitoring, and smart-contract defense.
• It serves as a source-side translation difficulty estimator, a unified orchestration tool in cybersecurity, and a proxy-based reentrancy protector in Ethereum.
• Common across implementations is the strategic placement of monitoring or defense mechanisms at the ingress point to enable effective threat detection and risk mitigation.

Sentinel-src is an overloaded research label rather than a single standardized platform. In the literature considered here, it denotes or is associated with a source-side machine translation difficulty estimator, the apparent codebase behind a unified cybersecurity monitoring system, and a proxy-based reentrancy defense for Ethereum smart contracts; the broader “Sentinel” name also appears in prompt-injection detection, adaptive RAG defense orchestration, multi-agent security monitors, planetary-defense mission design, and Earth-observation workflows built around Sentinel satellites (Proietti et al., 13 Aug 2025, Tallam, 20 Feb 2025, Joshi et al., 24 May 2026).

1. Scope and principal usages

The term’s ambiguity is itself a defining feature. In some papers it names a deployable software artifact, in others a model family, and in still others a related but distinct architectural role. A precise reading therefore requires domain-specific disambiguation.

Usage in the literature	Domain	Core characterization
Sentinel-src / Sentinel-src-24 / Sentinel-src-25	Machine translation	Source-side translation difficulty estimator
Sentinel-src as CyberSentinel codebase	Cybersecurity monitoring	Centralized orchestration around security_agent.py
Sentinel / Sentinel-src	Smart contracts	Proxy-based reentrancy protection
Sentinel	LLM security	Binary prompt-injection detector
Sentinel-Strategist	RAG security	Risk analysis plus selective defense orchestration
Sentinel Agents	Multi-agent systems	Distributed monitoring and policy-enforcement layer

A common misconception is that Sentinel-src names one interoperable research stack. The available papers instead describe separate systems with different objectives, threat models, and evaluation protocols. Some are primarily detectors, some are runtime enforcers, and some are data- or source-side estimators rather than security tools at all (Proietti et al., 13 Aug 2025, Tallam, 20 Feb 2025, Joshi et al., 24 May 2026, Ivry et al., 5 Jun 2025, Pallerla et al., 22 Apr 2026, Gosmar et al., 18 Sep 2025).

2. Source-side translation difficulty estimation

In machine translation research, Sentinel-src is a dedicated source-side estimator of how hard a text will be to translate. The task is formalized relative to a translator $m$ and target language $l$, with difficulty defined by expected translation quality $d_{m,l}(x)$; lower quality corresponds to greater difficulty. This differs from quality estimation because the estimator does not see the translation. The paper introduces Difficulty Estimation Correlation (DEC), defined as the average Kendall $\tau_b$ correlation across translators and languages, and argues that evaluation should be group-by-system because the relevant question is which source texts are hard for a fixed system (Proietti et al., 13 Aug 2025).

Sentinel-src is positioned against heuristics such as text length, word rarity, and dependency-tree height, and against LLM-as-a-judge methods using GPT-4o and CommandA. The reported result is that learned estimators outperform both heuristic baselines and LLM judges, with Sentinel-src-24 identified as the strongest source-only estimator in the ESA setting. The released variants Sentinel-src-24 and Sentinel-src-25 use XLM-RoBERTa large as encoder backbone, followed by a feedforward network over the $[CLS]$ token, and are trained with MSE to predict human scalar scores. Training proceeds in two stages: a Direct Assessment stage using WMT 21, 22, and 23, with Sentinel-src-25 also including WMT 24 ESA annotations, followed by MQM fine-tuning, with Sentinel-src-25 also including WMT 24 MQM annotations (Proietti et al., 13 Aug 2025).

The same paper emphasizes benchmark construction as a practical application. Given a score $\hat d(x)$, the estimator selects the top-$B$ hardest texts, and the resulting subset is evaluated by average human score and the proportion of perfect translations. Sentinel-src-24 is reported to reduce both the average translation score and the proportion of perfect outputs relative to random selection, while approaching the effectiveness of “artificial crowd” methods at much lower cost (Proietti et al., 13 Aug 2025).

3. Cybersecurity monitoring and the CyberSentinel codebase

In AI-security monitoring, Sentinel-src appears to denote the source-code implementation of CyberSentinel, with security_agent.py functioning as the main orchestrator. The figure-derived architecture is centralized: heterogeneous telemetry such as system logs, SSH activity, network events, and GitHub-related events flows into the orchestrator, which dispatches data to three specialized modules—Brute-Force Detection, Phishing Detection, and an Emergent Threat Detector—and then escalates suspicious outcomes to an alerts/mitigation layer (Tallam, 20 Feb 2025).

The most important architectural idea in that work is the unified single-agent design. Rather than deploying isolated detectors, the system routes multiple signal types through one orchestrating component, enabling cross-source correlation and a feedback-style control loop in which the orchestrator both sends data to detectors and receives their findings back. This design is presented as suitable for emergent threat detection because weak anomalies from different channels can be combined into a stronger incident hypothesis. The paper excerpt, however, is limited to a system diagram; it does not provide internal algorithms, heuristic formulas, pseudocode, anomaly-scoring equations, or evaluation metrics, and those details therefore remain unspecified in the available material (Tallam, 20 Feb 2025).

From a deployment perspective, the architecture targets near-real-time monitoring environments in which a security agent continuously consumes operational streams and supports downstream response. The figure indicates that the system is not merely passive logging, since it includes an alerts/mitigation stage, but the excerpt does not state whether mitigation is manual or automated, nor does it report false-positive rates, latency, or comparative performance (Tallam, 20 Feb 2025).

4. Proxy-based smart-contract protection

In Ethereum security, Sentinel-src—also referred to simply as Sentinel—is a proxy-based reentrancy protection system that decouples reentrancy logic from smart-contract implementation code. The central claim is architectural: defenses should be enforced at the proxy layer, where all calls to the implementation contract can be intercepted consistently, rather than woven into business logic. The proxy is the universal entry point, applies a guard before delegatecall, blocks unsafe static access, and then forwards calldata to the implementation. This is intended to make the system implementation-agnostic, upgrade-proof, and type-agnostic, while covering classic single-function reentrancy, cross-function reentrancy, cross-contract reentrancy, and read-only reentrancy (Joshi et al., 24 May 2026).

The architecture has three main parts: SentinelProxy, the implementation contract(s), and an external LockRegistry/ILockRegistry used in high-security mode. Two operating modes are defined. Optimized mode uses a gas-efficient local lock by checking LOCK_STATUS_SLOT, setting it to 1, and disabling static calls via STATIC_CALL_ALLOWED_SLOT. High-security mode uses an external shared mutex keyed by a domain identifier, enabling coordinated protection across multiple contracts in the same logical domain. Static-call handling is explicit: the proxy detects whether a call is static, avoids state-locking overhead for safe views, and denies reads when the contract is in a locked state so as to prevent read-only reentrancy (Joshi et al., 24 May 2026).

The evaluation uses a dataset of 70 vulnerable smart contracts: 38 single-function reentrancy cases, 20 cross-function cases, and 12 cross-contract cases, with the cross-function and cross-contract groups also including read-only reentrancy instances. On this dataset, Sentinel is reported to achieve 38/38 SFR, 20/20 CFR, and 12/12 CCR, for 70/70 total, while OpenZeppelin ReentrancyGuard achieves 51/70 and LiqGuard 45/70. The paper states that Sentinel provides 100% coverage across the four major attack categories considered and a 40% higher success rate than existing solutions overall. Gas overheads are reported as about 6400–7500 gas for static call detection, about 25,000 gas in optimized mode, and about 53,000 gas in high-security mode; these are compared to typical DeFi transactions of 200,000–500,000 gas. Detection tools on the same dataset are reported at 71.42% true positive rate for Slither, 64.28% for Mythril, and 57.14% for Oyente, supporting the paper’s distinction between detection and runtime prevention (Joshi et al., 24 May 2026).

5. LLM, RAG, and agentic-AI security variants

Several distinct research lines use Sentinel as a control-plane or detection component in LLM security. One paper introduces Sentinel as a binary prompt-injection and jailbreak detector built on answerdotai/ModernBERT-large, a 28-layer model with about 395 million parameters, native context length up to 8,192 tokens, RoPE, local-global alternating attention, and FlashAttention-related efficiency features. Fine-tuned as a sequence classifier on a curated mixture of open-source and private benign and malicious prompt collections, it reports on a held-out internal test set an average accuracy of 0.987, recall of 0.991, precision of 0.986, and F1 of 0.980; on public benchmarks its average binary F1 is 0.938, compared with 0.709 for the stated baseline protectai/deberta-v3-base-prompt-injection-v2. Inference latency on an L4 GPU is about 0.02 seconds per prompt (Ivry et al., 5 Jun 2025).

A different paper proposes the Sentinel-Strategist architecture for Adaptive Defense Orchestration in retrieval-augmented generation. Here Sentinel performs risk analysis from query- and retrieval-side telemetry, while Strategist selectively activates only those defenses warranted by context. The threat model includes membership inference, data poisoning, and content leakage. The paper argues that an always-on static stack of DP-RAG, TrustRAG-style filtering, and attention-variance filtering reduces contextual recall by more than 40%, and then shows that ADO can eliminate MBA-style membership inference leakage while recovering much of the lost retrieval utility. Across five controller variants, aggregate MBA leakage under ADO is reported as 0.0%; under poisoning, performance is controller-sensitive, with Llama 3 and Mistral strongest and GPT-4o and Qwen 3 weaker in activating TrustRAG under borderline cases (Pallerla et al., 22 Apr 2026).

A third strand extends the Sentinel idea to multi-agent systems. Sentinel Agents are defined as specialized monitoring components that observe inter-agent communication in a shared conversational environment, while a Coordinator Agent manages policy, quarantine, and escalation. The proposed deployment patterns are sidecar, proxy, continuous listener, and hybrid. In the proof-of-concept system, the Sentinel pipeline combines rule-based filters, behavioral analysis over a 10-second sliding window, and optional GPT-4-based inspection. A simulation study injected 162 synthetic attacks—110 prompt injection attempts, 49 data exfiltration probes, and 3 hallucination probes—into a travel-planning environment with Planner, Research, and Vendor agents. The paper reports a 100% detection rate across the three attack families, while also noting that false positives were not measured and that the evaluation is a feasibility demonstration rather than a full validation (Gosmar et al., 18 Sep 2025).

Taken together, these systems are related by name rather than implementation. One is a binary classifier, one is a query-aware orchestration framework, and one is a distributed monitoring layer for multi-agent conversation spaces. Their commonality lies in placing a dedicated security component alongside or ahead of the core generative workflow, not in sharing a common codebase (Ivry et al., 5 Jun 2025, Pallerla et al., 22 Apr 2026, Gosmar et al., 18 Sep 2025).

6. Broader scientific uses of the Sentinel name

Outside software and AI security, Sentinel is also the name of a planetary-defense mission concept. In the inner-Solar-System survey study, Sentinel is a wide-field, fully steerable infrared telescope operating in a heliocentric orbit near Venus’s distance from the Sun, roughly 0.7 AU. That interior orbit gives access to a different search volume from Earth-based surveys and makes the system less sensitive to albedo than optical searches. The paper’s key quantitative result is that Sentinel finds 50% of all impactors larger than 40 meters in a 6.5-year survey, and that Sentinel plus LSST can detect more than 70% of impactors larger than 40 meters. The study also argues that surveys must consider objects as small as $D = 15$–$30$ m if the goal is to identify objects that could cause damage on Earth in the next 100 years (Buie et al., 2016).

The name is also pervasive in Earth observation through the Copernicus Sentinel-1 and Sentinel-2 satellites. A systematic review of Sentinel-2 for crop yield estimation identifies three dominant methodological families: empirical vegetation-index models coupled with machine or deep learning, process-based crop models with data assimilation of Sentinel-2-derived variables such as LAI, and multi-sensor fusion, especially Sentinel-2 plus Sentinel-1 SAR (Narimani et al., 24 Mar 2026). For inland-water mapping, one paper extends SEN2DWATER into a multisource, multitemporal Sentinel-1 plus Sentinel-2 dataset with 12,831 co-registered pairs, 15 channels per sample, and benchmark results in which NDWI attains 93% precision, 94% recall, 93% F1-score, and 94% overall accuracy (Russo et al., 2024). In high-resolution flood mapping, a contiguous-U.S. framework combines manually annotated Sentinel-2 labels, transferred Sentinel-1 supervision, a shift-invariant loss for residual co-registration uncertainty, and a Conditional Variational Autoencoder for despeckling; the best multispectral model reaches AUPRC up to 0.956, while SAR flood mapping improves relative to classical filtering when shift-aware training and generative despeckling are used (Ma et al., 29 Jun 2026).

Related papers emphasize that Sentinel-1 and Sentinel-2 data are not perfectly aligned out of the box. A dedicated co-registration study reports clear residual shifts between ESA Sentinel-1 SAR and Sentinel-2 optical products and finds that a 3rd-order polynomial warp gives the most satisfactory results, with total processing time under 10 seconds per image pair (Ye et al., 2020). In disaster response, xBD-S12 aligns xBD with Sentinel-1 and Sentinel-2, yielding 10,315 pre- and post-disaster image pairs; the benchmark shows that ChangeMamba performs best in-distribution at $F1_{\text{comp}} = 0.800$, while simpler U-Net variants generalize better on the event-based split, where U-Net 2-step late fusion reaches $l$0 and geospatial foundation models provide little practical benefit (Dietrich et al., 7 Nov 2025). This broader literature shows that, in remote sensing, “Sentinel” usually denotes sensor platforms and mission infrastructure rather than a software artifact called Sentinel-src (Narimani et al., 24 Mar 2026, Russo et al., 2024, Ma et al., 29 Jun 2026, Ye et al., 2020, Dietrich et al., 7 Nov 2025).

7. Architectural patterns and disambiguation

Across these otherwise unrelated papers, a recurring design preference is visible. Sentinel-branded systems often sit at a boundary or control point rather than inside the protected process itself: Sentinel-src in MT scores the source text before translation; CyberSentinel’s security_agent.py routes heterogeneous telemetry before escalation; the smart-contract Sentinel proxy intercepts calls before implementation logic executes; the Sentinel in Sentinel-Strategist analyzes risk before Strategist selects defenses; and Sentinel Agents monitor message flow before Coordinator-level containment. This suggests a shared architectural intuition: place monitoring or enforcement at an ingress, proxy, or control-plane layer so that heterogeneous downstream behaviors can be handled without modifying every internal component (Proietti et al., 13 Aug 2025, Tallam, 20 Feb 2025, Joshi et al., 24 May 2026, Pallerla et al., 22 Apr 2026, Gosmar et al., 18 Sep 2025).

Another useful disambiguation concerns “detection” versus “protection.” Some Sentinel systems are purely predictive or classificatory, such as the prompt-injection detector and the translation-difficulty estimator. Others are intended to change runtime behavior, such as the smart-contract proxy or the adaptive RAG defense controller. Still others are primarily observational and governance-oriented, such as Sentinel Agents in multi-agent systems. A final misconception is terminological: in planetary science and remote sensing, “Sentinel” frequently refers to telescopes or Copernicus satellites rather than software packages. The name therefore identifies a family of research labels, not a single technical standard (Ivry et al., 5 Jun 2025, Proietti et al., 13 Aug 2025, Joshi et al., 24 May 2026, Gosmar et al., 18 Sep 2025, Buie et al., 2016, Narimani et al., 24 Mar 2026).