> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-examples/policy-global-allow-file-access-require-approval.md).
# Wildcard Allow File Access with Require Approval
This example shows a **File Access Policy** used as a **Wildcard Approval Requirement for running applications**. When enabled, it applies to any application a user tries to launch, creating a single, top‑level control point across all endpoints. After this **Wildcard File Access Policy** is in place, additional policies can be added to allow specific applications, teams, or scenarios to run without approval.
## What this Policy Does
When a user on any **in-scope endpoint** tries to run an application:
1. The request is evaluated by the **File Access** policy engine.
2. Because the policy is broadly scoped (all users, all applications), it matches most execution attempts on those endpoints.
3. The policy requires **Approval** within the **Admin Console** before allowing the action to proceed.
### Why it Behaves this Way
This policy is intentionally written as a “broad match” policy, then applies a control:
* **Enforced**: The policy is active and will apply controls (not just log).
* **Approval control on success**: When the policy matches, it triggers an approval workflow.
* **All users**: A wildcard user filter makes it apply to any user account on in-scope machines.
* **All applications**: A wildcard application filter makes it apply to any application being evaluated by this File Access policy.
* **Built-in checks**: Standard checks (user, machine, file, date/time/day, certificate) are present. If those constraints aren’t narrowed (for example, no date/time/day/cert restrictions are provided), the policy behaves like a broad catch-all for execution on the targeted endpoints.
### What the User Experiences
* Most application launches on the targeted endpoints will generate an **approval request**.
* The policy includes a user-facing notification message. If the message references a specific date or one-off event, replace it with something generic (or remove it) to avoid confusion in production.
## Important Notes and Common Adjustments
* **High prompt volume**: Because this applies to *all* applications, it can create a lot of approvals—especially when expanded to many endpoints.
* **Narrow the scope** if needed:
* Restrict the application filter to a specific set of executables or paths
* Restrict the user filter to specific users/groups
* Add certificate/publisher constraints to treat trusted vs. untrusted software differently
* Add time/day/date restrictions for staged rollouts or business-hours-only enforcement
## How Build a Wildcard File Access Policy with Required Approval
{% stepper %}
{% step %}
**Create Policy**
From the **Policies** tab of the Admin Console's Endpoint Privilege Manager page, click the **Create Policy** button.
This will open the **Create Policy Form** in a modal window.
{% endstep %}
{% step %}
**Policy Name**
Enter a descriptive name for your new Wildcard File Access Policy.
{% endstep %}
{% step %}
**Policy Type**
Select **File Access** from the **Policy Type** select list.
{% endstep %}
{% step %}
**Status**
Select the status that you would like your new **Wildcard File Access Policy** to be in upon submission of the completed **Create Policy** form.
{% endstep %}
{% step %}
**Controls**
Select **Admin Approval** under Required Access Controls.
{% endstep %}
{% step %}
**Account Collections**
Click inside the **"Add Accounts"** field, then select the **"Select All"** checkbox in the Accounts form field. This does not add each account collection to the policy individually. Instead, selecting all accounts applies a wildcard rather than creating a list of individual Account Collection IDs.
{% endstep %}
{% step %}
**Machine Collections**
Click inside the **"Add Machines"** field, then select the **"Select All"** checkbox in the Machines form field. This does not add each machine collection to the policy individually. Instead, selecting all machines applies a wildcard rather than creating a list of individual Machine Collection IDs.
{% endstep %}
{% step %}
**Application Collections**
Click inside the **"Add Applications"** field, then select the **"Select All"** checkbox in the Applications form field. This does not add each application collection to the policy individually. Instead, selecting all applications applies a wildcard rather than creating a list of individual Application Collection IDs.
{% endstep %}
{% step %}
**Date & Time**
For a **Wildcard File Access Policy,** it is recommended that the **Date and Time Ranges** be set to **Always**, ensuring the block is continuously enforced with no time-based gaps.
{% endstep %}
{% step %}
**Save Your New Wildcard File Access Policy**
Once the form has been sufficiently filled in per the previous steps, the **Save** button will be changed from an inactive to an active state. Click on the **Save** button. The **Create Policy** modal form will be closed and your **Wildcard File Access Policy** will be saved.
Why this Wildcard File Access Policy Should be your First Policy
This pattern — a **Wildcard File Access** which **Requires Approval** that catches everything by default — serves a very specific and important strategic purpose in endpoint privilege management. Here's a full breakdown of the use-cases and the reasoning behind it:
### The Core Concept: "Default-Deny via Default-Require-Approval"
Rather than trying to enumerate every dangerous application upfront (which is nearly impossible), this approach **inverts the model**: everything requires approval by default, and you then carve out exceptions for trusted, known-good applications. It's conceptually similar to a default-deny firewall rule at the bottom of a ruleset.
### Primary Use-Cases
#### 1. Regulated or High-Security Environments
Organizations subject to compliance frameworks like HIPAA, PCI-DSS, SOC 2, or government/defense mandates often need to demonstrate that **no unauthorized software can execute** on managed endpoints without a documented approval chain. A wildcard file access with required approval as a wildcard policy creates a single, auditable control point for every application launch.
#### 2. Application AllowListing Rollouts
This policy is the ideal **foundation layer** when an organization is building out an application allowlist. Rather than blocking everything immediately (which would be disruptive), you:
* Start with a wildcard approval requirement within a wildcard policy (less disruptive — users can still run things, but must request approval)
* Observe what gets requested
* Add targeted **Allow policies** above it for IT-approved software (approved apps pass through without triggering the approval gate)
* Over time, transition toward a true deny policy at the wildcard once the allowlist matures
This policy structure is intentionally written as a "broad match" policy that applies a control — because the user and application filters both use wildcards, it functions as a broad catch-all for execution on targeted endpoints.
#### 3. Pilot or Phased Deployment
This type of policy is useful for demonstrating how to introduce an approval workflow for application execution across a group of endpoints — for example, a pilot group or a department. Security teams can validate the approval workflow, tune approver capacity, and build the exception list before rolling out to the full fleet.
#### 4. Zero-Trust Endpoint Posture
In a zero-trust model, **implicit trust is eliminated** — even for standard user applications. A wildcard file access with required approval as a wildcard policy enforces that posture at the execution layer. No application is implicitly trusted simply because it's present on the machine.
#### 5. Incident Response / Breach Containment
If an organization has experienced (or suspects) a compromise, this policy can be rapidly deployed to **lock down a segment of endpoints** — requiring every application launch to be human-approved — while the investigation proceeds, without immediately blocking everything and causing a full outage.
#### 6. High-Risk User Groups or Machines
For specific populations like contractors, third-party vendors, or endpoints in sensitive network segments (e.g., OT adjacent, finance systems), a wildcard approval policy provides maximum oversight without requiring granular per-app policy authoring upfront.
## Why File Access Policy (Not Privilege Elevation) for the use-cases?
This is a nuanced but important distinction. A **File Access policy** intercepts the *execution* of a file (the moment an application is launched), while a Privilege Elevation policy only intercepts attempts to run something with elevated privileges. By using File Access here, the approval requirement applies to **any application launch** — regardless of whether the user needs admin rights — giving broader coverage.
### The Layered Policy Strategy That Follows
Implement sophisticated policy combinations using layered policies — applying multiple policies to the same resources for defense-in-depth. Once this wildcard file access policy is in place, the operational model looks like this:
Priority
Policy
Scope
High
Allow — IT-approved apps (browsers, Office, etc.)
Specific apps, all users
High
Allow — Developer tools
Specific users/groups
Low (catch-all)
Require Approval — Everything else
All users, all apps
Applications matched by a higher-priority Allow policy pass silently. Anything not explicitly allowed falls through to the wildcard file access policy with required approval.
## Key Operational Consideration
Because this policy applies to all applications, it can create a high volume of approval requests — especially when expanded to many endpoints. This is why the documentation recommends starting with a **pilot group** and building out the exception (Allow) policies *before* broad deployment. Deploying in batches while monitoring system performance and user feedback, and adjusting policies based on operational requirements, is the recommended approach.
---
# 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://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-examples/policy-global-allow-file-access-require-approval.md?ask=&goal=
```
`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.