Assail home

ASSAIL RESEARCH / MODEL CARD

Ares Version 2
Sidewinder Model Card

Model lineage, fine-tuning approach, evaluation evidence, and limitations of Assail’s domain-adapted security model.

Request a Demo

Read model card

MODEL, IN CONTEXT

Model lineage, evaluation evidence, and documented limitations.

ASSAIL RESEARCH / MODEL CARD

Ares Version 2
Sidewinder Model Card

Model lineage, fine-tuning approach, evaluation evidence, and limitations of Assail’s domain-adapted security model.

Request a Demo

Read model card

MODEL, IN CONTEXT

Model lineage, evaluation evidence, and documented limitations.

ASSAIL RESEARCH / MODEL CARD

Ares Version 2
Sidewinder Model Card

Model lineage, fine-tuning approach, evaluation evidence, and limitations of Assail’s domain-adapted security model.

Request a Demo

Read model card

MODEL, IN CONTEXT

Model lineage, evaluation evidence, and documented limitations.

VERSION 1.0: DRAFT

PREPARED 17 OCT 2026

TECHNICAL REVIEW

SIDEWINDER

Capabilities

Sidewinder is Assail’s domain-adapted model for authorized security assessment. It is based on Google’s Gemma 4 31B instruction-tuned model, identified in the training repository as google/gemma-4-31B-it.

Sidewinder helps generate and evaluate hypotheses from security observations, select tools and arguments, adapt after unsuccessful tests, and propose evidence-grounded findings. It is designed for authorized engagements, controlled labs, and security research.

Read more

SIDEWINDER

Capabilities

Sidewinder is Assail’s domain-adapted model for authorized security assessment. It is based on Google’s Gemma 4 31B instruction-tuned model, identified in the training repository as google/gemma-4-31B-it.

Sidewinder helps generate and evaluate hypotheses from security observations, select tools and arguments, adapt after unsuccessful tests, and propose evidence-grounded findings. It is designed for authorized engagements, controlled labs, and security research.

Read more

SIDEWINDER

Capabilities

Sidewinder is Assail’s domain-adapted model for authorized security assessment. It is based on Google’s Gemma 4 31B instruction-tuned model, identified in the training repository as google/gemma-4-31B-it.

Sidewinder helps generate and evaluate hypotheses from security observations, select tools and arguments, adapt after unsuccessful tests, and propose evidence-grounded findings. It is designed for authorized engagements, controlled labs, and security research.

Read more

TRAINING / CONFIGURATION

Adapt the behavior. Preserve the base.

Sidewinder’s documented training pipeline keeps the base weights frozen and adapts the model through LoRA. Supervised fine-tuning develops security reasoning and tool-use behavior; direct preference optimization distinguishes better responses from weaker ones.

Configuration

Documented setting

LoRA rank / alpha

32 / 64

SFT learning rate

0.0002

DPO learning rate

0.000005

Sequence lengths

4,096 SFT / 2,304 DPO tokens

Training compute

Four NVIDIA H200 GPUs

Precision

BF16 mixed-precision

The internal v7rl name refers to a further model-derived data round. The documented procedure remains offline SFT followed by DPO; it should not be described as PPO, GRPO, or an online reinforcement-learning run.

TRAINING / CONFIGURATION

Adapt the behavior. Preserve the base.

Sidewinder’s documented training pipeline keeps the base weights frozen and adapts the model through LoRA. Supervised fine-tuning develops security reasoning and tool-use behavior; direct preference optimization distinguishes better responses from weaker ones.

Configuration

Documented setting

LoRA rank / alpha

32 / 64

SFT learning rate

0.0002

DPO learning rate

0.000005

Sequence lengths

4,096 SFT / 2,304 DPO tokens

Training compute

Four NVIDIA H200 GPUs

Precision

BF16 mixed-precision

The internal v7rl name refers to a further model-derived data round. The documented procedure remains offline SFT followed by DPO; it should not be described as PPO, GRPO, or an online reinforcement-learning run.

