Quarantine

Fleet → Quarantine (/gravity/fleet/quarantine) lets you isolate a fleet-enrolled host at the network level - useful if you suspect it’s been compromised and want to cut it off without touching the machine directly.

What it does

Quarantining a host blocks its outbound network traffic at the operating-system level, except for the connection it needs to keep talking to Sencai - so the platform can still release it later. The isolation runs on the host itself, through the fleet agent, and is Linux-only.

Caution

Isolating or releasing a host dispatches to the fleet agent, which is a gated capability that has to be enabled for your environment. Where it isn’t, both Quarantine Agent and Release fail outright - no host is isolated or released, and nothing is recorded in Active Quarantines, History, or your audit trail. Check with your account team before relying on quarantine as your response plan.

Caution

Quarantine and release use two separate agent capabilities, not one: isolating a host requires Quarantine: Isolate, and releasing it requires a separate Quarantine: Release grant on the same agent. Grant both from Fleet → Agents → Grant Capability before relying on quarantine as your response plan - otherwise you can isolate a host and then be unable to release it. The target agent also needs to be online at the moment a command is dispatched; a disconnected agent, or one that was enrolled before a capability was granted, won’t act on it until it reconnects with the capability in place.

Quarantining a host

You can trigger it manually or configure a policy that does it automatically:

• Manual - Fleet → Quarantine → Quarantine Agent, enter the agent’s ID, and optionally apply an existing policy.
• Policy-driven - define a Quarantine Policy with a trigger type (manual, critical incident, critical vulnerability score, or suspicious execution), and an auto-release window (or manual release only). See the caution below before relying on a policy to isolate a host on its own.

Caution

Policies do not isolate hosts automatically yet. Creating a policy stores your configuration and it is returned by the API, but today only the critical vulnerability score trigger is evaluated at all - when a fleet agent reports a hardening scan - and it runs in evaluation-only mode: a match is recorded in your audit trail, but the host is not isolated. The critical incident, suspicious execution, and manual trigger types are not evaluated at all. To isolate a host, use the manual path above - subject to the dispatch and capability prerequisites noted at the top of this page.

Trigger types

Trigger	Intended condition	Evaluated today
Manual	Only when someone explicitly quarantines the agent	No automatic condition
Critical incident	A critical-severity incident is linked to the host	Not yet
Critical vulnerability score	The host’s vulnerability score crosses a critical threshold	Evaluation only - no isolation
Suspicious execution	Anomalous command execution is detected on the host	Not yet

Each policy also records an auto-release window - the number of hours after which a quarantine triggered by that policy is intended to release itself, or manual only - and whether to notify on trigger. Neither the auto-release window nor the notification has a consumer yet: nothing currently releases a quarantine automatically or sends a notification when a policy fires, regardless of what you configure here. Release a host manually - see below.

What breaks while quarantined

Essentially all outbound network traffic from the host is blocked - it can’t reach the internet, other internal services, or anything else outside its connection back to Sencai. It doesn’t touch the host’s own running processes, files, or local services; those keep running, they just can’t communicate outward.

Releasing a host

From Fleet → Quarantine → Active Quarantines, click Release on the host and optionally note a reason. Releasing a host requires an organization Owner or Admin role in the organization that quarantined it, and the agent must have the Quarantine: Release capability granted and be connected at that moment - the same online requirement as isolating a host. Release dispatches to the agent the same way quarantine does: where dispatch isn’t enabled for your environment, Release fails and the host stays listed as actively quarantined.

Every quarantine and release action - who triggered it, on which host, when - is recorded in your organization’s audit trail.

History

Fleet → Quarantine → History lists the most recent quarantine events for your organization (up to the last 20) - whether each is still active or has been released manually, with the trigger type, when it was quarantined, when (if at all) it was released, and any release reason that was given. Use this if you need a quick record of past isolations without pulling the full audit trail.

Managing quarantine policies

From Fleet → Quarantine → Quarantine Policies, you can add a new policy (name, trigger type, auto-release window, and whether to notify on trigger) or delete one you no longer need. Deleting a policy doesn’t release any host it’s currently applied to - release those separately from Active Quarantines if needed.

What’s next

• Fleet agent - how capabilities are granted, including Quarantine: Isolate and Quarantine: Release
• Agent policies - autonomy limits for automated actions, secret injections, and custom probes (a different thing from a Quarantine Policy)
• Remote execution - running commands instead of isolating a host
• Audit log - reviewing quarantine history
• Incidents - the broader incident-response workflow