# Understanding Administrative Policy

Administrative Policy answers one question: who is allowed to do what in the vault? It controls every administrative action, from creating users to changing policy itself. Read this page before editing anything.

![Administrative Policy showing the action list and a configured Manage Users rule](/img/guide/admin-policy/understanding.png)
*The Administrative Policy. Each action (left) maps to the groups allowed to perform it.*

## The core principle: deny by default

Every action in the vault starts in a denied state. If no rule exists for an action, nobody can perform it, regardless of their group memberships or seniority.

This means the policy is not a blocklist. It is an allowlist: you explicitly grant each action to specific groups. Anything not mentioned is blocked.

:::warning\[Implications at bootstrap]
A freshly deployed vault has no rules for most actions. The only exception is **Modify Admin Policy**, which is pre-configured to allow the initial Admins group so the first administrators can configure the rest. Every other action must be granted explicitly before anyone can use it.
:::

## The governed actions

Administrative Policy covers twelve distinct actions. Each action maps to a specific category of vault operation.

| Action | What it permits |
|---|---|
| Manage Users | Create, edit, and delete human users and machine users and agents |
| Manage User Groups | Create, edit, and delete groups; add and remove members |
| Modify Admin Policy | Change Administrative Policy rules |
| Modify Signing Policy | Change Signing Policy rules |
| Freeze Keys | Freeze individual keys, bulk-freeze all keys |
| Unfreeze Keys | Unfreeze individual keys, bulk-unfreeze all keys |
| Import/Generate Keys | Create new API keys, import HMAC secrets, generate Ed25519 and RSA keys |
| Delete Keys | Permanently delete keys |
| View System Resources | Read-only access to see keys, users, groups, and policies |
| Configure Venues | Create, edit, and delete venue configurations |
| Access Keys Backup | Download the encrypted key backup |
| View and Export Audit Log | View and CSV-export audit log entries |

:::tip
**Freeze Keys** and **Unfreeze Keys** are intentionally separate actions. A common pattern is to grant Freeze Keys to a broader operations group (so anyone on-call can halt signing in an emergency) while restricting Unfreeze Keys to a smaller senior group (to ensure a deliberate decision before signing resumes).
:::

## Mapping actions to groups

For each action you configure which groups are allowed to perform it. A user must belong to at least one of those groups.

Groups can contain both human users and machine users and agents. Assigning a machine user's group to an action grants that machine the capability when it calls the API.

A user who belongs to multiple groups gains the union of capabilities those groups provide.

## The bootstrap exception

During initial setup, the only action that has a rule is **Modify Admin Policy**, pre-assigned to the Admins group created at deployment. This lets the first administrators log in and grant the remaining actions without being locked out.

Every other action remains denied until you explicitly add a rule. The [onboarding card](/guide/getting-started/first-login) on the dashboard prompts you through the minimum steps to get the vault usable.

## How enforcement works

When a user or machine attempts an action:

1. The vault checks the user's group memberships against the current Administrative Policy.
2. If the action has no matching rule, the request is denied.
3. If a matching rule exists, the action proceeds directly (after passkey verification for state-changing actions performed by human users).

Policy enforcement is cryptographically consistent across all three vault nodes. No single node can override the policy, and the policy cannot be changed without the passkey-signed draft-and-submit workflow described in [Configure your admin policy](/guide/admin-policy/configure).