Ares / System Card / 1.0 Draft
Ares Version 3 Hellfire advances the software system around Assail’s fine-tuned Sidewinder model. The release identity refers to the platform and execution harness: orchestration, tools, authentication workflows, evidence handling, operating controls, and deployment infrastructure that turn model outputs into security assessments.
CONTROLLED EXECUTION
The Hellfire harness, powered by the Sidewinder model.
Ares / System Card / 1.0 Draft
Ares Version 3 Hellfire advances the software system around Assail’s fine-tuned Sidewinder model. The release identity refers to the platform and execution harness: orchestration, tools, authentication workflows, evidence handling, operating controls, and deployment infrastructure that turn model outputs into security assessments.
CONTROLLED EXECUTION
The Hellfire harness, powered by the Sidewinder model.
Ares / System Card / 1.0 Draft
Ares Version 3 Hellfire advances the software system around Assail’s fine-tuned Sidewinder model. The release identity refers to the platform and execution harness: orchestration, tools, authentication workflows, evidence handling, operating controls, and deployment infrastructure that turn model outputs into security assessments.
CONTROLLED EXECUTION
The Hellfire harness, powered by the Sidewinder model.
The Hellfire harness, powered by the Sidewinder model.
The Hellfire harness, powered by the Sidewinder model.
Release
Ares Version 3 Hellfire
Prepared
October 17, 2026
Status
Draft for technical review
RELEASE / LINEAGE
Product generations and model revisions are separate identifiers. Hellfire evolves the surrounding software without additional fine-tuning or new model weights.
Ares Version 1 Dagger
Assail fine-tune of Qwen3-14B, a 14-billion-parameter base. First model generation.
Ares Version 2 Sidewinder
Assail fine-tune of the Gemma 4 31B instruction-tuned base. New base-model family and new fine-tuning.
Ares Version 3 Hellfire
Retains Sidewinder. Harness, scaffolding, and platform evolution, not an additional fine-tune.
A product label in the interface does not by itself identify a distinct checkpoint or serving deployment.
RELEASE / LINEAGE
Product generations and model revisions are separate identifiers. Hellfire evolves the surrounding software without additional fine-tuning or new model weights.
Ares Version 1 Dagger
Assail fine-tune of Qwen3-14B, a 14-billion-parameter base. First model generation.
Ares Version 2 Sidewinder
Assail fine-tune of the Gemma 4 31B instruction-tuned base. New base-model family and new fine-tuning.
Ares Version 3 Hellfire
Retains Sidewinder. Harness, scaffolding, and platform evolution, not an additional fine-tune.
A product label in the interface does not by itself identify a distinct checkpoint or serving deployment.
RELEASE / LINEAGE
Product generations and model revisions are separate identifiers. Hellfire evolves the surrounding software without additional fine-tuning or new model weights.
Ares Version 1 Dagger
Assail fine-tune of Qwen3-14B, a 14-billion-parameter base. First model generation.
Ares Version 2 Sidewinder
Assail fine-tune of the Gemma 4 31B instruction-tuned base. New base-model family and new fine-tuning.
Ares Version 3 Hellfire
Retains Sidewinder. Harness, scaffolding, and platform evolution, not an additional fine-tune.
A product label in the interface does not by itself identify a distinct checkpoint or serving deployment.
SYSTEM / BOUNDARY
The model and the integrated system have different responsibilities. This responsibility map describes the architecture, not a measured performance comparison or a sequential workflow.
MODEL · SIDEWINDER
Reasoning, proposed actions, and tool calls.
HARNESS · HELLFIRE
Scheduling and specialist tasks; supported tool execution; identity verification; scope and budget enforcement.
SYSTEM CONTEXT
State and evidence; operator configuration and run controls; model serving, workers, storage, and supporting services.
Model evaluation
Sidewinder tests assess individual reasoning, tool-calling, and refusal behavior.
Harness evaluation
Integrated-system tests use reachable targets and known ground truth.
Evidence limit
No verified Hellfire-versus-Sidewinder performance uplift is reported. The reviewed records do not establish a matched release-to-release evaluation holding the underlying model and other relevant conditions constant.
SYSTEM / BOUNDARY
The model and the integrated system have different responsibilities. This responsibility map describes the architecture, not a measured performance comparison or a sequential workflow.
MODEL · SIDEWINDER
Reasoning, proposed actions, and tool calls.
HARNESS · HELLFIRE
Scheduling and specialist tasks; supported tool execution; identity verification; scope and budget enforcement.
SYSTEM CONTEXT
State and evidence; operator configuration and run controls; model serving, workers, storage, and supporting services.
Model evaluation
Sidewinder tests assess individual reasoning, tool-calling, and refusal behavior.
Harness evaluation
Integrated-system tests use reachable targets and known ground truth.
Evidence limit
No verified Hellfire-versus-Sidewinder performance uplift is reported. The reviewed records do not establish a matched release-to-release evaluation holding the underlying model and other relevant conditions constant.
SYSTEM / BOUNDARY
The model and the integrated system have different responsibilities. This responsibility map describes the architecture, not a measured performance comparison or a sequential workflow.
MODEL · SIDEWINDER
Reasoning, proposed actions, and tool calls.
HARNESS · HELLFIRE
Scheduling and specialist tasks; supported tool execution; identity verification; scope and budget enforcement.
SYSTEM CONTEXT
State and evidence; operator configuration and run controls; model serving, workers, storage, and supporting services.
Model evaluation
Sidewinder tests assess individual reasoning, tool-calling, and refusal behavior.
Harness evaluation
Integrated-system tests use reachable targets and known ground truth.
Evidence limit
No verified Hellfire-versus-Sidewinder performance uplift is reported. The reviewed records do not establish a matched release-to-release evaluation holding the underlying model and other relevant conditions constant.
HELLFIRE
Hellfire is the execution harness around Sidewinder. It coordinates authorized web, API, mobile, and supported AI assessments alongside attack surface management and Shadow AI discovery, with applicable MITRE ATLAS coverage.
Tools, identities, evidence, and operating controls remain governed by the harness.
Read more
HELLFIRE
Hellfire is the execution harness around Sidewinder. It coordinates authorized web, API, mobile, and supported AI assessments alongside attack surface management and Shadow AI discovery, with applicable MITRE ATLAS coverage.
Tools, identities, evidence, and operating controls remain governed by the harness.
Read more
HELLFIRE
Hellfire is the execution harness around Sidewinder. It coordinates authorized web, API, mobile, and supported AI assessments alongside attack surface management and Shadow AI discovery, with applicable MITRE ATLAS coverage.
Tools, identities, evidence, and operating controls remain governed by the harness.
Read more
Investigate whether an exposure can be reproduced, collect evidence, and prioritize remediation across web applications, APIs, mobile application workflows, and supported AI surfaces. Assessments may use an anonymous perspective or operator-provided identities. Coverage depends on permissions, credentials, enabled modules, network position, and deployment configuration.
The harness orders assessment phases and assigns specialist tasks. Deterministic scheduling provides a baseline task pool; model-assisted planning can propose additional work based on observed surface and the assessment objective. The Sidewinder model proposes reasoning, actions, and tool calls; the surrounding software controls execution.
The harness establishes and verifies identities before assigning authenticated tasks. Supported workflows include token-based access and browser-based sign-in, with operator-assisted interactive login for identity-provider flows that need a human. MFA, expired sessions, identity-provider restrictions, and handoff requirements can limit or interrupt testing.
The tool layer executes supported HTTP, browser, identity, and constrained command operations. Target authorization, host and URL restrictions, role-scoped tools, explicit module selection, and execution budgets apply outside the model. Some command execution is separately enabled and constrained by the runtime.
Hellfire includes an AI assessment lane with reconnaissance and probes selected for supported AI surfaces. Intrusive MCP/RAG probes and cost-oriented modules require explicit selection. Software-enforced budgets apply inference-call, output-token, and endpoint limits.
The harness connects findings to captured exchanges and uses comparison requests to distinguish a vulnerability signal from ordinary application behavior. Reports organize findings and supporting evidence for review. Model outputs and verification logic can still produce false positives or miss real vulnerabilities; evidence requires human review.
Context fitting trims older conversation content to preserve space for current work and output. Retry and error-handling paths address supported transient failures, while resource and task budgets constrain execution. Limits, missing credentials, unreachable endpoints, unsupported protocols, and application state can leave exposures untested.
Operators can pause supported runs or stop them. A pause takes effect at an execution boundary, so work already in flight may finish first. Stopping ends the run and does not reverse actions already taken. Assessment traffic may consume capacity, create test data, trigger account controls, or change application state.
Assessment data may include target configuration, supplied identities, requests and responses, findings, reports, and extracted application data. Organization-scoped access controls and encryption mechanisms are implemented; credential and key-custody options depend on configuration. Retention, deletion, processor access, and reuse permissions depend on the applicable Privacy Policy, agreement, and deployment configuration.
Target responses, pages, files, and AI outputs can contain misleading instructions or prompt injection. Local inference, isolation, offline operation, and key custody must be verified in the deployed environment. Behavior on one precision, hardware platform, target, or benchmark does not establish equivalence elsewhere.
Validate exposures across supported web, API, mobile, and AI surfaces. Coverage depends on scope, permissions, credentials, modules, network position, and configuration.
Deterministic scheduling supplies baseline tasks. Model-assisted planning proposes additional work from observed surface and objectives. The harness controls execution.
Identities are verified before authenticated work. Token access, browser sign-in, and supported operator-assisted login are available; MFA and sessions can limit testing.
Supported HTTP, browser, identity, and constrained command operations run under host and URL scope restrictions, role-scoped tools, module selection, and budgets.
Supported AI surfaces have a dedicated assessment lane. Intrusive MCP/RAG and cost-oriented probes require explicit selection. Inference, token, and endpoint budgets apply.
Captured exchanges and comparison requests support findings. Reports organize evidence for human review; false positives and missed vulnerabilities remain possible.
Context fitting, supported retries, and resource limits manage execution. Unreachable endpoints, missing credentials, unsupported protocols, and limits can leave gaps.
Pause applies at an execution boundary; in-flight work may finish. Stop ends a run but does not reverse actions. Tests can consume capacity or change target state.
Evidence may contain sensitive data. Access and encryption controls apply; key custody, retention, deletion, and reuse permissions depend on configuration and agreements.
Hostile content may contain prompt injection. Verify local inference, isolation, offline operation, and key custody. One tested configuration does not establish equivalence elsewhere.
DEPLOYMENT / ASSURANCE
Ares has an Assail-hosted service path and customer-environment deployment paths. Availability and verification must be stated for the specific release artifact and environment.
SaaS
Application and model inference use the configured Assail-hosted infrastructure.
Customer cloud / BYOC
The model boundary depends on the selected deployment configuration. Customer-hosted application components alone do not establish local inference.
On-premises / local inference
Model serving and required supporting services are provisioned within the customer’s approved boundary.
Disconnected customer-operated Site
Requires local model serving, packaged dependencies, offline entitlement and update provisions, and reachable in-scope targets.
Release records should identify the product build, harness revision, model artifact, serving configuration, enabled modules, and evaluation revision separately. Changes to tool authority, scope enforcement, authentication, or deployment boundaries warrant a system-card update even when the model remains unchanged.
Companion document: Sidewinder Model Card.
DEPLOYMENT / ASSURANCE
Ares has an Assail-hosted service path and customer-environment deployment paths. Availability and verification must be stated for the specific release artifact and environment.
SaaS
Application and model inference use the configured Assail-hosted infrastructure.
Customer cloud / BYOC
The model boundary depends on the selected deployment configuration. Customer-hosted application components alone do not establish local inference.
On-premises / local inference
Model serving and required supporting services are provisioned within the customer’s approved boundary.
Disconnected customer-operated Site
Requires local model serving, packaged dependencies, offline entitlement and update provisions, and reachable in-scope targets.
Release records should identify the product build, harness revision, model artifact, serving configuration, enabled modules, and evaluation revision separately. Changes to tool authority, scope enforcement, authentication, or deployment boundaries warrant a system-card update even when the model remains unchanged.
Companion document: Sidewinder Model Card.
DEPLOYMENT / ASSURANCE
Ares has an Assail-hosted service path and customer-environment deployment paths. Availability and verification must be stated for the specific release artifact and environment.
SaaS
Application and model inference use the configured Assail-hosted infrastructure.
Customer cloud / BYOC
The model boundary depends on the selected deployment configuration. Customer-hosted application components alone do not establish local inference.
On-premises / local inference
Model serving and required supporting services are provisioned within the customer’s approved boundary.
Disconnected customer-operated Site
Requires local model serving, packaged dependencies, offline entitlement and update provisions, and reachable in-scope targets.
Release records should identify the product build, harness revision, model artifact, serving configuration, enabled modules, and evaluation revision separately. Changes to tool authority, scope enforcement, authentication, or deployment boundaries warrant a system-card update even when the model remains unchanged.
Companion document: Sidewinder Model Card.
TALK TO ASSAIL
Explore harness controls, deployment requirements, and verification for your environment.
Your environment. Your objectives. A mission built around both.
