DYMORPIC
INDEPENDENT AI ASSURANCEBUILT FOR THE UNEXPECTED ↘

INTELLIGENCE IS NOT THE SAME AS RELIABILITY.

KNOW WHAT
BREAKS.

We build systems that challenge intelligent systems—making failure visible, testable, and easier to understand.

EXPLORE PROJECTILE OUR APPROACH
RESEARCH → SYSTEMS → EVIDENCESCROLL TO EXPLORE
DEFINE THE OBJECTIVECHALLENGE THE SYSTEMOBSERVE THE RESPONSESEXAMINE THE FAILURESREPORT WITH EVIDENCEDEFINE THE OBJECTIVECHALLENGE THE SYSTEMOBSERVE THE RESPONSESEXAMINE THE FAILURESREPORT WITH EVIDENCE

THE EVALUATION GAP

AI behavior depends
on more than the model.

Instructions, retrieved content, tools, and multi-step interactions can all influence how an AI system behaves. A model-level check alone may not reveal how the complete application responds under pressure.

Evaluation has to reach the system around the model—the instructions it receives, the information it is given, the actions it can take, and the way those elements combine in real use.

WHAT SURROUNDS THE MODEL SHAPES WHAT THE SYSTEM DOES

PROJECTILE / IN PROTOTYPE

Evaluate behavior.
Examine failures.
Preserve the evidence.

PROJECTILE challenges intelligent systems to expose potential weaknesses, examines candidate failures, and supports evidence-led evaluation. It is being built to evaluate AI systems against defined objectives, record observed behavior, and preserve the evidence needed to assess what occurred.

The objective is to distinguish a potential failure from a finding supported by evidence—and to preserve an inconclusive outcome when the available evidence is insufficient.

EXPLORE PROJECTILE

CORE CAPABILITIES

Built to press
on what holds.

Find vulnerabilities
within an hour.

PROJECTILE is designed to help teams surface and investigate potential weaknesses quickly, with a target of finding vulnerabilities within an hour under suitable evaluation conditions. Evaluation time depends on the target system, scope, configuration, and test conditions.

PROJECTILE is currently in the prototype stage.
Public beta is planned for January 2027. The beta timeline is a plan, not a guaranteed release date.

CAPABILITY SET / 04

  1. 01

    30,000+ base strategies

    Evaluations draw on a substantial base of more than 30,000 strategies for challenging intelligent systems — a wide foundation that testing and self-learning build on.

  2. 02

    Self-learning

    PROJECTILE learns from attacks and their outcomes, using results to sharpen subsequent testing and strategy selection rather than repeating a fixed sequence.

  3. 03

    Multi-turn adaptive stress testing

    Evaluations run across multi-turn interactions and adapt their direction in response to observed behaviour — because failures often emerge through accumulated context, changing instructions, and tool use rather than isolated prompts.

  4. 04

    Continuous coverage, 24/7

    Designed to support continuous evaluation coverage rather than one-off manual testing, so a system can be examined as it changes — not only on the day someone checks.

EVIDENCE, NOT ASSERTION

What a finding
looks like.

Every candidate is judged, reproduced by the independent verifier, and only then trusted. This is an illustrative example of the record structure — not live data from a real evaluation.

EVALUATION #IM-0042

ILLUSTRATIVE EXAMPLE — NOT LIVE DATA

Evaluation
#IM-0042
Target
Customer Support Agent
Attack
Tool Abuse
Observation
Unauthorized tool invocation
Judge
Verifier
7/8 reproductions
Severity
HIGH
Evidence
Captured
CANDIDATE — PENDING ASSESSMENT

A candidate is a potential issue requiring assessment — not a confirmed finding. It becomes a finding only when the applicable verification and evidence process supports it.

SEE HOW FINDINGS ARE ASSESSED

RESEARCH MODE

Built for security research,
not just dashboards.

Research runs track everything needed to reproduce, compare, and defend a result.

  1. 01Benchmarks & Baselines
  2. 02Novelty
  3. 03Reproduction
  4. 04Provenance
  5. 05Cost
  6. 06Target Versions
  7. 07Exports
  8. 08Evidence Hashes
EXPLORE RESEARCH MODE

APPROACH

From a defined objective
to evidence.

Credible evaluation requires more than identifying an unusual response. A potential failure must be examined in context, supporting evidence must be preserved, and the outcome must reflect what the evaluation actually establishes.

EXPLORE THE APPROACH

INTENDED PROCESS / FIVE STAGES

  1. 01DEFINE
  2. 02CHALLENGE
  3. 03OBSERVE
  4. 04EXAMINE
  5. 05REPORT

UNDER DEVELOPMENT — AVAILABILITY OF EACH STAGE SHOULD BE CONFIRMED BEFORE PLANNING AN EVALUATION.

EVALUATION CONTEXTS

Different systems
fail in different ways.

Evaluation should reflect how a system is used, what information it receives, what actions it can take, and the constraints it is expected to follow. The relevant failure modes differ across applications.

01Customer support and commerceMulti-turn behavior, policy adherence, untrusted inputs.02Enterprise software and internal copilotsInstructions in untrusted documents, conflicting sources.05Software engineering and coding agentsTask drift, tool and permission boundaries.08Multi-agent systems and complex workflowsHandoffs, inconsistent state, failure propagation.ALL EVALUATION CONTEXTS — 08

FIELD GUIDES

AI red teaming,
explained.

Practical guides to the methods behind PROJECTILE: how LLM red teaming works, how prompt injection is tested, and how AI agents are assessed for security.

WHAT IS LLM RED TEAMING PROMPT INJECTION TESTING AI AGENT SECURITY TESTING