TRAINING / CONFIGURATION

Adapt the behavior. Preserve the base.

Sidewinder’s documented training pipeline keeps the base weights frozen and adapts the model through LoRA. Supervised fine-tuning develops security reasoning and tool-use behavior; direct preference optimization distinguishes better responses from weaker ones.

Configuration

Documented setting

LoRA rank / alpha

32 / 64

SFT learning rate

0.0002

DPO learning rate

0.000005

Sequence lengths

4,096 SFT / 2,304 DPO tokens

Training compute

Four NVIDIA H200 GPUs

Precision

BF16 mixed-precision

The internal v7rl name refers to a further model-derived data round. The documented procedure remains offline SFT followed by DPO; it should not be described as PPO, GRPO, or an online reinforcement-learning run.

01 / MODEL LINEAGE & PROVENANCE

Domain-adapted security model

Sidewinder is Assail’s domain-adapted model for authorized security assessment, based on Google’s Gemma 4 31B instruction-tuned model (google/gemma-4-31B-it), documented as ares-v7-rl or ares-v7rl. Use and delivery remain subject to base-model terms, third-party data obligations, and Assail agreements; this card grants no redistribution license. Traceability should identify base and adapter artifacts, dataset manifests, serving derivatives, and evaluation protocol. Harness-only releases retain this lineage unless weights change.

02 / AUTHORIZED USE

Security reasoning and tool selection

Sidewinder helps generate and evaluate hypotheses from security observations, select tools and arguments, adapt after unsuccessful tests, and propose evidence-grounded findings. It is designed for authorized engagements, controlled labs, and security research. Sidewinder is not evaluated as a general-purpose assistant, a guarantee of vulnerability coverage, or an independent decision-maker for high-impact actions.

03 / ADAPTATION

A unified LoRA adapter

The documented pipeline freezes the base weights and trains LoRA adapters. Earlier experiments used separate executor and reasoner adapters. From internal revision v5 onward, the documented design uses one unified adapter for both roles. The internal v7rl name refers to a further model-derived data round. The documented procedure remains offline SFT followed by DPO; it should not be described as PPO, GRPO, or an online reinforcement-learning run.

04 / FINE-TUNING

Supervised learning and preferences

Examples teach tool use, argument selection, security reasoning, adaptation, and engagement with authorized tasks. Preference pairs distinguish better and worse behavior, including clarification before dispatch, multi-step completion, and grounded conclusions. LoRA rank / alpha: 32 / 64. SFT learning rate: 0.0002; DPO: 0.000005. Sequence lengths: 4,096 / 2,304 tokens. Four NVIDIA H200 GPUs; BF16 mixed precision.

05 / TRAINING DATA

Mixed sources, explicit disclosure limits

The documented preparation pipeline combines public instruction and function-calling datasets, security writeups, controlled examples, internally authored examples, synthetic augmentations, and preference pairs. Exact final checkpoint-linked data composition, license clearance, and customer-data policy are not established by this card. Public accessibility alone does not establish permission for every training or redistribution use.

06 / EVALUATION

Three independent evaluation axes

The model repository defines three independent evaluation axes. The documented automated judge is GPT-4.1 at temperature zero. These are internal development evaluations with model-graded outputs, not independent certification or measurements of end-to-end vulnerability discovery. No release-qualified headline tool-calling or reasoning score is claimed. Historical evaluation changes affect comparability, and numerical comparisons require a consistent evaluation revision and matched checkpoint identities.

07 / EVALUATION COVERAGE

Tool calling, reasoning, and refusal

Tool calling: 97 scenarios covering format, tools, arguments, dispatch, clarification, and multi-step chains. Reasoning: 108 scenarios covering evidence, inference, next actions, and unsupported claims. Refusal tests cover benign tasks, authorized security tasks, and harmful-request sets. These are internal development evaluations, not independent certification.

08 / SERVING

