Resource Limits

AIR Responders run on production endpoints, so evidence collection must not disrupt the workloads running on them. Resource Limits cap how much of an asset’s resources the Responder may consume while executing tasks such as evidence acquisitions, Hunt/Triage scans, disk imaging, and interACT sessions.

Limits apply while a task runs. An idle Responder consumes negligible resources and does not need throttling. See Responder Architecture Overview and Performance Analysis for measured footprints.
Limits are enforced on the asset itself. The Responder applies each limit at the operating-system level while the task runs.

Where to configure

Resource Limits are part of Policies:

Go to Settings > Policies, create or edit a policy, and open the Resource Limits section.
Assign the policy to the organizations it should govern. When several policies match an asset, they merge in priority order, and the read-only Default Policy fills in any value left unset, so every task runs with a complete resource configuration.

Operators can also bypass policy values for a single task by choosing Use Custom Options under Show Advanced Options when creating the task. This requires the Override Policy privilege. Task types expose only the limits that are relevant to them; for example, disk imaging tasks expose bandwidth and disk I/O priority rather than CPU limits.

Available limits

Setting	Unit and range	Default	When the limit is reached
CPU Limit	Percent of the asset’s total CPU capacity, 1-100	50%	The task is throttled and takes longer; it does not fail
CPU Core Limit	Logical core count, 0-64 (0 = unlimited)	Unlimited	Task work is confined to fewer cores; the task takes longer
Memory Limit	GiB or MiB, minimum 512 MiB (0 = unlimited)	4 GiB	The operating system terminates the task’s processes and the task is reported as failed, protecting the asset
Bandwidth	KiB/s, MiB/s, or GiB/s (0 = unlimited)	Unlimited	Evidence transfers wait for available bandwidth; nothing fails
Disk Space	Free space to preserve on the collection volume, in KiB, MiB, or GiB	Not set	Collection stops; evidence collected so far is still uploaded, and the task reports the disk-space condition
Disk I/O Priority	Lowest / Low / Medium / High	Medium	No threshold to reach; this setting adjusts I/O scheduling priority

How each limit works

CPU Limit

The CPU limit is a percentage of the asset’s total CPU capacity across all logical cores. On an 8-core asset, a 50% limit allows the task to use up to four cores’ worth of CPU time, spread across all cores.

The Responder applies the limit to the entire task, including the collection engine and any analysis child processes. A lower limit also reduces how much work the task attempts in parallel.

When the limit is reached, the task runs slower. A CPU limit never causes a task to fail.

CPU Core Limit

The CPU core limit restricts how many logical cores a task may use, independently of the CPU percentage. On Windows and Linux, the task is confined to the allowed number of cores. On macOS and AIX, the same limit is applied as the equivalent share of the asset’s total CPU capacity.

A value of 0 means unlimited. Like the CPU limit, the core limit slows work down; it never aborts a task.

Memory Limit

Some customers run Responders on assets where resource isolation is a security and safety requirement. The memory limit gives you a predictable ceiling on how much memory each task may use, so even rare memory spikes are bounded and cannot disrupt business-critical workloads. This is a proactive safety control rather than a fix for a common memory issue.

The Responder enforces the limit at the operating-system level.
The limit covers the task’s entire process tree, including collection and analysis child processes.
If a task exceeds its memory limit, the operating system terminates the limited process tree. The task is reported as failed with a memory-related cause, and the asset is protected from resource exhaustion.
For interACT, the limit is applied when the session starts; a changed limit takes effect with the next session.

The default is 4 GiB. The minimum enforceable limit is 512 MiB, and 0 means unlimited.

Bandwidth

The bandwidth limit throttles evidence transfers. It applies to:

Evidence uploads to every repository type (SMB, SFTP, FTPS, Amazon S3, Azure Storage, Google Cloud Storage, and others)
Disk image streams
interACT file transfers
Large content downloads

Routine Responder-to-Console communication (polling, status updates) is lightweight and unaffected. In addition, a Responder uploads to a given evidence repository one file at a time, which prevents a single asset from opening many parallel streams against the same repository.

When the limit is reached, the transfer waits until bandwidth is available. A bandwidth limit never causes a task to fail; it only extends transfer time.

Disk Space

The disk space setting reserves an amount of free space that must remain available on the volume hosting the collection directory. The Responder checks free space before collection starts and re-checks it continuously while evidence is being written.

If free space would drop below the reserve:

Collection stops rather than filling the volume.
Evidence collected up to that point is still packaged and uploaded.
The task reports the disk-space condition, either as a failed collection or as partial evidence when only optional content was skipped.

Even when no reserve is configured, the collection engine keeps a built-in minimum safety margin of roughly 100 MB of free space.

