<commit_before>---
layout: "intro"
page_title: "Policies - Getting Started"
sidebar_current: "gettingstarted-policies"
description: |-
  Policies in Vault control what a user can access.
---

# Policies

Policies in Vault control what a user can access. In
the last section, we learned about _authentication_. This section is
about _authorization_.

For authentication Vault has multiple options or backends that
can be enabled and used. For authorization and policies Vault always
uses the same format. All authentication backends must map identities back to
the core policies that are configured with Vault.

When initializing Vault, there is always one special policy created
that can't be removed: the `root` policy. This policy is a special policy
that gives superuser access to everything in Vault. An identity mapped to
the root policy can do anything.

## Policy Format

Policies in Vault are formatted with
[HCL](https://github.com/hashicorp/hcl). HCL is a human-readable configuration
format that is also JSON-compatible, so you can use JSON as well. An example
policy is shown below:

```javascript
path "secret/*" {
  policy = "write"
}

path "secret/foo" {
  policy = "read"
}

path "auth/token/lookup-self" {
  policy = "read"
}
```

The policy format uses a prefix matching system on the API path
to determine access control. The most specific defined policy is used,
either an exact match or the longest-prefix glob match. Since everything
in Vault must be accessed via the API, this gives strict control over every
aspect of Vault, including mounting backends, authenticating, as well as secret access.

In the policy above, a user could write any secret to `secret/`, except<commit_msg>Updated policy format to use capabilities keyword (#3063)<commit_after>---
layout: "intro"
page_title: "Policies - Getting Started"
sidebar_current: "gettingstarted-policies"
description: |-
  Policies in Vault control what a user can access.
---

# Policies

Policies in Vault control what a user can access. In
the last section, we learned about _authentication_. This section is
about _authorization_.

For authentication Vault has multiple options or backends that
can be enabled and used. For authorization and policies Vault always
uses the same format. All authentication backends must map identities back to
the core policies that are configured with Vault.

When initializing Vault, there is always one special policy created
that can't be removed: the `root` policy. This policy is a special policy
that gives superuser access to everything in Vault. An identity mapped to
the root policy can do anything.

## Policy Format

Policies in Vault are formatted with
[HCL](https://github.com/hashicorp/hcl). HCL is a human-readable configuration
format that is also JSON-compatible, so you can use JSON as well. An example
policy is shown below:

```javascript
path "secret/*" {
  capabilities = ["write"]
}

path "secret/foo" {
  capabilities = ["read"]
}

path "auth/token/lookup-self" {
  capabilities = ["read"]
}
```

The policy format uses a prefix matching system on the API path
to determine access control. The most specific defined policy is used,
either an exact match or the longest-prefix glob match. Since everything
in Vault must be accessed via the API, this gives strict control over every
aspect of Vault, including mounting backends, authenticating, as well as secret access.

In the policy above, a user could write any secret to `secret/`, except
{'fraction_non_alphanumeric': 0.06300345224395858, 'fraction_numerical': 0.0011507479861910242, 'mean_word_length': 4.5015822784810124, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2491344', 'n_tokens_mistral': 920, 'n_tokens_neox': 904, 'n_words': 488}