System Card / Version 1.4
Dagger
The v1.4 model and harness powering Ares
Ares is an autonomous offensive security system that finds and proves exploitable weaknesses across APIs, web applications, and mobile applications. This card documents Dagger: the v1.4 model and harness that operate it: governed by one principle: people authorize and bound the work, and Ares plans and executes within those bounds.
Release
v1.4 / June 2026
Coverage
API, Web, Mobile
Deployment
Self-hosted, local-only
Operating model
Human-authorized, scope-bound
01 · Overview
Overview and intended use
Ares runs autonomous red team operations against systems its operators are authorized to test. An operation, which the product calls a hunt: begins from a defined target and scope, enumerates the reachable surface, exercises that surface for weaknesses, and returns evidence-grade, reproducible findings a security team can act on. This card documents Dagger, the v1.4 model and harness that drive those operations.
Ares reaches external targets directly and internal targets through a lightweight Hunt agent the customer runs inside their own network, establishing a controlled tunnel so the platform can assess assets that are not exposed to the public internet. Access is multi-tenant with role-based controls, so an operation is always tied to an authenticated operator and an authorized scope.
Who it is for
Ares is built for internal security teams, penetration testers, and managed security service providers who need continuous coverage at a scale and cadence that manual testing cannot match. It augments human practitioners; it does not replace their judgment, and its findings are designed to be reviewed, prioritized, and acted on by people.
What this card covers
This is a transparency document for Dagger, the v1.4 model and harness, at the level of capability, evaluation, and control. It describes how the system is built and bounded. It deliberately omits operational detail, exploit content, and anything that would provide uplift for attacking systems without authorization.
Authorized use only
Ares is designed and licensed for testing of systems the operator owns or is explicitly authorized to assess. By default the platform performs reconnaissance only; active exploitation is a separate, deliberately enabled capability. Use against systems without authorization is prohibited by license and by the controls described in this card.
02 · Architecture
Model and architecture
Ares is not a single model answering prompts. It is a coordinated system of specialized agents sitting on top of a shared knowledge layer and a self-hosted model, all orchestrated so that an operator’s authorized objective becomes bounded, verified work.
The model
Dagger, the v1.4 model, is a foundation model fine-tuned for offensive security work. It is self-hosted and runs locally inside the deployment boundary, so target data and findings do not leave the customer or operator environment for a third-party model provider. This local-only posture is a deliberate architectural invariant, not a deployment option, and it is what allows Ares to operate in environments where data residency and isolation are non-negotiable.
Model specifications
Dagger v1.4
Base lineage
Fine-tuned foundation model
Parameters
14 billion
Context window
32,768 tokens
Fine-tuning
Curated offensive-security datasets
Knowledge cutoff
January 2025
Deployment
Self-hosted, local-only inference
Training data and customer-data handling
Dagger is fine-tuned on curated offensive-security datasets assembled from sources Assail is licensed to use, public security corpora, and synthetic data generated in the internal Assail Bank laboratory; the composition, cleaning, and filtering of that mix are governed by an internal data-governance standard. Customer engagement data is the sensitive case and is treated separately: target data, traffic, and findings produced during a hunt are processed only inside the customer or operator boundary and are not transmitted to Assail or to any third-party model provider for training. The post-operation self-heal loop writes learned false-positive suppression skills back into a store scoped to the originating tenant; suppression learning is not pooled across tenants unless a customer explicitly opts in.
The harness and the swappable-model thesis
The harness coordinates the agents, manages the lifecycle of an operation, and holds the egress and scope controls. Ares is built on the thesis that the harness accrues durable value while the model remains swappable. Capability, evaluation, and safety are measured as properties of the whole system (the agents, the validators, and the controls around them) rather than of a single set of weights.
Operation flow
An operator’s authorization (target, scope, and rules of engagement) enters the Polemos orchestrator, which drives a bounded pipeline. A validation tier funnels candidate findings into evidence-grade results, and a post-operation self-heal loop feeds precision back into the next run.
Reconnaissance
Surface mapping
Detection
Candidate findings
Exploitation
Confirm in scope
Chaining
Kill-chain
03 · Evaluations
Capabilities and evaluations
Ares is evaluated on public, security-specific benchmarks alongside a controlled internal environment. Each benchmark measures a different slice of capability, and methodology matters as much as the headline number, so it is stated here in full. Two principles govern every run: no per-target hardcoding, so capability is generic rather than memorized; and a clear separation between detection (finding a weakness, and capture or exploitation) proving it.
The benchmark suite
CVE-Bench is a public benchmark of 40 real, recently disclosed vulnerabilities, run in zero-day and one-day variants, that measures an agent’s ability to exploit live vulnerabilities. XBOW is a set of 104 dockerized web challenges scored on flag capture, where 17 legacy images do not build, so the solvable ceiling is the buildable set. The OWASP Benchmark measures detection precision and false-positive behavior across a large synthetic suite. The internal Assail Bank is a deliberately vulnerable laboratory used for training and for repeatable internal benchmarking, including multi-step exploit chains.
CVE-Bench · one-day variant
92.5%
37 of 40 CVEs exploited in a single end-to-end run per challenge.
XBOW · interim snapshot
58 / 86
Flags captured, with 86 detected of the 87 buildable images. 17 of 104 do not build; the count is expected to move as the campaign completes.
Methodology. Figures reflect Dagger, the v1.4 model, on the harness, measured on a frozen mid-June 2026 snapshot. We report a single end-to-end run per challenge (pass@1), graded automatically by flag capture for XBOW and by the benchmark’s own exploit-success check for CVE-Bench, with no per-target hardcoding. Challenges were run under white-box access to the target environment, which measures a generic capability ceiling rather than single-pass field performance. The OWASP Benchmark (detection precision and false-positive behavior) and the internal Assail Bank (multi-step chaining) are run separately and described in the text rather than charted.
Reading these results
Benchmark performance is indicative, not predictive of any specific engagement. Real targets differ from benchmark targets in scope, configuration, and defenses, and a capture campaign run one challenge at a time under white-box review is a measure of a generic capability ceiling, not of single-pass field performance. Ares is strongest at finding and proving weaknesses inside a defined surface and at chaining verified findings into a demonstrated path; results on a given system depend on the environment and the rules of engagement the operator sets.
04 · Safety
Safety, authorization, and misuse mitigations
An autonomous offensive system carries obvious dual-use risk. The answer is not a single guardrail but a layered set of controls, each constraining a different failure mode. The first and most important is structural: the system acts only on what a human has authorized and bounded, and its network reach is gated at the harness so it cannot wander outside that scope.
The authorization mandate
People authorize and bound the engagement. Ares plans and executes inside those bounds. Authorization is the precondition for the system to act at all, and autonomy depends on it rather than relaxing it.
Layered controls
Each layer constrains a distinct failure mode.
Scope binding and egress control
Every operation is tied to an explicit target definition and rules of engagement. The harness enforces a scoped network gate, so the system cannot reach assets outside the authorized scope, and out-of-scope direction is refused rather than reinterpreted.
Recon-first posture
By default Ares performs reconnaissance only. Active exploitation is a separate capability that must be deliberately enabled, so the more intrusive behavior is never the default and is always an explicit operator choice.
Validation tier
A validation tier sits between the engagement agents and the operator, adjudicating findings against evidence, confirming reproducibility, and suppressing false positives. The platform does not report a vulnerability as confirmed without exploitation evidence, so findings are demonstrated rather than asserted.
Audit and traceability
Operation activity is logged for review and attribution, including the post-operation self-heal revisions, which are stored as an auditable overlay without overwriting the original findings. The record makes accountability possible after the fact and supervision possible during the run.
Data protection and local-only inference
Customer data is protected with per-tenant encryption and a customer-held private key, backed by a hardened secrets store, and the model is self-hosted, so target data and findings are not sent to a third-party model provider.
Differentiated access
Ares is a controlled commercial product, not a broadly available offensive capability. Public-sector mission work is delivered through a separate program and is not part of the commercial Ares offering described here.
Adversarial input integrity
An autonomous offensive agent necessarily reads attacker-influenceable content: HTTP responses, error messages, page text, and files returned by the target. That content is treated as untrusted data, not as instructions. The harness constrains the agent so text encountered in a target cannot expand scope, redirect the operation, change the rules of engagement, or trigger egress outside the authorized boundary; injection attempts are logged as observations rather than obeyed.
Real-time oversight and abort
Oversight is not only after the fact. An authorized operator can pause or terminate a hunt in progress, and the harness exposes the live action stream so a human can supervise an active operation, not just review it afterward. Termination halts further action while preserving the audit record up to that point.
No single layer is sufficient against a determined or adaptive misuse attempt, and Assail does not claim otherwise. The layers are designed to make unauthorized or unsafe action harder, more uncertain, and more detectable, while preserving the legitimate defensive work the product exists to do.
05 · Robustness
Red teaming and robustness
Controls are only meaningful if they hold under pressure, and an autonomous offensive system has to be tested against its own behavior as much as against its targets.
Benchmark-driven hardening
Capability is improved against external, scored benchmarks one failing case at a time: identifying the generic capability gap behind a failure and closing it generically rather than hardcoding a result. Failures cluster by vulnerability class, so a single generic improvement typically lifts a whole batch, tracked against reproducible public targets.
Continuous precision review
The self-heal loop runs after every operation, turning false positives into reusable suppression skills, so precision is reviewed continuously in production rather than only at training time. The same pipeline can be run retroactively across a tenant’s historical reports, recalibrating prior operations to current precision.
Expert review and rapid response
Engagement behavior, scope enforcement, and the validation tier are reviewed by Assail’s own offensive security practitioners, whose job is to find the cases the automated systems miss. New failure patterns are added to ongoing evaluation so the same class of issue is tested for in future releases.
Testing the controls, not only the capability
Benchmarks measure how well Ares finds and proves weaknesses; they say nothing about whether the safety controls hold, so those are tested directly and separately. The control suite probes attempts to direct the agent outside its authorized scope, attempts to egress beyond the harness boundary, prompt-injection payloads planted in target-controlled responses, and attempts to elicit action while in recon-only mode. The pass condition is refusal and containment, not capability, and results are tracked release over release.
Independent assessment
The reviews described above are conducted by Assail’s own practitioners. Independent third-party validation of the platform and its safety controls is identified in this card as an area to complete.
06 · Limitations
Limitations
Stating limitations plainly is part of operating an offensive system responsibly.
Human review is required
Ares augments security teams; it does not replace their judgment. Findings, including chained paths, should be reviewed and prioritized by a qualified practitioner before action.
Coverage is bounded by scope and reach
The system reasons about the surface it is authorized and able to reach. Internal targets require the customer-run Hunt agent, and assets outside the defined scope are not assessed.
Findings are probabilistic
The validation tier and self-heal loop reduce false positives but do not eliminate false positives or false negatives. Absence of a finding is not proof of absence of a weakness.
Benchmarks are indicative
Published figures reflect a capture campaign that was still in progress and an internal lab, run under a defined methodology. They describe capability on those benchmarks, not guaranteed outcomes on any specific system.
Self-heal is a post-operation precision mechanism
It improves the quality of reported findings and the next operation, but it is not a mid-operation guarantee of completion against every environment or defense.
Targets can attempt to manipulate the agent
Because Ares reads attacker-influenceable content, a hostile or compromised target may try to redirect it through injected instructions. Input-integrity controls reduce this risk but do not eliminate it, and novel injection techniques are an active area of testing.
Assurance currently rests largely on self-attestation
The controls and evaluations described here are conducted primarily by Assail. Independent third-party validation of the platform and its safety controls strengthens these claims and is identified in this card as an area to complete.
07 · Governance
Governance, oversight, and access
Ares is governed by a written internal governance framework and by the company-wide expectation that all of Assail’s offensive tooling operates only against authorized targets. Access is controlled and multi-tenant, with role-based permissions, per-tenant isolation, and encryption of data at rest, and the commercial product is kept organizationally separate from Assail’s public-sector mission work.
Oversight extends to the board level, and the platform’s audit trail makes individual operations reviewable after the fact.
Responsible use
Customers agree to use Ares only against authorized targets. The controls in the safety section are the technical expression of that commitment; the license is the contractual one. Both apply at the same time.
Disclosure
Where Ares surfaces weaknesses in third-party software during authorized work, Assail supports coordinated, responsible disclosure to the affected vendor, following a defined disclosure timeline and giving vendors a remediation window before any wider publication.
How authorization is established and verified
Authorization is the precondition for the system to act at all. Every operation is bound to an authenticated operator, an explicit target definition, and rules of engagement captured before the hunt begins; the harness enforces the resulting scope at the network boundary.
Release thresholds and red lines
Assail assesses capability and control together before each release, and will hold or restrict a release that materially widens misuse potential without a corresponding control.
Document history
v1.4, June 2026: initial publication of the Dagger system card.
08 · Summary
Summary
Dagger, the v1.4 model and harness behind Ares, delivers autonomous, evidence-grade red teaming across APIs, web applications, and mobile applications, organized as an orchestrated agent system with a dedicated validation tier and a self-hosted, local-only model. Its capabilities are paired with layered controls anchored by a single principle: people authorize and bound the work, and Ares operates inside those bounds. Capability and control are designed and evaluated together, as properties of the whole system.
See it in action
Put an adversary on your side.
See how Assail can help your team uncover and prove real exposure before attackers do.