Merged weights and local derivatives

The serving repository documents vLLM-based inference, with the fine-tuned adapter merged into the base for the production serving path. Training-time multi-LoRA evaluation and production merged-weight serving are different configurations. Some local deployments use an FP8 derivative to fit hardware and memory requirements. Quantization is a deployment transformation, not new domain fine-tuning; it may still affect model behavior, so quality equivalence to BF16 requires separate evaluation.

09 / SYSTEM BOUNDARY

The harness retains execution authority

The model does not execute network operations by itself. Execution authority, target scope, credentials, available tools, budgets, and operational controls belong to the surrounding system and are described in the Hellfire System Card. Behavior depends on prompts, parsers, tool schemas, context handling, generation settings, and the surrounding harness. A tool-calling score cannot be carried unchanged into a different tool registry or runtime.

10 / LIMITATIONS

Model outputs still require controls

Sidewinder can infer incorrectly, invent unsupported details, select the wrong tool, or choose unsuitable arguments. Training examples and evaluation tasks may not represent unfamiliar application designs, protocols, business rules, languages, or identity systems. Synthetic data and automated judging can propagate generator preferences and grading errors. Refusal behavior is imperfect and cannot authenticate authorization; enforced system controls remain necessary. Longer context, lower precision, different serving hardware, or a different harness can change observed behavior.

01 / MODEL LINEAGE & PROVENANCE

Domain-adapted security model

Sidewinder is Assail’s domain-adapted model for authorized security assessment, based on Google’s Gemma 4 31B instruction-tuned model (google/gemma-4-31B-it), documented as ares-v7-rl or ares-v7rl. Use and delivery remain subject to base-model terms, third-party data obligations, and Assail agreements; this card grants no redistribution license. Traceability should identify base and adapter artifacts, dataset manifests, serving derivatives, and evaluation protocol. Harness-only releases retain this lineage unless weights change.

02 / AUTHORIZED USE

Security reasoning and tool selection

Sidewinder helps generate and evaluate hypotheses from security observations, select tools and arguments, adapt after unsuccessful tests, and propose evidence-grounded findings. It is designed for authorized engagements, controlled labs, and security research. Sidewinder is not evaluated as a general-purpose assistant, a guarantee of vulnerability coverage, or an independent decision-maker for high-impact actions.

03 / ADAPTATION

A unified LoRA adapter

The documented pipeline freezes the base weights and trains LoRA adapters. Earlier experiments used separate executor and reasoner adapters. From internal revision v5 onward, the documented design uses one unified adapter for both roles. The internal v7rl name refers to a further model-derived data round. The documented procedure remains offline SFT followed by DPO; it should not be described as PPO, GRPO, or an online reinforcement-learning run.

04 / FINE-TUNING

Supervised learning and preferences

Examples teach tool use, argument selection, security reasoning, adaptation, and engagement with authorized tasks. Preference pairs distinguish better and worse behavior, including clarification before dispatch, multi-step completion, and grounded conclusions. LoRA rank / alpha: 32 / 64. SFT learning rate: 0.0002; DPO: 0.000005. Sequence lengths: 4,096 / 2,304 tokens. Four NVIDIA H200 GPUs; BF16 mixed precision.

05 / TRAINING DATA

Mixed sources, explicit disclosure limits

The documented preparation pipeline combines public instruction and function-calling datasets, security writeups, controlled examples, internally authored examples, synthetic augmentations, and preference pairs. Exact final checkpoint-linked data composition, license clearance, and customer-data policy are not established by this card. Public accessibility alone does not establish permission for every training or redistribution use.

06 / EVALUATION

Three independent evaluation axes

The model repository defines three independent evaluation axes. The documented automated judge is GPT-4.1 at temperature zero. These are internal development evaluations with model-graded outputs, not independent certification or measurements of end-to-end vulnerability discovery. No release-qualified headline tool-calling or reasoning score is claimed. Historical evaluation changes affect comparability, and numerical comparisons require a consistent evaluation revision and matched checkpoint identities.

