RAR enforcement

You can use Rich Authorization Requests (RAR) to include fine-grained authorization constraints in the authorization details claim in OAuth tokens. Vault uses the provided constraints to enforce path-level and parameter-level access control beyond what standard ACL policies provide.

Default behavior

Vault enables RAR by default, and OAuth 2.0 tokens with authorization_details always honor the RAR authentication details.

If the JWT does not contain an authorization_details claim for a RAR, Vault rejects the request with an error indicating that the claim is required.

We recommend using RAR for all agentic workflows to enable fine-grained authorization constraints.

How RAR constraints work

RAR constraints narrow the access granted by ACL policies. For a request to succeed all of the following must be true:

1. The request path and operation must match at least one path and capabilities constraint in the RAR.
2. The ACL policy associated with the entity must permit the operation.
3. When a matching RAR constraint includes allowed_parameters, the request parameters must satisfy those constraints.

RAR constraints only restrict access and cannot expand permissions beyond what ACL policies allow.

Interaction with ACL policies

RAR constraints work alongside Vault ACL policies, not as a replacement. Both ACL policies and RAR constraints must permit an operation for the operation to succeed.

Vault ACL policies also support allowed_parameters, denied_parameters, and required_parameters. When both policy-level and RAR-level controls are present:

• RAR constraints narrow policy permissions: RAR can only further restrict what policies allow
• Denied parameters take precedence: When either policy or RAR denies a parameter, Vault denies the parameter
• Allowed parameters are intersected: A parameter must be allowed by both policy and RAR
• Required parameters are combined: All required parameters from both sources must be present

For example, you can define a Vault policy that allows create and update actions with data and metadata fields:

path "secret/data/*" {
  capabilities = ["create", "update"]
  allowed_parameters = {
    "data" = []
    "metadata" = []
  }
}

Then add an additional RAR constraint on the associated OAuth token that only allows updates to the data parameter:

{
  "type": "vault:path_access",
  "path": "secret/data/app-config",
  "capabilities": ["create", "update"],
  "allowed_parameters": {
    "data": []
  }
}

As a result, Vault only allows agents to update the data parameter on the secret/data/* path, which represents intersection of policy and RAR contraints.

Multiple RAR constraints

A JWT can include multiple authorization detail objects in the authorization_details array. Vault evaluates each constraint independently and allows the request when the request matches at least one constraint that permits the operation.

For example, the following JWT allows:

• Reading from database/creds/readonly-role
• Creating or updating at pki/issue/my-role (with common_name required)
• Reading or listing from secret/data/app-* paths (except version 1)

{
  "authorization_details": [
    {
      "type": "vault:path_access",
      "path": "database/creds/readonly-role",
      "capabilities": ["read"]
    },
    {
      "type": "vault:path_access",
      "path": "pki/issue/my-role",
      "capabilities": ["create", "update"],
      "required_parameters": ["common_name"]
    },
    {
      "type": "vault:path_access",
      "path": "secret/data/app-*",
      "capabilities": ["read", "list"],
      "denied_parameters": {
        "version": ["1"]
      }
    }
  ]
}