Application Restrictions
Application Restrictions define the expected behavior of a particular program: which child processes it can start, files it can access, destinations it can contact, and capabilities it can use.
Open Respond > Runtime Blocks > Application Restrictions. Operator or Admin permission is required to create or change restrictions.
Choose the right control
Use Application Restrictions for an application's allowed behavior. Use Runtime Blocks for a specific blocking rule, or Runtime Detection to alert on matching activity without blocking it.
Application Restrictions were previously called Guardian Profiles. Existing profiles remain available in this workspace.
Modes
| Mode | Behavior |
|---|---|
| Observe | Stores the definition without applying active restrictions. Use this while reviewing the application. |
| Audit | Records matching violations without terminating the process or denying the operation. |
| Enforce | Terminates processes that violate the configured allowlists and denies configured blocked system calls. |
Enforcement can interrupt the application. A terminating action may occur after the triggering operation has begun. Network restrictions cover new TCP connections, not UDP traffic or connections that were already open. Review the generated policy and test representative activity before using Enforce.
Create restrictions
- Select Create restrictions.
- Enter a name and the full executable path of the application.
- Choose the target sensor and any applicable network-function scope.
- Start in Observe.
- Review the allowed child processes, file paths, network destinations, and capabilities.
- Set the observation window, then select Create Restrictions.
Enter one restriction per line. Use full executable paths, exact file paths or directory prefixes ending in /, TCP destination ports and CIDRs, capability names, and blocked system calls as appropriate. An empty allowlist leaves that category unrestricted. Audit and Enforce require at least one restriction.
Users with limited sensor access must choose one permitted sensor instead of leaving the fleet-wide default.
A definition applies to the executable and scope you select. Do not use a general-purpose interpreter as a substitute for a particular script.
Generate allowed behavior
In Observe mode, use the wand action labelled Auto-generate allowlists from observed events. It uses the definition's saved observation window. For a fleet-wide definition, select an Evidence sensor; a sensor-scoped definition uses its target.
Generation requires retained Analytics history with usable observations for that sensor and the exact application path. If the definition specifies a network-function role, the evidence sensor must also match that role for the application. Observe mode and sensor connectivity alone are not enough.
Generation saves the observed allowlists immediately. Categories with new evidence replace their existing lists; categories without observations and blocked system calls remain unchanged. Open Edit restrictions afterward to review the result.
Choose representative activity that includes startup, normal operation, and expected maintenance. Observed activity is not automatically approved activity, and an unobserved action may still be required.
Review and edit
Open an existing definition to inspect its scope, mode, and allowed behavior. Use Edit restrictions to change editable fields, then Save Changes.
Editing changes the name, description, and restriction lists. The application, network-function role, sensor scope, and observation window remain fixed. Create a separate definition to change those fields. Use the table's Mode selector to change mode.
Use Compare... when another accessible definition targets the same binary. Export tracing policy YAML downloads an Audit or Enforce policy for inspection; Observe drafts cannot be exported.
Move to enforcement
- Review the definition in Observe mode.
- Change to Audit and exercise normal application workflows.
- Investigate violations and adjust the allowed behavior where justified.
- Change to Enforce only after reviewing the expected impact.
- Confirm application health and sensor-reported policy state.
A requested mode alone is not confirmation that every target sensor has applied it. Check the sensor's reporting and enforcement state.
Detection policies
The former Guardian Policies editor is no longer a separate workflow. Open Detect > Runtime Detection > Custom Rules to inspect and edit existing detection rules.