When an agent proposes an unsafe action: how SWARM constrains execution

Sources checked: 2 November 2026. FailSafe Research.

An agent can discover an interesting path and propose an action that goes beyond the job it was given. In offensive security, the difference between a useful finding and an operational incident can be the action that follows. FailSafe SWARM puts restrictions around that transition through an execution gate, action modes and an isolated agent runtime.

The aim is to give your team evidence it can use while keeping the assessment within an agreed risk boundary. That starts before the model makes its first proposal: name the targets, access, exclusions, permitted techniques and conditions that stop the work.

The proposed command goes through a gate

FailSafe’s documented command gate inspects proposed execution, including request parameters and bodies. In Safe mode, it rejects recognized destructive operations and configured state-changing actions, including restricted mutation methods, form submissions and brute-force tooling. It also applies the request-rate cap.

This matters because a useful instruction to the agent is only one part of the operating model. The proposed action has to pass the execution check. A request that conflicts with the configured policy should be rejected before that action runs.

The gate has a defined limitation. It recognizes prohibited operations and patterns; it does not infer every payload’s intent or predict every effect in an arbitrary application. A request can look ordinary and still cause a state change. That is why environment selection, scoped access and review remain part of the assessment.

Safe mode starts with a smaller proof

In Safe mode, agents are instructed to confirm a weakness read-only first. An approved benign signal can sometimes establish a security boundary failure without progressing through a more disruptive chain. The useful question is whether the evidence explains the finding well enough for the system owner to act.

Some paths cannot be validated completely within those restrictions. Preserve that distinction in the report: what was observed, what it establishes, and what remains unexecuted. A hypothesis with a restricted proof should not be presented as a fully completed exploit.

Deeper validation needs a different environment

Cyber mode allows broader authorized writes and mutations so an exploit can be validated more deeply. Known irreversible destructive operations remain blocked. The target must be customer-owned or explicitly authorized, isolated from production, with hard network-egress restrictions.

The environment requirement is material. If a test executes on the target, subsequent activity can take place in that target’s network context. Isolating the agent runner does not automatically constrain the target’s outbound traffic. Agree and verify that boundary before authorizing deeper execution.

Keep the agent’s local context limited

In both modes, the agent runs without elevated privileges in an ephemeral sandbox without ambient credentials. That limits its local execution context. Authenticated testing still requires deliberately scoped target access, and the engagement should define credential handling, removal and the people who can stop work.

FailSafe continues to harden sandbox isolation and payload handling. For an enterprise assessment, ask to review the current control behavior against the configuration you will use. Useful evidence includes permitted and denied actions, the applicable request limit, known coverage restrictions and the agreed escalation process. This is a configuration review, not a promise that a single gate catches every possible harmful action.

Control the inference boundary too

For sensitive assessments, FailSafe supports sovereign hosting and fully local inference by agreed design. In that configuration, model processing and evidence can remain inside the enterprise environment. The execution gate, target containment and model-processing location remain separate controls to review together.

Explore the FailSafe Trust Center for the mode comparison, read the three containment boundaries, or review your assessment requirements. No training on customer assessment data occurs by default; explicit customer permission is required for training or fine-tuning.

Documentation basis: FailSafe’s agent-safety addendum and public execution-control summary, editorial update 2 November 2026. This describes the documented control model; deployed scope and prerequisites are confirmed for the engagement.