Disk I/O Priority

Disk I/O priority controls how the Responder’s disk operations compete with other workloads, using each operating system’s native I/O priority mechanism. It does not cap throughput.

Medium keeps the Responder’s default behavior. The Responder already runs with a reduced I/O footprint, so Medium does not raise anything. The selected level remains in effect until another task applies a different one.

Built-in protections

The following protections apply regardless of policy configuration:

Evidence-collection tasks run one at a time per asset. Acquisitions, Hunt/Triage scans, full-text searches, and similar collection tasks queue and execute sequentially, so two heavy collections do not run at the same time. Operational task types (disk imaging, interACT sessions, isolation) have their own queues and can run alongside when requested.
Task processes run at reduced CPU and I/O priority, so interactive and business workloads take precedence.
A minimum free-disk safety margin of roughly 100 MB applies to every collection, even with no configured reserve.

Tuning guidance for sensitive environments

The defaults are safe starting points for most fleets. Environments with stricter requirements, such as banking systems, critical infrastructure, and healthcare, can use the profiles below as starting points. Validate them on representative assets before rolling them out fleet-wide.

Latency-sensitive, user-facing production systems (branch workstations, terminal servers, trading systems, operator consoles):

CPU Limit 25-40%, CPU Core Limit 1-2
Disk I/O Priority Low or Lowest
Bandwidth capped to a fraction of the site uplink (for example 10-20 MiB/s per asset on a 1 Gbps site)
Disk Space reserve of at least 10% of the collection volume
Schedule broad Hunt/Triage sweeps off-peak

Keep the 4 GiB memory default, or lower it toward 2 GiB only after observing typical task memory usage on that asset class.

Shared infrastructure (domain controllers, database servers, virtualization hosts): prioritize storage protection. Disk I/O Priority Lowest and a firm bandwidth cap matter more than the CPU value. Schedule collections off-peak where possible.

Active incident response: raise the CPU limit to 80-100%, leave cores unlimited, and remove the bandwidth cap. Use a dedicated response policy or per-task custom options so the change is easy to revert.

Coexisting with EDR and antivirus

Resource Limits reduce contention with other security tooling, but they do not replace exclusions:

Configure your EDR/AV exclusions for the Responder as described in Responder Exception Rules. Real-time scanning of evidence archives as they are written adds load that is outside the Responder’s own accounting.
Throttled tasks trade a short burst of activity for a longer window of low activity. If your EDR alerts on the Responder’s collection behavior, tune the exclusions rather than removing limits.

Monitoring

Console: each asset’s detail page shows periodic host CPU, RAM, and disk usage reported by the Responder. Task durations and statuses reveal the effect of limits; failure causes explicitly name memory and disk-space conditions.
Responder logs: the Responder periodically logs its own resource snapshots while a task runs. See Responder Architecture Overview and Performance Analysis for how to read them.
On the asset: standard OS tools (Task Manager, htop, Activity Monitor) show the Responder and its task processes, which run under the configured limits and at reduced priority.

FAQ

Does a 50% CPU limit mean half of one core? No. The percentage refers to the asset’s total CPU capacity across all logical cores. On an 8-core asset, 50% allows up to four cores’ worth of processing, spread across all cores.

Does the Responder consume resources when no task is running? No meaningful amount. Resource Limits govern task execution; the idle Responder’s footprint is negligible.

Does setting Bandwidth or Disk Space to 0 disable protection? 0 means unlimited for both settings. For disk space, the collection engine still preserves its built-in minimum free-space margin of roughly 100 MB.

Can a resource limit make my task fail? CPU, core, and bandwidth limits never fail a task; they slow it down. The disk-space reserve stops a collection that would exhaust the volume, and the evidence collected up to that point is still uploaded.

The memory limit is the one deliberate exception: a task that exceeds it is terminated by the operating system and reported as failed. This protects the asset from memory exhaustion.

Can several heavy tasks run at the same time on one asset? Evidence-collection tasks queue and run one at a time. Disk imaging, interACT, and isolation use separate queues, so an imaging task can run alongside an acquisition if you start both. Plan bandwidth and disk I/O priority accordingly.

Are limits enforced identically on every operating system? Tasks stay within their limits on every supported platform. The Responder uses each platform’s native controls; platform-specific notes are called out in the relevant sections above.

Will a disk imaging task saturate my storage or network? Imaging tasks honor the Bandwidth limit on the image stream and the Disk I/O Priority setting. Set both when imaging assets attached to shared storage.

Will a YARA Hunt/Triage scan spike CPU? The CPU limit applies to scans as well, so a limited scan runs shallower and longer instead of spiking. Narrow the scan scope with Hunt path patterns to reduce total work.