Introducing Sentinel-R3

Published on September 19, 2026

A penetration test is a long conversation with a machine that will not answer directly. You enumerate, you form a hypothesis, you test it, you read the output, and you revise. The interesting part is rarely a single clever command. It is holding the whole picture in your head across hours of work and knowing which thread to pull next.

Today we are releasing Sentinel-R3, the third generation of our offensive-security agent for authorized penetration testing. It is a reasoning and tool-use model: given a scoped target and a toolkit, it enumerates, works out a foothold, escalates as far as it can, and writes up the attack path with root causes and remediation.

Sentinel-R3 is on Hugging Face as a gated, proprietary release.

R3 is not a larger R2. Two things changed underneath it, and both were about making long, tool-heavy engagements practical rather than about raising a benchmark score.

A new base, chosen for long engagements

Where R2.2 was built on Gemma 4 26B-A4B, a sparse mixture of experts, R3 moves to Qwen3.8-27B: a 27.6B dense hybrid-attention model. Every parameter is active on every token.

The architecture is the reason we moved. Across its 64 layers, the base interleaves 48 Gated-DeltaNet linear-attention layers with 16 full-attention layers, on a 3:1 ratio. Linear attention is O(n) in sequence length rather than quadratic, and the periodic full-attention layers preserve the exact recall that linear attention alone gives up.

That ratio is what makes the 262,144-token native context affordable in practice. A real engagement is not a short prompt. It is a full port scan, several file dumps, a directory listing nobody wants to truncate, and dozens of tool round-trips, all of which have to stay in context because the finding on turn forty depends on something noticed on turn six. Quadratic attention makes that expensive enough that harnesses start summarising and throwing away the evidence. Linear attention on most layers makes keeping it viable.

The base is a vision-language model, and we left that intact. Fine-tuning targeted the language model only, so the vision tower and its preprocessor pass through unmodified and image input still works as it does in the base. The training data is text-only, so none of the security behaviour is conditioned on images.

Nineteen tools, not one shell

This is the change we expect operators to feel first.

R2.2 funnelled every action through a single execute(command) tool. That works, but it teaches the model a bad habit: cram every intention into a shell string, then parse prose back out of the result. Real agent harnesses do not work that way, so there was a permanent gap between how the model was trained and how it was actually run.

R3 is trained on a nineteen-tool agent surface — Bash, Read, Write, Edit, Grep, Glob, Agent, the Task* family, Cron*, Monitor, SendMessage and ListAgents. The training data was rewritten onto exactly this surface, so the action space the model sees at inference is the one it saw during fine-tuning. No prose parsing, and no pretending a file edit is a sed invocation.

The reference harness is our own CLI, which exposes the same nineteen tools:

Point it at a vLLM server running these weights and it will map attack surface, prove exploitability against authorized targets, and produce findings with severity ratings and evidence. Execution stays containerised, with egress allowlisting and an immutable root filesystem, and sessions persist across days with transcript resumption.

What it learned from

Sentinel-R3 was fine-tuned on glyphsoftware/sentinel-exploit-tooled, a curated set of authorized penetration-test trajectories rewritten onto that tool surface. Each example is a multi-turn conversation that runs the full arc: enumeration, foothold, privilege escalation, remediation write-up, interleaving reasoning with tool calls and tool results.

• 1,230 conversations, split 1,205 train and 25 held-out
• 4,171,133 tokens, of which 2,222,145 are supervised
• 19 distinct tools, with 78% of calls to Bash and 22% to the dedicated tools

The trajectory mix is deliberately weighted toward full engagements rather than isolated tricks: 350 ATT&CK-mapped full-lifecycle red-team engagements, 300 HTB-style machine pentests, 300 V8 JavaScript-engine exploitation traces, 100 jeopardy CTFs, 100 advanced engagements across Active Directory, cloud and database targets, 41 grounded synthetic pentests on real CVE chains, and 39 single-CVE exploit development runs.

Every scenario is scoped as authorized testing against lab targets, and all flags, credentials and addresses in the set are synthetic lab values.

