> For the complete documentation index, see [llms.txt](https://newdocs.keeper.io/en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://newdocs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-reference/wildcards.md).

# Wildcards

<figure><img src="/files/zWi5jpdG0tSuUaLaWPeG" alt=""><figcaption></figcaption></figure>

**Audience:** IT admins. Use this when writing policy filters that match many applications or paths without listing each one.

***

## Wildcards

Wildcards let one pattern match many names or paths. How they behave depends on the filter type — that distinction matters more than which policy type you're configuring.

### **Application Filters**

Application Filters support wildcards in paths. `*` matches any characters (regex-style `.*`), path variables are resolved first, and then the pattern is matched. Matching is case-insensitive on Windows and case-sensitive on Linux/macOS. Application filters appear in every policy type that targets an executable — Privilege Elevation, File Access, Command Line, Least Privilege, the Agentic AI policy family (Agentic AI, Agentic Access, Agentic Privilege Elevation), and Custom — so a pattern like `{programfiles}\*\*.exe` works the same way across all of them.

### **Folder Filters**

Folder Filters (the `Extension.Folders` field used primarily by File Access policies) support path variables but use prefix matching only: the folder value is resolved and then evaluated as "does the full path start with this folder?" Wildcards in the folder path are not supported — `{downloads}\*` is treated as a literal `*`. Because matching is prefix-based, a folder filter automatically covers that folder and all of its subfolders without any wildcard.

### **Command-Line ArgumentFilters**

**Command-line argument filters** (used by Command Line policies and by Privilege Elevation policies with command-line scoping) support wildcards in command and argument patterns.

### One Important Caveat

For File Access **DENY** policies with wildcards on Windows, executables in protected paths — `{systemroot}`, `{system32}`, `{programfiles}`, `{programfilesx86}` — are automatically excluded from matching so a broad wildcard can't accidentally block critical OS binaries. This exclusion is enforced at evaluation time and applies only to wildcard denies; explicit-path denies still match normally.

## Application Filter Wildcards

**Supported:**

* **Wildcards in paths:** e.g. `{programfiles}\*\*.exe` — matches any `.exe` in any subfolder of Program Files.
* **Path variables:** e.g. `{userprofile}\Documents\*.exe`, `{downloads}\*.pdf`.
* **Combined:** e.g. `{userprofile}\*\*.exe` — any `.exe` in any subfolder of the user profile.

**How it works:** `*` in the path is treated as “any characters.” The path is normalized, variables are resolved, then the pattern is matched. On Windows matching is case-insensitive; on Linux/macOS it is case-sensitive.

**Examples:**

* `*.exe` — any file ending in `.exe` (in the context where the pattern is applied).
* `{desktop}\*.exe` — any `.exe` on the user’s desktop (variable resolved per user).
* `{programfiles}\*\*.exe` — any `.exe` in any subfolder of Program Files.

## Combined Variable + Wildcard Examples

You can **combine** path variables with one or more `*` segments so a single pattern matches many paths (e.g. different app versions or install locations). Variables are resolved first, then each `*` matches any characters in that path segment.

| Pattern                                                                     | What it matches                                                                                                         |
| --------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `{userprofile}\AppData\Local\GitHubDesktop\*\resources\app\git\cmd\git.exe` | Git bundled with GitHub Desktop, for any version folder (e.g. `app-3.2.1`, `app-3.3.0`) under the user’s Local AppData. |
| `{localappdata}\*\*\*.exe`                                                  | Any `.exe` three levels deep under the user’s Local AppData (covers per-app and versioned folders).                     |
| `{programfiles}\*\*\*.exe`                                                  | Any `.exe` in any subfolder of Program Files (e.g. `C:\Program Files\Vendor\Product\bin\app.exe`).                      |
| `{userprofile}\Documents\*\*.pdf`                                           | Any PDF in any one-level subfolder of the user’s Documents.                                                             |
| `{appdata}\*\*.exe`                                                         | Any `.exe` in any one-level subfolder of the user’s Roaming AppData.                                                    |

**Why combine:** Install paths often include version or build folders (e.g. `GitHubDesktop\app-3.2.1\...`). Using `*` in that segment lets one policy match all versions without updating the rule when the app is updated. See [Reference: Variables](broken://pages/E3BQ3kP4uECttGaKgOlA) for the full list of variables you can use in these patterns.

## Folder Filter (Extension.Folders) — Prefix Matching Only

When a policy uses **Extension.Folders** (or a folder-style filter), the product uses **prefix matching**:

* The folder value can use **path variables** (e.g. `{downloads}`, `{userprofile}`).
* The **full path** of the file being evaluated is checked: does it **start with** the resolved folder path?
* If yes, the folder filter matches (including all files in subfolders).
* **Wildcards in the folder path are not supported.** For example, `{downloads}\*` does **not** mean “any subfolder of Downloads”; the `*` is treated as a literal character.

#### **Examples:**

* Folder `{downloads}` → matches `C:\Users\Jane\Downloads\file.exe` and `C:\Users\Jane\Downloads\subdir\file.exe`.
* Folder `{userprofile}` → matches any file under the user’s profile.
* Folder `{downloads}\*` → **wrong**; use `{downloads}` if you want “everything in Downloads and subfolders.”

## Combining ApplicationCheck and Extension.Folders

{% hint style="info" %}

#### macOS Protected Paths and Wildcard Scope

Learn about [macOS Protected Path Design Intent](/en/keeperpam/endpoint-privilege-manager/deployment/deploy-with-macos/protected-path-design-intent.md) in our [Reference](broken://pages/KvWSRZejdNPlnwjbIFWQ) section.
{% endhint %}

When **ApplicationCheck** contains only a **filename pattern** (e.g. `*.exe`) and **Extension.Folders** is set, the product can combine them during preprocessing:

* Result: full path patterns like `{desktop}\*.exe` or `{downloads}\*.pdf`.
* Those are then evaluated with normal application/path matching (including wildcards in the path).

So you can write “all executables on the desktop” as: ApplicationCheck with `*.exe` (or similar) and Extension.Folders with `{desktop}`. No need to list every path by hand.

## Linux/macOS: Executables without Extensions

On Linux and macOS, many executables have no extension. You can:

* Use a pattern that matches “any file” in a folder (e.g. `*` with Extension.Folders), or
* List common extensions (e.g. `.sh`, `.bin`, `.run` on Linux; `.app`, `.command` on macOS) in ApplicationCheck and combine with Extension.Folders.

Folder filters still use prefix matching only; application patterns support `*` in the path.

{% hint style="info" %}

#### macOS Protected Paths and Wildcard Scope

Learn about [macOS Protected Path Design Intent](/en/keeperpam/endpoint-privilege-manager/deployment/deploy-with-macos/protected-path-design-intent.md) in our [Reference](broken://pages/KvWSRZejdNPlnwjbIFWQ) section.
{% endhint %}

## What to Avoid

* **Folder path with `*`:** e.g. `Extension.Folders: ["{downloads}\\*"]` — the `*` is literal; use `{downloads}` for “all of Downloads.”
* **Expecting wildcards inside folder strings:** Only prefix matching is applied to the resolved folder path.
* **Case on Linux/macOS:** Patterns are case-sensitive; use the correct case for paths and extensions.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://newdocs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-reference/wildcards.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.