Dreadnode, Fiddler and the Evidence an AI Assurance Stack Should Produce

Sources checked: 10 November 2026. FailSafe Research.

An enterprise can purchase model testing, agent monitoring and runtime enforcement from one supplier and still need to reconcile three different kinds of evidence. A pre-deployment test describes a tested configuration. A runtime trace records a session. An enforcement decision records what a control permitted or denied. Combining them in a product portfolio does not automatically establish that a particular attack path is closed.

What the acquisition announcements establish

On November 3, CrowdStrike announced agreements to acquire Dreadnode for automated AI security testing and Fiddler for agent observability and explainability. These are planned acquisitions and integration directions. The announcements do not establish that every combined capability is already deployed or that one supplier has demonstrated superior effectiveness in a matched assessment.

Connect a finding to the policy that should stop it

Start with a finding reference and a concrete boundary: an agent must not retrieve a different workspace's synthetic record. The pre-deployment result should identify the model, harness, connector and relevant policy versions. A runtime trace should identify the requested action without distributing confidential content. The control record should explain which identity, resource and approval state caused the allow or deny decision.

The owner can then ask whether the proposed correction addresses the demonstrated boundary. A change to a final-response filter may leave a tool's data access unchanged. A new approval prompt may leave an alternative connector outside the check. The closure record needs the version actually deployed and a repeat of the original case, along with legitimate operations that should still succeed.

Where independent assessment is useful

FailSafe's AI security assessments examine the deployed application, connected tools and resulting authority. We organize evidence around the action attempted, expected boundary, observed effect and remediation retest. A customer's preventive and observability products can remain part of that environment. Product access, test permissions and the ability to observe outcomes determine the scope.

This is a practical way to evaluate a consolidated stack without assuming that consolidation is either sufficient or ineffective. An internal team, a platform vendor and an external assessor may each contribute useful observations. Independence does not make a result correct by itself. Reproducible cases and explicit limitations make the result assessable.

Ask for an exportable closure record

A useful buyer checklist includes configuration provenance, an allowed test objective, control decisions, sanitized execution evidence, a correction owner and deployed retest results. Keep the original failure available after the issue is closed. Identify which evidence cannot leave the environment and provide a review process for it. An audit screenshot without the decision history is a weak substitute for that record.

FailSafe's AttackBench research with NEAR supplies a separate reason to record the model and runtime together: research outcomes depend on their combination. Those published results do not evaluate the announced acquisitions. Use the synthetic finding and retest example to specify the evidence you want from your own assessment.