Training itself was LoRA supervised fine-tuning at rank 32, merged down to bfloat16, on a single NVIDIA DGX Spark. It reached the shipped checkpoint in 12.5 hours across 152 steps, with a held-out eval loss of 0.5665.

Benchmarks, and what they do not show

Measured on 2026-08-16 with EleutherAI's lm-evaluation-harness v0.4.12, zero-shot on the merged weights:

• MMLU computer security: 0.8800 accuracy
• MMLU security studies: 0.8449 accuracy
• WMDP cyber: 0.6296 accuracy

We want to be direct about what those numbers are worth. They are multiple-choice knowledge tests, and this model was not fine-tuned for recall. We ran the base model under identical settings and all three differences were within noise. That is the expected result: the fine-tune targets agentic behaviour, and a multiple-choice benchmark cannot see agentic behaviour.

What we have not published is the number that would actually matter: end-to-end task success on real engagements. No agentic benchmark has been run on this build, and checkpoint selection was on held-out loss alone. Treat the figures above as evidence that we did not damage the base model's security knowledge, and nothing more than that.

WMDP in particular is a hazardous-knowledge proxy rather than a quality metric. It exists so unlearning methods can be scored on driving it down. We report it for transparency, not as an achievement.

Known limits

A model that is designed to compromise systems should ship with its failure modes in plain sight.

• It is not a substitute for a skilled operator. Outputs can be wrong, incomplete, or unsafe to run. Every command needs review before execution.
• The training set is small. 1,205 conversations is a specialised behavioural slice, not a broad capability upgrade.
• Roughly 9% of training tool calls are synthesised. The Task*, Cron*, SendMessage and ListAgents families have no precedent in the source corpus, so they teach syntax and plausible placement rather than verified strategy.
• Some tools are barely taught. Glob, Edit, TaskOutput and TaskStop have single-digit example counts and should not be relied on.
• It is prompt-format sensitive. The model was trained on a prose tool description. Serving it through a harness that passes a structured tools= list is a train/inference mismatch, and that branch of the chat template was never seen during training.
• The distribution is skewed toward Linux HTB-style boxes, web and service CVEs, and V8 exploitation.
• Its reasoning is not ground truth. Plans and explanations are aids to validate, not proofs.

Scoping, network isolation, logging and guardrails are the responsibility of the operator and the harness around the model. They are not properties of the weights.

Running it

The repository holds full merged weights, so it loads directly with Transformers with no separate base download or PEFT step. An adapter-only repository is published alongside it for teams who want to compose it differently.

Two settings matter more than the rest. Leave thinking enabled — the chat template emits a reasoning block on every assistant turn and defaults to reasoning_effort="xhigh", and the model was trained that way. And keep the prose system prompt, which the template injects on every render. A system message you pass in is appended to it rather than replacing it, so use that slot for engagement-specific detail such as scope and rules of engagement, not for restating the operator persona.

Recommended generation settings are a temperature of 0.2 to 0.4, top_p of 0.9, and at least 1024 new tokens, since reasoning and tool calls consume budget quickly. The weights serve through any OpenAI-compatible runtime, including vLLM and SGLang.

Gated by design

Sentinel-R3 is an offensive-security model, and that makes distribution a product decision rather than a footnote.

The repository is publicly visible, but the weights are gated. Requesters confirm that they are authorized users, that they will only point the model at systems they have explicit permission to test, and that they accept the terms of the Glyph Proprietary License v1.0. The model is not open source, and it may not be redistributed, distilled, or used to train or evaluate another model.

To request access, visit glyphsoftware/sentinel-r3, review the conditions on the model page, and submit a request from your Hugging Face account. Once approved, authenticate with a permitted token and load the merged weights.

What comes next

The honest gap in this release is evaluation. We can show you that R3 keeps the base model's security knowledge and that its held-out loss is where we want it, but we cannot yet show you a number for how often it finishes an engagement. Building that benchmark, in isolated environments and against targets we control, is the next piece of work.

Alongside it we are broadening the trajectory set, particularly for the tail tools that are currently under-represented, and continuing to tighten the guardrails in the harness that surrounds execution.

If your team runs authorized engagements and wants to evaluate Sentinel-R3, get in touch.