---
title: Block Application Policy Group
slug: kronpam-agent-reference-guide-3-8-1/block-application-policy-group
docTags: 
createdAt: 2026-06-24T08:53:55.732Z
---

In this policy group, the policy should be set to **Block**. There is no second step for selecting subprocess behavior, as the main process is already blocked. Once commands or applications are added to this policy group, they will be restricted accordingly.

![](https://api.archbee.com/api/optimize/g9cApVza9NIhSh0pjZYtA/DP9oh0Xh7h33QTnNaDyIY_image.png "Block Application Policy Group Creation")

When a policy is applied, the enforcement is not limited strictly to the command string entered by the user. Instead, the policy engine validates both the command itself and its associated **Image Path**.

To illustrate this with an example:

If you define a policy for the mkdir command:

1.       **Command Execution:** If the user simply runs mkdir, the policy is triggered.

2.       **Absolute Path Execution:** If the user runs the command using its full binary location, such as /usr/bin/mkdir, the policy is also triggered.

This ensures that a user cannot bypass security restrictions or approval workflows by simply calling the absolute path of a binary instead of the alias or short command. The agent resolves the executable's path to ensure that regardless of how the command is invoked, the **Managerial Approval** or elevation rules are consistently enforced.

**Key Technical Points:**

·         **Path Canonicalization:** The system identifies the underlying binary (the image path) to prevent evasion.

·         **Consistency:** This approach ensures that whether the command is in the system's $PATH or called directly from a specific directory, the policy remains active.

·         **Security:** It prevents "shadowing" or bypassing policies through different invocation methods.

![](https://api.archbee.com/api/optimize/g9cApVza9NIhSh0pjZYtA/UP8bein0qHUyH74tIhkhv_image.png "Different types of the Command Executions")