Cosine's pitch for ArgusRed is blunt: "We post-trained a model that pen tests instead of refusing." The interesting question isn't the marketing — it's what a model built to attack code, rather than apologize for being asked to, actually delivers.
What ArgusRed Does and Who It's Designed For
ArgusRed is an offensive-security tool built on a model that Cosine post-trained specifically for adversarial work, not an off-the-shelf API wrapped in system prompts. The premise is that general-purpose LLMs are aligned to refuse or hedge on offensive tasks — reading the code worth attacking, attempting exploits — so any tool built on them inherits those refusals; a model trained for the job is claimed to do the work instead . Cosine is the UK lab behind Genie, its autonomous coding agent reported around 30% on SWE-bench .
The intended user is narrow and specific: small development teams without a dedicated security function, facing investor, auditor, or customer pressure on their application security posture . That framing matters because it sets expectations — this is positioned as a tool a team without an in-house pentester can run, though Cosine's broader cybersecurity page is more cautious about replacing human reviewers.
ArgusRed produces two deliverables rather than a long backlog of warnings. It reports confirmed exploitable findings with supporting runtime evidence — request/response pairs or stack traces — and attaches a proposed fix or pull request . Unproven candidates are discarded, not handed to you as "maybes," and the tool can re-attack after remediation to verify the fix actually closed the hole.
The only published output backs up that emphasis on evidence over volume. In a sample report dated 2026-05-22, ArgusRed audited the Symfony Framework — roughly 1.05 million lines of code across 10,904 files on PHP 8.4+ — and reported 2 confirmed exploitable findings, 12 rejected false positives out of 14 candidates, and 0 files touched in the target repository . The headline number isn't how much it found; it's how much it threw away.
CLI Design: Security Scan, Pen Test, and Go Enforcement
That restraint is enforced by architecture, not by the model's judgment. ArgusRed's CLI splits the work into two phases with different blast radii. Security Scan is a read-only pass that analyses a codebase across eight vulnerability categories (the categories are referenced but not enumerated on the readable CLI page) . Pen Test is the active phase: it attempts live exploits, but only against systems the user has explicitly authorised, and authorisation is required before it runs . The two modes share a model but not a permission set.
| Property | Security Scan | Pen Test |
|---|---|---|
| Access | Read-only code analysis | Live exploit attempts |
| Scope | 8 vulnerability categories | User-authorised targets only |
| Mutating ops (writes, command exec) | Deterministically blocked by harness | Permitted within sandbox |
| Network egress | Not required | Restricted to pre-authorised addresses |
| Pre-condition | None beyond repo access | Explicit authorisation |
The control mechanism is the part worth reading closely. Below the model sits a harness written in Go that intercepts every tool call before execution. In Security Scan, it deterministically blocks file writes and command execution regardless of what the model requests; in Pen Test, it restricts network egress to the pre-authorised target addresses only . Scope is a property of the harness, not a property of the prompt. If the model decides to write a file during a read-only scan or reach an out-of-scope host, the call never leaves the interception layer. That is a meaningfully different trust model from prompt-level guardrails, which depend on the model choosing to comply.
Cosine frames this as "unsafe model, safe harness."
"Unsafe model, safe harness" — the design premise that the model is intentionally not constrained by alignment, with control living in a non-model layer below it (source: ArgusRed CLI).
The logic follows from the product's core pitch. General-purpose models are aligned to refuse or hedge on offensive tasks, so a tool built on one inherits those refusals; Cosine's answer is a model post-trained to do the work instead, then fenced from the outside by a deterministic guardrail . Safety is enforced where it can be audited — in code — rather than left to the statistical behaviour of an LLM.
For a performance reference point, Cosine reports scanning Google's Bank of Anthos demo application — roughly 30,000 lines across six modules — in about 10 minutes . Treat that as a vendor figure, not an independent benchmark; no third-party timing or reproduction has been published. The architecture is the more durable claim here. A non-LLM enforcement layer is verifiable in a way that a model's restraint is not.
The Symfony Audit: 2 Exploitable Findings, 12 False-Positive Rejections
The only concrete output Cosine has published is a sample report dated 2026-05-22, run against the Symfony Framework — roughly 1.05 million lines of code across 10,904 files on PHP 8.4+ . On that codebase ArgusRed surfaced 2 confirmed exploitable findings while rejecting 12 false positives and downgrading 6 more . The headline number is not the two bugs; it is the fourteen alerts the tool declined to forward.
Quick Answer: ArgusRed's published Symfony audit (2026-05-22) scanned ~1.05M lines across 10,904 files and reported only 2 confirmed exploitable findings, rejecting 12 false positives and downgrading 6. Zero files were touched in the target repo; verification ran in read-only Docker isolation.
That ratio reflects a stated design goal: suppress unproven alerts rather than maximize discovery volume. ArgusRed classifies each candidate as confirmed, not reproducible, or inconclusive, and surfaces only the confirmed tier to the developer . A finding earns "confirmed" status by being reproduced as a working exploit in the sandbox, with a request/response or runtime trace attached and a proposed fix. Everything that cannot be reproduced is discarded rather than passed along as a "maybe" — the inverse of a conventional scanner that floods a queue and leaves triage to the reader.
| Status | Count | Surfaced to developer? |
|---|---|---|
| Confirmed exploitable | 2 | Yes — with evidence + proposed fix |
| Downgraded | 6 | No — severity reduced, not actionable |
| Rejected false positive | 12 | No — discarded |
| Files modified in target repo | 0 | — |
Isolation is enforced at the container boundary, not by the model's judgment. Verification ran in Docker with the host checkout kept read-only, and the run reports 0 files touched in the target repository across the entire audit . This is the same architectural point from the harness layer, now visible as an output artifact: the model can attempt whatever it wants inside the sandbox, but the repo it is reasoning about stays untouched. Cosine separately states that source and sandbox execution remain within the UK and EU , a containment claim that matters for regulated teams but is, like the rest, vendor-reported.
One workflow detail is worth flagging for anyone integrating this into a remediation loop: ArgusRed can re-run against the same codebase after a fix lands, re-attacking each confirmed finding to verify closure rather than trusting that the patch worked . That turns a single report into a verify-fix-verify cycle. The caveat is unchanged from the architecture discussion: the Symfony report is a first-party artifact. No third party has reproduced the run, re-scanned the same Symfony commit, or audited whether the two confirmed findings were genuinely novel. Treat the numbers as a demonstration of the suppression model, not as an independently validated benchmark.
ArgusRed Has No Model Card. What That Means for Trust.
That gap is the pattern, not the exception. As of June 2026, no model card, evaluation report, or abuse-control policy specific to ArgusRed has been published — the claim that Cosine "post-trained a model that pen tests instead of refusing" is positioning, not an independently verified capability. There is no published refusal-policy document, no security eval, and no third-party audit of the offensive model behind the tool . For developers used to reading a model card before trusting a system, ArgusRed asks you to trust the harness and the marketing instead.
Cosine's own documentation undercuts the most aggressive framing. ArgusRed's landing page markets a low-friction "no security team required" product, but Cosine's broader cybersecurity page is more cautious — it states the tool is not a traditional scanner, does not replace reviewers, and is designed for human-in-the-loop use in a controlled environment . Those two messages target different readers, and the cautious one is the accurate one.
"[It is] not a traditional scanner, does not replace reviewers, and is designed for human-in-the-loop, controlled-environment use." — Cosine cybersecurity documentation (source: Cosine)
The one hard benchmark Cosine has published does not cover this product. The Lumen Outpost report (May 13, 2026) claims 53.9% Pass@3 on Cosine's internal Niche-Bench versus 48.3% for Kimi K2.6, leading or tying in 9 of 13 languages . That measures long-horizon general coding, not adversarial security work. It supports the claim that Cosine can build and serve post-trained specialist models; it does nothing to validate that ArgusRed's specialist actually thinks like an attacker.
Community scrutiny has been thin and contested rather than confirmatory. The Hacker News launch discussion was rocky — at least one submission was flagged or deleted over AI-generated text and self-promotion . No independent production case study, third-party evaluation, or reproduced run exists. The practical takeaway: scope ArgusRed to authorized targets, keep a human reviewer on every confirmed finding, and treat its performance and safety claims as vendor statements until independent coverage lands.
Dual-Use Risk and Authorization in ArgusRed's Offensive Model
ArgusRed's primary defense against misuse is authorization gating, not model-level refusal. The Pen Test phase requires the user to explicitly declare which target systems are in scope, and the Go harness restricts network egress to those pre-authorized addresses only — any tool call aimed elsewhere is blocked deterministically before execution . This is consistent with the product's core thesis: because the underlying model is post-trained to attempt offensive work instead of refusing it, the safety boundary has to live outside the model, in the harness. The consequence is that the gate is only as trustworthy as the team setting the scope.
That trust problem is sharpened by ArgusRed being closed-source . There is no public GitHub permission manifest, no published release notes, and no model card, so the Go enforcement layer — the component that supposedly blocks mutating operations in Security Scan and confines egress in Pen Test — cannot be externally audited. You are asked to take the "unsafe model, safe harness" design on the vendor's word. For a tool whose failure mode is an offensive agent reaching a system it was not authorized to touch, the absence of an inspectable enforcement implementation is a material gap, not a footnote.
Cosine adds a data-residency claim: source code and sandbox execution stay within the UK and EU . For regulated teams that constraint can matter, but it carries no independent audit, attestation, or third-party verification — it is another first-party statement layered on a closed system.
The compliance and liability framing is where this lands for a deploying team. ArgusRed's landing page markets a low-friction "no security team required" product, while Cosine's broader cybersecurity page is more cautious — stating it is not a traditional scanner, does not replace reviewers, and is built for human-in-the-loop, controlled-environment use . With no published abuse-control policy and an offensive model designed not to refuse, the entire authorization burden falls on whoever runs it. Practically, that means:
- Scope every run yourself. The harness enforces what you authorize; it cannot tell a legitimate target from one you have no permission to test.
- Own the legal exposure. Misdirected exploitation against a system you do not control is your liability, not a refusal the model will catch.
- Treat residency and enforcement claims as unverified. Until independent coverage lands, the UK/EU and harness guarantees are vendor statements.
Cosine's Adversarial Trajectory: From Genie to Sovereign AI to ArgusRed
ArgusRed is the first public offensive product from Cosine, a UK company previously known for Genie, its autonomous coding agent reported at roughly 30% on SWE-bench . The shift is the story: from automating the writing of your own code to adversarially testing other people's. The same post-training playbook drives both — Cosine builds specialist model variants for domains where general-purpose models underperform, then serves them behind a harness. ArgusRed is the newest and, notably, the least documented entry in that lineup.
That trajectory has institutional weight behind it. GOV.UK named Cosine among six startups receiving AIRR supercomputer access through the UK Sovereign AI effort, describing the company as a British frontier lab building models and coding agents for defence, national security, and regulated industries . Cosine has separately rallied BT, HSBC, and BAE around "Lumen Sovereign," pitched as Britain's first sovereign frontier model, with cybersecurity and adversarial testing named among the priority use cases . ArgusRed fits that narrative cleanly: an offensive model is the product form of a "build for defence and regulated industries" thesis.
The post-training pattern is consistent across the catalogue. Cosine's Lumen Outpost benchmark report claims 53.9% Pass@3 on its internal Niche-Bench against 48.3% for Kimi K2.6, and the model picker lists Lumen Outpost and Lumen Scout at roughly 0.25x and 0.1x cost multipliers . The coding variants come with a benchmark report; ArgusRed ships with a landing page, a CLI description, and one sample report. That asymmetry is the takeaway.
The concrete read for a developer: ArgusRed is a coherent extension of a company that genuinely ships post-trained specialists and has the sovereign-AI backing to fund offensive work. But the evidence floor sits well below its coding products. Use it where you control the target and the legal exposure, treat its UK/EU residency and harness guarantees as vendor claims, and wait for an independent benchmark, a model card, or a third-party audit before trusting it as a security control rather than an assistant.
Last updated: 2026-06-26. Based on Cosine first-party material and contemporaneous reporting; performance and safety claims remain vendor statements pending independent coverage.
Frequently asked questions
Is ArgusRed a wrapper around an existing LLM API?
No. Cosine post-trains a model specifically for offensive security rather than prompting an off-the-shelf API behind a system prompt . The base model is not disclosed, and ArgusRed is closed-source . The distinction is the entire pitch: a general-purpose model is aligned to refuse or hedge on adversarial tasks like reading the code worth attacking or attempting exploits, so a tool built on it inherits those refusals, whereas a model trained for the work is claimed to perform it instead. That "instead of refusing" behaviour, however, is positioning — no refusal-policy document, eval report, or model card was published to substantiate it.
What is the difference between Security Scan and Pen Test in the ArgusRed CLI?
Security Scan is read-only and Pen Test is active, and both modes are constrained by a Go harness rather than by model alignment. In Security Scan, the harness deterministically blocks every mutating operation — file writes and command execution — regardless of what the model requests . In Pen Test, the harness attempts live exploits against user-authorised systems but restricts network egress to pre-authorised targets only . This is the "unsafe model, safe harness" design: a non-LLM guardrail intercepts each tool call before execution, so the enforcement lives outside the model.
How does ArgusRed suppress false positives?
It attempts to reproduce each candidate vulnerability in an isolated sandbox and reports only confirmed, reproducible findings; candidates it cannot verify are rejected or marked inconclusive . The clearest illustration is the Symfony Framework sample report dated 2026-05-22, which recorded 2 confirmed exploitable findings, 12 rejected false positives, and 6 downgraded findings, with 0 files touched in the target repo and verification run in Docker against a read-only host checkout . Evidence quality and false-positive suppression — not raw discovery count — are the stated design goals.
Has ArgusRed's performance been independently verified?
No, as of June 2026. The Symfony report and the Bank of Anthos timing — roughly 10 minutes for about 30,000 lines of code across 6 modules — are both vendor-produced artifacts, not independent benchmarks . No model card, third-party benchmark, or external production case study has been published. Cosine's Lumen Outpost benchmark report, which claims 53.9% Pass@3 on its internal Niche-Bench, measures general long-horizon coding, not offensive security, so it does not validate ArgusRed's security model . Treat the performance claims as vendor statements pending independent coverage.
What stops ArgusRed from being used against unauthorized systems?
The Go harness restricts Pen Test network egress to pre-authorised target addresses only, and Cosine requires explicit authorisation before a Pen Test runs . That gating reflects the obvious dual-use risk of an offensive model built not to refuse. Beyond it, ArgusRed is closed-source with no published abuse-control policy, model card, or permission manifest , so external verification of how the egress restriction is actually implemented is not currently possible. Cosine also states source and sandbox execution stay within the UK and EU, but that too remains a vendor claim .
