# macOS Protected Path Design Intent

### macOS Protected Path Design Intent

#### Why /Applications and /System/Applications Are Protected

On macOS, `/Applications` and `/System/Applications` are **protected paths** — wildcard file access policies are intentionally bypassed for executables in these directories. This is by design, not a limitation.

A blanket wildcard policy targeting `{applications}/*.app` or `{applications}/*.app/Contents/MacOS/*` would catch every application in `/Applications` indiscriminately, including software legitimately deployed through an MDM solution such as Jamf. Protecting these directories ensures that managed, approved applications are never inadvertently blocked or gated behind an approval workflow they should not require.

Additionally, a standard user cannot install software into `/Applications` without administrator credentials. The threat model for unsanctioned software installs does not live in `/Applications` — it lives in the user's home directory, where a user can freely download and run applications without elevated privileges.

{% hint style="info" %}

#### **What this means for policy design:**

* Wildcard file access policies are the right tool for the **user's home directory and downloads** — this is where unmanaged software installs actually occur. Use patterns like `{home}/*.dmg`, `{downloads}/*.app`, or `{downloads}/*.pkg` to enforce that users can only run approved software and to require approval or block anything downloaded outside of managed channels.
* For applications in `/Applications` or `/System/Applications`, use **explicit paths**. This is intentional — it gives administrators precise control over specific applications without risking disruption to the broader managed application estate.
  {% endhint %}

#### **Examples of appropriate wildcard policy targets on macOS:**

<table><thead><tr><th width="178.45455932617188">Pattern</th><th>Use Case</th></tr></thead><tbody><tr><td><code>{downloads}/*.app</code></td><td>Block or require approval for any app downloaded directly by the user</td></tr><tr><td><code>{downloads}/*.dmg</code></td><td>Block or require approval for disk images in the user's Downloads folder</td></tr><tr><td><code>{downloads}/*.pkg</code></td><td>Block or require approval for installer packages downloaded by the user</td></tr><tr><td><code>{home}/*.app</code></td><td>Block or require approval for any app run directly from the user's home directory</td></tr></tbody></table>

#### **Examples of explicit path policies for /Applications:**

<table><thead><tr><th width="551.7879028320312">Pattern</th><th>Use Case</th></tr></thead><tbody><tr><td><code>{applications}/Google Chrome.app/Contents/MacOS/Google Chrome</code></td><td>Require approval to launch Chrome</td></tr><tr><td><code>{system}/Applications/Calculator.app/Contents/MacOS/Calculator</code></td><td></td></tr></tbody></table>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/reference/macos-protected-path-design-intent.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.