Response scripts and run-script tickets

Response scripts add a fifth kind of action to the response ticket system: run_script, alongside the existing isolate, kill_process, quarantine_file and fetch_file. This article covers the allowlist model, how a script actually runs through the existing approval queue — and, most importantly, what is genuinely missing before any of this does anything on a real fleet.

Read this before you configure anything

This is a deliberate trust-boundary decision, not an oversight: a manager that can push arbitrary executable content to an agent is exactly the kind of capability a security product should not hold, so the platform was built the other way around from the start — the sensor only ever runs something it already trusted locally, never something handed to it over the wire.

The allowlist model

A response script is a per-tenant allowlist entry with:

Name

The identifier a sensor looks up in its own local script library. Immutable once created.

Description

What the script does, for whoever is approving a ticket to run it.

Action kind

isolate, kill, quarantine_file, block_ip or custom — categorises what the script does, for reporting.

Timeout

How long the sensor will wait for the script before giving up.

Stateful

Whether the script leaves a lasting effect on the endpoint that a later undo request could reverse. See the undo note below.

Undo supported

Whether the script accepts a command: "undo" request and returns an undo_token on a successful run — see the undo note below.

An allowlist entry is delivered to a host group's sensors through the normal signed policy bundle — see The signed policy bundle — so a sensor knows which script names it is permitted to run before any ticket ever names one. A run_script ticket is refused outright unless the named script is both an enabled allowlist entry on the server, and independently confirmed against the sensor's own last-received bundle before it will execute — a fail-closed double-check on both sides of the wire.

Running a script through the existing approval queue

There is no separate "execute now" path for a response script. Running one raises a real run_script ticket through the same human-approval queue every other response action already goes through — see Response actions and Live response and approval for the full ticket lifecycle: created as pending_approval, approved by a person with the response-actions write permission, collected by the sensor on its next poll, and reported back as completed or refused, with the result — a status and a detail string — recorded on the ticket.

On the console's Response scripts page, running a script targets a host through a search-first picker rather than a plain dropdown, since the tenant's sensor list has no server-side search endpoint yet — the same pattern used elsewhere in the console where a full-text search route does not exist.

In the console

XDR → Response scripts lists, creates, edits, enables/disables and removes allowlist entries against the real server CRUD. There is no control to upload or paste script content here — consistent with the fact that the server has no route for it and the sensor never receives content over the wire; offering an upload button would be a control that silently did nothing. A script's name cannot be changed after creation, because it is the allowlist key a sensor matches against.

What to do next

1. Do not rely on run_script for anything time-sensitive until your organisation has its own way of getting signed scripts onto endpoints — that piece is not built.
2. Read Response actions for the full set of response commands and what each one does.
3. Read Live response and approval for exactly what a ticket records and who should hold the permission to approve one.