# Configuring Installation Policies

You can set installation policies for each ecosystem independently. This lets you control what happens when someone on your team tries to install a new package.

## Accessing policy settings

Go to [Endpoint Protection and open the Settings tab](https://app.aikido.dev/endpoint-protection/settings). You will see a list of all supported ecosystems with their current policy status. Click on any ecosystem to configure its settings.

<figure><img src="https://3149773201-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyKbzcQGrx7UtrG0nPZZ7%2Fuploads%2FbtXl1STbRbZgWzR63zHE%2FScreenshot%202026-04-09%20at%2012.34.40.png?alt=media&#x26;token=e7fc1d6d-4d49-4bcf-9529-a276d113d449" alt=""><figcaption></figcaption></figure>

## How Aikido decides to block or allow a package

When someone tries to install a package, Aikido evaluates the following rules in order. It stops at the first rule that matches.

{% hint style="info" %}
**In short:** Malware and explicit block rules take priority over everything. Explicit allow rules and approved requests come next. Then global blocks and approval requirements apply. If nothing matches, the install goes through.
{% endhint %}

* Rule 0 - Malware is always blocked. If the package is identified as malware, the install is blocked. No exceptions or policies can override this.
* Rule 1 - Group exceptions that block a specific package always win. If there is an exception that blocks this specific package for the user's group, the install is blocked.
* Rule 2 - Group exceptions that allow a specific package, or a previously approved request, always win: If there is an exception that allows this specific package for the user's group, or if an admin previously approved a request for this package, the install is allowed.
* Rule 3 - "Block All Installs" blocks everything else. If "Block All Installs" is enabled for the ecosystem (either as the default setting or through a group exception), the install is blocked.
* Rule 4 - "Force Requests" requires approval. If "Force Requests" is enabled (either as the default setting or through a group exception), and the package has not been previously requested or was previously denied, the install is held and a request is sent to the Inbox.
* Rule 5 - Everything else is allowed. If none of the above rules match, the package is installed normally.

## Available controls

<figure><img src="https://3149773201-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyKbzcQGrx7UtrG0nPZZ7%2Fuploads%2F9Czn43yrBpFD2HpMLNbI%2Fimage%20(4).png?alt=media&#x26;token=24d39820-e728-4c11-a0cf-499e724063bd" alt=""><figcaption></figcaption></figure>

### Block All Installs

When enabled, all installations from that ecosystem are blocked on connected devices. No new packages can be installed until you turn this off or create an exception.

Use this when you want to fully lock down an ecosystem for your organization.

### Force Requests for New Packages

When enabled, team members cannot install new packages on their own. Instead, their install attempt is sent to the **Inbox** as a request for an admin to review. The admin can then approve or reject it.

This is a good middle ground when you want oversight without completely blocking installs.

### Minimum Package Age

Sets how long a package must have existed before it can be installed. For example, if set to 24 hours, any package published less than 24 hours ago will be blocked.

This helps protect against supply chain attacks, where an attacker publishes malicious code to a public registry and tries to get people to install it before the community can flag it.

## Exceptions

Exceptions let you override your default policies for specific packages or user groups. This is useful when your default policy is strict but certain teams need access to specific tools.

For example, you might block all Chrome extensions by default but allow a set of approved extensions for your Product team. Or you might require approval for all NPM installs but let your engineering group install trusted libraries without waiting.

### Adding an exception

1. Go to **Endpoint Protection** and open the **Settings** tab.
2. Click on the ecosystem you want to configure.
3. Scroll down to the **Exceptions** section.
4. Click **Add Exception**.
5. Choose a policy type, specify the packages or values it applies to, and select the user groups it targets.

{% hint style="warning" %}
Package identifiers vary by ecosystem. [Double-check the correct identifier before adding an exception](https://help.aikido.dev/aikido-endpoint-protection/miscellaneous-aikido-endpoint/package-identifiers).
{% endhint %}

<figure><img src="https://3149773201-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyKbzcQGrx7UtrG0nPZZ7%2Fuploads%2Fj0nAHuYm2fw7q04DUtTd%2FScreenshot%202026-03-25%20at%2010.35.47.png?alt=media&#x26;token=af3e46e3-92ec-44f0-a50b-148309d0617b" alt="" width="556"><figcaption></figcaption></figure>

### Exception types

**Allow specific package(s)** allows specific packages to be installed, even if the ecosystem is set to "Block All Installs" or "Force Requests." You can list one or more packages and assign the exception to specific user groups.

**Block specific package(s)** blocks specific packages for the selected user groups, even if the default policy would allow them. Use this to prevent known risky packages from being installed.

**Block all installs** blocks all installs from the ecosystem for specific user groups, even if the default policy allows them. Use this when you want to lock down a group without changing the setting for the whole organization.

**Force requests for new packages** requires admin approval for new installs within the selected user groups, even if the default policy does not require it. This lets you add an approval step for specific teams without turning it on for everyone.