07 / EVALUATION COVERAGE

Tool calling, reasoning, and refusal

Tool calling: 97 scenarios covering format, tools, arguments, dispatch, clarification, and multi-step chains. Reasoning: 108 scenarios covering evidence, inference, next actions, and unsupported claims. Refusal tests cover benign tasks, authorized security tasks, and harmful-request sets. These are internal development evaluations, not independent certification.

08 / SERVING

Merged weights and local derivatives

The serving repository documents vLLM-based inference, with the fine-tuned adapter merged into the base for the production serving path. Training-time multi-LoRA evaluation and production merged-weight serving are different configurations. Some local deployments use an FP8 derivative to fit hardware and memory requirements. Quantization is a deployment transformation, not new domain fine-tuning; it may still affect model behavior, so quality equivalence to BF16 requires separate evaluation.

09 / SYSTEM BOUNDARY

The harness retains execution authority

The model does not execute network operations by itself. Execution authority, target scope, credentials, available tools, budgets, and operational controls belong to the surrounding system and are described in the Hellfire System Card. Behavior depends on prompts, parsers, tool schemas, context handling, generation settings, and the surrounding harness. A tool-calling score cannot be carried unchanged into a different tool registry or runtime.

10 / LIMITATIONS

Model outputs still require controls

Sidewinder can infer incorrectly, invent unsupported details, select the wrong tool, or choose unsuitable arguments. Training examples and evaluation tasks may not represent unfamiliar application designs, protocols, business rules, languages, or identity systems. Synthetic data and automated judging can propagate generator preferences and grading errors. Refusal behavior is imperfect and cannot authenticate authorization; enforced system controls remain necessary. Longer context, lower precision, different serving hardware, or a different harness can change observed behavior.

01 / MODEL LINEAGE

Domain-adapted security model

Based on Google Gemma 4 31B instruction-tuned weights, with LoRA adaptation for authorized security assessment. Internal adapter revisions are distinct from product generations.

02 / AUTHORIZED USE

Security reasoning and tool selection

Develop hypotheses, select tools and arguments, adapt after unsuccessful tests, and propose evidence-grounded findings in authorized engagements and controlled labs.

03 / ADAPTATION

A unified LoRA adapter

Base weights remain frozen while a unified LoRA adapter is trained. The documented procedure is offline SFT followed by DPO, not online reinforcement learning.

04 / FINE-TUNING

Supervised learning and preferences

Supervised examples teach tool use and security reasoning. Preference pairs reward clarification, multi-step completion, and grounded conclusions.

05 / TRAINING DATA

Mixed sources, explicit disclosure limits

Training combines public, internal, controlled, and synthetic examples. Final checkpoint-linked composition, license clearance, and customer-data policy are not established by this card.

06 / EVALUATION

Three independent evaluation axes

Internal, model-graded evaluations cover tool calling, reasoning, and refusal. They are not independent certification or end-to-end discovery measurements.

07 / EVALUATION COVERAGE

Tool calling, reasoning, and refusal

Tool calling covers 97 scenarios; reasoning covers 108. Refusal evaluation includes benign, authorized-security, and harmful-request sets. No release-qualified headline score is claimed.

08 / SERVING

Merged weights and local derivatives

Production serving uses merged weights through vLLM. Some local installations use FP8 derivatives; equivalence to BF16 requires separate evaluation.

09 / SYSTEM BOUNDARY

The harness retains execution authority

The harness owns execution, scope, credentials, tools, and budgets. Model behavior also depends on prompts, parsing, context, generation settings, and runtime.

10 / LIMITATIONS

Model outputs still require controls

Sidewinder can infer incorrectly, invent details, or select unsuitable tools. Refusal cannot establish authorization. Enforced controls and review remain necessary.

11 / PROVENANCE

Licensing and artifact traceability

