Application Restrictions
Application Restrictions let you block an application from running or limit what it may do while running. Both controls are managed from the same page.
Open Respond > Application Restrictions. Operator or Admin permission is required to create or change restrictions.
Choose the right control
Choose the action that matches your goal:
| Action | Use it when you want to |
|---|---|
| Block application | Prevent a particular application from running. On supported hosts, limit the rule to starting arguments, users or groups, and a schedule. |
| Restrict application activity | Allow an application to run, but limit the programs it starts, files it accesses, network destinations, and system privileges it uses. |
These controls are complementary. For example, allow a service to run with restricted activity while blocking an unwanted administration tool.
Use Runtime Blocks for other blocking policies, or Runtime Detection to identify matching activity without applying an application restriction.
Application Restrictions were previously called Guardian Profiles. Existing profiles remain available in this workspace.
Modes
| Mode | Behavior |
|---|---|
| Observe | Saves a draft without applying restrictions. For activity restrictions, use observed history to help prepare the allowed behavior. |
| Audit | Records matching commands or activity violations without blocking them. |
| Enforce | Applies the rule. Review the reported effect for the selected hosts before confirming. |
Enforcement can interrupt an application. Depending on host support, blocking may prevent execution or terminate a process after it has started. Activity restrictions may also deny blocked operations. Test representative activity on a limited target before expanding the rule.
Create restrictions
- Select Create restrictions.
- Choose Block application or Restrict application activity.
- Enter a rule name and the application's full path, such as
/usr/bin/myapp. Enter the application path only, not a complete command. - Choose Target hosts. Review the scope carefully before using All sensors (fleet-wide).
- Choose an initial mode. Use Observe to prepare a draft or Audit to check matches before enforcing.
- Complete the conditions or restrictions described below.
- Open Review, check the targets and available compatibility information, then select Create Restrictions.
Block application
The Console checks the conditions supported by the selected hosts after you enter the application path. Available options depend on support across all targeted hosts.
- Starting arguments - Leave this empty to match all arguments. When available, add each starting argument separately, in order and with exact spelling. For
/usr/bin/ps aux, enter/usr/bin/psas the application path andauxas the first argument. Do not add shell quotes. - Users and groups - Apply the rule to all users, only selected users or groups, or everyone except the selected users or groups. Choose the account or group type and enter its exact name.
- Schedule - Choose Always, a One-time window, or Weekly when available. One-time start and end fields use UTC; weekly schedules use the timezone you choose.
Accounts and groups belong to the target host, including directories connected to that host. They are not your Console sign-in accounts. A name that cannot be found on a target host prevents activation there.
If an option is unavailable, choose compatible hosts or use a rule without that condition. When editing an existing rule, saved conditions are not silently removed: resolve the compatibility message before activation. Refresh compatibility if the information is missing or out of date.
Restrict application activity
Review the allowed child processes, file paths, network destinations, and privileges. Enter one item per line. A folder path ending in / includes its contents; a path without the trailing / matches that exact path. An empty allowed list leaves that category unrestricted. Audit and Enforce require at least one restriction.
Network restrictions cover new TCP connections, not UDP traffic or connections that were already open. Ask your administrator to review unfamiliar system privileges or blocked operations before enforcing them.
Use Observation settings to choose the history used when generating allowed behavior.
Users with limited sensor access must choose one permitted sensor instead of leaving the fleet-wide default.
A rule applies to the application path and targets you select. Do not select a general-purpose script runner when you intend to restrict only one script.
Generate allowed behavior
For Restrict application activity rules in Observe mode, use Auto-generate allowlists from observed events. This uses recorded activity, not AI, and uses the rule's saved observation window. For a fleet-wide rule, select an Evidence sensor; a sensor-specific rule uses its target.
Generation requires retained history with usable observations for that sensor and the exact application path. If an older rule retains a network-function targeting filter, the evidence sensor must also match that filter 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.
Edit the name, description, and the conditions or restrictions available for that rule. The action, application path, and target hosts remain fixed. Activity rules also retain their observation window. Create a separate rule to change these fields. Use the table's Mode selector to change mode.
Use the download action to keep a copy of an Audit or Enforce rule for review. Command rules offer Export command policy JSON; activity rules offer Export tracing policy YAML. Observe drafts cannot be exported. You do not need to edit these files to manage a rule in the Console.
For activity restrictions, use Compare... when another accessible rule targets the same application.
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. Review each host's reported state. A scheduled rule may be waiting for its active window; an unsupported or unconfirmed result requires attention before you rely on it.
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.