# Understanding signing policies

The Signing Policy is an ordered list of rules that the vault evaluates for every signing request. It determines whether a request is approved, denied, or handed off for external evaluation.

![Signing Policy rules view: an ordered Approve rule and a default Deny fallback](/img/guide/signing-policy/understanding.png)
*The Signing Policy. Rules are evaluated top to bottom; the first match wins, with a default deny at the end.*

## First match wins

Rules are evaluated top to bottom. The first rule whose conditions match the incoming request determines the outcome. If no rule matches, the permanent **deny all** baseline at the bottom of the list applies.

This means rule order matters. Put your most specific rules above general ones. A broad "allow" rule placed at the top would match most requests before any restrictions below it can take effect.

## Conditions

Each rule carries a set of conditions. All conditions in a rule are combined with AND; every condition must be true for the rule to match. You can filter on:

* **User groups:** which group the signing identity (human or Machine User) belongs to
* **Key security groups:** which [security group](/guide/keys/security-groups) the requested key belongs to
* **Raw signing:** whether the rule applies to raw signing requests (the `POST /v1/keys/{id}/sign` endpoint)

## Actions

A matching rule triggers one of the following actions:

| Action | Effect |
|---|---|
| **Approve** | The vault proceeds with the MPC signing ceremony |
| **Deny** | The request is rejected immediately |
| **External Rule Server (ERS)** | The vault calls your rule server and waits for its decision |

## The permanent deny-all baseline

The last entry in every Signing Policy is a fixed "deny all" rule. It cannot be removed or reordered. Its purpose is to make the policy deny-by-default: any request that does not match a preceding rule is blocked. You never need to add an explicit catch-all deny; it is already there.

## Enforcement chain

Policy enforcement is split across two sets of nodes to prevent any single component from bypassing controls.

1. The Orchestrator routes the signing request to all three Policy Server nodes.
2. Each Policy Server node independently evaluates the rule list and produces a signed decision.
3. A 2-of-3 consensus of signed decisions is required before proceeding.
4. The Key Store nodes receive the request along with the Policy Server signatures and verify 2-of-3 independently.
5. Only after that verification does each Key Store node participate in the MPC signing ceremony.

The Orchestrator cannot forge a policy approval. The Key Store nodes will not sign without verified policy consensus.

## Signing Policy vs. Administrative Policy

The Signing Policy controls how keys are used for signing. The Administrative Policy (configured separately on the Admin Policy page) controls who can perform administrative actions, including who can modify the Signing Policy itself. See [Administrative Policy](/guide/admin-policy/understanding) for details on governing access to vault management operations.