Base-model terms, data obligations, and product agreements apply. This card does not permit weight redistribution. Revisions should identify artifacts and evaluation protocols.

EVALUATION / INTERPRETATION

Evidence with a defined boundary.

A useful evaluation explains what was tested, and what the result cannot establish. Sidewinder’s model repository separates tool calling, reasoning, and refusal behavior rather than presenting one score as a measure of the entire security system.

Evaluation axis

What is examined

Tool calling · 97 scenarios

Correct format, tool, arguments, dispatch behavior, clarification, and multi-step chains.

Reasoning · 108 scenarios

Problem identification, inference from evidence, sensible next action, and avoidance of unsupported claims.

Refusal · source-specific

False refusals of benign tasks, authorized security-task engagement, and behavior on harmful-request sets.

The model repository defines three independent evaluation axes. The documented automated judge is GPT-4.1 at temperature zero. These are internal development evaluations with model-graded outputs, not independent certification or measurements of end-to-end vulnerability discovery.

No release-qualified headline tool-calling or reasoning score is claimed. Historical evaluation changes affect comparability, and numerical comparisons require a consistent evaluation revision and matched checkpoint identities. Behavior depends on prompts, parsers, tool schemas, context handling, generation settings, and the surrounding harness. A tool-calling score cannot be carried unchanged into a different tool registry or runtime.

EVALUATION / INTERPRETATION

Evidence with a defined boundary.

A useful evaluation explains what was tested, and what the result cannot establish. Sidewinder’s model repository separates tool calling, reasoning, and refusal behavior rather than presenting one score as a measure of the entire security system.

Evaluation axis

What is examined

Tool calling · 97 scenarios

Correct format, tool, arguments, dispatch behavior, clarification, and multi-step chains.

Reasoning · 108 scenarios

Problem identification, inference from evidence, sensible next action, and avoidance of unsupported claims.

Refusal · source-specific

False refusals of benign tasks, authorized security-task engagement, and behavior on harmful-request sets.

The model repository defines three independent evaluation axes. The documented automated judge is GPT-4.1 at temperature zero. These are internal development evaluations with model-graded outputs, not independent certification or measurements of end-to-end vulnerability discovery.

No release-qualified headline tool-calling or reasoning score is claimed. Historical evaluation changes affect comparability, and numerical comparisons require a consistent evaluation revision and matched checkpoint identities. Behavior depends on prompts, parsers, tool schemas, context handling, generation settings, and the surrounding harness. A tool-calling score cannot be carried unchanged into a different tool registry or runtime.

EVALUATION / INTERPRETATION

Evidence with a defined boundary.

A useful evaluation explains what was tested, and what the result cannot establish. Sidewinder’s model repository separates tool calling, reasoning, and refusal behavior rather than presenting one score as a measure of the entire security system.

Evaluation axis

What is examined

Tool calling · 97 scenarios

Correct format, tool, arguments, dispatch behavior, clarification, and multi-step chains.

Reasoning · 108 scenarios

Problem identification, inference from evidence, sensible next action, and avoidance of unsupported claims.

Refusal · source-specific

False refusals of benign tasks, authorized security-task engagement, and behavior on harmful-request sets.

The model repository defines three independent evaluation axes. The documented automated judge is GPT-4.1 at temperature zero. These are internal development evaluations with model-graded outputs, not independent certification or measurements of end-to-end vulnerability discovery.

No release-qualified headline tool-calling or reasoning score is claimed. Historical evaluation changes affect comparability, and numerical comparisons require a consistent evaluation revision and matched checkpoint identities. Behavior depends on prompts, parsers, tool schemas, context handling, generation settings, and the surrounding harness. A tool-calling score cannot be carried unchanged into a different tool registry or runtime.

TALK TO ASSAIL

Put the model in context.

Discuss Sidewinder, its evaluation boundaries, and its role within the Ares system.

Your environment. Your objectives. A mission built around both.

https://api.peec.ai/agent-analytics/generic-access-log