System Card / Version 2.0
Sidewinder
The model and harness powering Ares v2.0
Sidewinder is the v2.0 generation of Ares: a new 31B-parameter model on a rebuilt agentic harness, fine-tuned for autonomous offensive security across APIs, web applications, and mobile applications. The model is self-hosted and runs entirely inside the deployment boundary. Everything it does rests on one principle: people authorize and bound the work, and Ares plans and executes within those bounds.
Release
v2.0 / June 2026
Model
31B params · 128k context
Coverage
API · Web · Mobile
Deployment
Self-hosted, local-only
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 that a security team can act on. Sidewinder is the v2.0 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 Sidewinder 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 · Step change
What is new in Sidewinder
Sidewinder is a generational release, not a point update over the v1 line. Four changes define it. Each one widens the system’s capability surface, and each one raised the bar for the safeguards described in the safety section. The capability gains are expected on the basis of the architecture; the v2.0 benchmark re-runs that would quantify them are still in progress.
01
New 31B-parameter model
The model behind Ares moved to a new generation: a 31B-parameter foundation model fine-tuned for offensive security, with separate adapters for execution and reasoning, and a 128k-token context window for long operations.
02
Rebuilt agentic harness
The harness that coordinates the agent system was rebuilt and the model integrated as a swappable component. The harness is where Ares accrues its durable value; the model is the part that can change underneath it.
03
Recursive self-heal in the loop
A recursive self-heal stage now runs after each operation, reviewing findings, suppressing false positives against learned criteria, and writing reusable suppression skills so precision compounds over time.
04
Mobile testing integration
Mobile application testing runs against real devices through an integrated device cloud with AI-driven test authoring. In the v2.0 release this integration is being migrated onto the rebuilt platform and is still maturing, so mobile coverage should be read as a developing capability rather than one at parity with web and API.
Naming note
Figures and capability claims in this card describe the v2.0 generation. Where a benchmark has not yet been re-run on the v2.0 model, this card says so rather than carrying a number forward from the prior model.
03 · 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
Sidewinder’s model is a 31B-parameter, open-weights foundation model fine-tuned for offensive security work, with distinct adapters tuned for execution and for reasoning so the system can both carry out steps and plan over them. It supports a 128k-token context window for long, multi-step operations. The model is self-hosted and runs locally inside the deployment boundary; target data and findings do not leave the customer or operator environment to a third-party model provider. This local-only posture is a deliberate architectural invariant, not a deployment option.
Model specifications
Sidewinder v2.0
Base lineage
Open-weights foundation model
Parameters
31B
Context window
128k tokens
Fine-tuning
Curated offensive-security datasets
Adapters
Execution + reasoning
Deployment
Self-hosted, local-only inference
Training data and customer-data handling
Sidewinder 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 recursive 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. In the v2.0 release the harness was rebuilt and the model generation changed together, around the same durable design; the swappable-model architecture is what makes a change of that size manageable. Because both changed at once, this release is not by itself a demonstration of swapping the model under an unchanged harness. Capability, evaluation, and safety are therefore measured as properties of the whole system 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 recursive self-heal loop feeds precision back into the next run.
Reconnaissance
Surface mapping
Detection
Candidate findings
Exploitation
Confirm in scope
Chaining
Kill-chain
The agent roster
The orchestrator, Polemos, decomposes the authorized objective into tasks and coordinates a roster of specialized agents whose functional roles are reconnaissance, detection, exploitation, and chaining. A dedicated vulnerability-chaining agent assembles individually confirmed findings into an interactive kill-chain so impact is demonstrated end to end rather than as a list of isolated issues. In the product these functional roles are surfaced to operators under a set of mythologically named personas; the personas are presentation labels and do not change the bounded, validator-gated behavior described in this card.
Shared knowledge and self-improvement
All agents read from and contribute to a shared knowledge layer that combines a knowledge graph, vector search, and graph-based retrieval, so context discovered by one agent is available to the rest. After an operation completes, the recursive self-heal stage reviews the findings, applies learned false-positive suppression, and writes reusable suppression skills back into a shared store, so the precision of the next operation benefits from the last. Training of the model itself is done by fine-tuning on curated offensive-security datasets; the self-heal loop is the runtime mechanism that keeps precision improving in production.
04 · 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 · baseline (prior model)
92.5%
37 of 40 CVEs exploited under the prior-generation model. The v2.0 Sidewinder re-run is in progress.
XBOW · baseline (prior model)
58 / 86
58 flags captured, with 86 detected of the 87 buildable images (17 of 104 do not build), under the prior-generation model. The v2.0 re-run is in progress.
Methodology. Baseline figures are real measurements of the harness running the prior-generation Dagger v1.4 model on a frozen mid-June 2026 snapshot, reported as a single end-to-end run per challenge (pass@1) under white-box access to the target, with no per-target hardcoding; the XBOW baseline is an interim snapshot of a capture campaign that had not finished. They are shown for continuity and are not Sidewinder results. The v2.0 Sidewinder re-runs are in progress and have no final figure yet, so no v2.0 number is presented. This card does not carry a prior-model number forward as if it were a v2.0 result.
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.
05 · Safety
Safety, authorization, and misuse mitigations
An autonomous offensive system carries obvious dual-use risk, and Sidewinder is a larger model than the one it replaces and is expected to be more capable, though its v2.0 capability evaluations are still in progress. The answer to that risk 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 greater 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. The larger v2.0 context window makes disciplined handling of untrusted input more important, not less.
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.
06 · Robustness
Red teaming and robustness
Controls are only meaningful if they hold under pressure, and Sidewinder’s larger model and rebuilt harness widened what had to be tested before release.
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. Because Sidewinder is a larger model on a rebuilt harness, this suite was re-run against the v2.0 system before release, and results are tracked release over release so a closed control gap is regression-tested.
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.
07 · Limitations
Limitations
Stating limitations plainly is part of operating an offensive system responsibly. Sidewinder’s added capability does not remove any of them.
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 and partly in progress
Published baselines reflect the harness on the prior-generation model and, for XBOW, a capture campaign that was still running. The v2.0 re-runs are not yet complete, so this card does not present a final v2.0 benchmark figure.
Mobile testing is maturing in v2.0
Mobile coverage runs through an integrated real-device cloud and is being extended into the rebuilt platform, so its behavior on unusual mobile targets is still being broadened.
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 the larger v2.0 context window keeps this 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.
08 · 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. Sidewinder is a deliberate test of this commitment: a larger model was paired with the additional controls described in the safety section before it shipped.
Document history
v2.0 (Sidewinder), June 2026: new 31B model, rebuilt harness, recursive self-heal, and mobile integration migrating onto the rebuilt platform; v2.0 benchmark re-runs in progress at publication. Supersedes v1.4 (Dagger).
Summary
Summary
Sidewinder is a larger capability paired with tighter controls. The v2.0 model and rebuilt harness deliver 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. All of it is anchored by a single principle: people authorize and bound the work, and Ares operates inside those bounds.
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.