Back to blog

Multi-Model Pentesting: Keep Routing Inside the Approved Boundary

3 min read
Multi-Model Pentesting: Keep Routing Inside the Approved Boundary

Sources checked: . FailSafe Research.

A fallback model can keep a workflow moving when the preferred endpoint fails. It can also send sensitive assessment context somewhere procurement never approved. Treat model routing as an enforceable security decision.

An approved model route map

DecisionEvidence to request
ClassificationData classes allowed at each endpoint
RecoveryApproved fallback, escalation or stop
AuditActual route and policy version for the run

Classify the context before routing

An agent may hold source snippets, credentials references, application responses and findings in the same working context. Identify which classes may reach each approved endpoint. Route policy should apply to the complete request, including tool outputs and attachments. A public initial prompt does not make the later conversation public. Keep the identity, project and data classification attached as the workflow moves between specialist and general reasoning tasks.

Define permitted recovery explicitly

Write down what happens when a model is unavailable, a budget is exhausted or a task needs a different capability. The options may include an approved alternative, a human escalation or a clean stop.

Do not allow an application library’s default provider to become an undocumented fallback. Make the blocked case observable so operators can distinguish a policy-preserving stop from a broken assessment or a completed task.

Test routing with synthetic sensitive markers

Use harmless markers representing restricted source or findings and trigger the approved failure conditions. Inspect destination records and retained diagnostics without collecting real secrets. Verify that an unapproved endpoint is never called and that a permitted fallback receives only the allowed context. Include retries and queued work; a policy enforced only on the first attempt can be bypassed by the system’s own recovery behavior.

Keep model changes in the assessment record

Record model identifiers, endpoints, routing policy version and any escalation with the resulting evidence. A later retest should explain whether the target changed, the model changed or both. This makes cost and quality comparisons interpretable. It also gives the security owner a way to revoke a provider or alter a boundary without relying on individual operators to remember a new informal rule.

Make routing part of the proposal

FailSafe’s multi-model and customer-controlled deployment options are useful when routing must meet a specific policy. Ask for the proposed route map and verify failure behavior in the evaluation, alongside the quality of the exploit evidence.

Start with FailSafe deployment options, SWARM and the GlassBreak cyber model. For a side-by-side assessment, plan a matched evaluation. Custom enterprise deployment is scoped separately from the first-pentest offer.

Reference: FailSafe inference and fallback design requirements. Reviewed 29 October 2026. This is a buyer guide, not an independent head-to-head test.

Questions & answers

Questions about this topic

Direct answers to common questions about this page.

Only if that path is explicitly approved for the data involved. Otherwise stop or escalate.

Model and endpoint changes affect both data handling and the interpretation of later retests.

Put this guidance to work

Bring your application and deployment requirements. Ask FailSafe to show the evidence on an agreed target, with clear access, safety rules and success criteria.

Plan a matched evaluation