Set up OBO delegation

Enterprise

Appropriate Vault Enterprise license or HCP Vault Dedicated cluster required.

Use Vault Enterprise and your ID provider to implement zero trust principles with delegated ephemeral and narrowly scoped agent credentials. Accept JWTs with RAR authorization details, and OBO semantics as means to perform authorized operations on Vault.

Before you start

You must have a Vault Enterprise or HCP Vault Dedicated server deployed.
You must configure an identity or OAuth provider that supports OBO:
- Use IBM Verify for agent IAM
- Use Auth0 for agent IAM
You must have admin permissions on Vault. You need a Vault token with sufficient ACL policies attached to configure and modify your Vault deployment.

Step 1: Create an OAuth resource server profile

Create an OAuth resource server configuration file called verify-oauth.json using the environment variables you saved during provider setup:
```
$ cat > verify-oauth.json << EOF
{
  "issuer_id":            "${ISSUER}",
  "use_jwks":             true,
  "user_claim":           "sub",
  "supported_algorithms": ["RS256"],
  "jwks_uri":             "${JWKS_URI}"
}
EOF
```
IBM Verify limitation
Avoid validating with the audiences value with Verify STS clients as the client performing the OBO token exchange with RAR authorization details does not support audience mapping in the access token mapping.

Create an OAuth resource server profile using the JSON file:

$ vault write sys/config/oauth-resource-server/verify @verify-oauth.json

WARNING! The following warnings were returned from Vault:
* algorithm "RS256" is functional but consider using PS256 (RSA-PSS) for
better security
* profile supports only one algorithm family - consider supporting multiple
families for flexibility

Read the profile to check for correctness.

$ vault read sys/config/oauth-resource-server/verify

Key                     Value
---                     -----
audiences               [https://localhost:8200/v1]
clock_skew_leeway       0
config_id               de81dc66-e00d-23c6-7dfc-9cdbc5aaf97e
enabled                 true
issuer_id               https://mydomain.verify.ibm.com/oauth2
jwks_uri                https://mydomain.verify.ibm.com/oauth2/jwks
jwt_type                access_token
no_default_policy       false
profile_name            verify
supported_algorithms    [RS256]
use_jwks                true

Create an OAuth resource server profile using JWKS mode to fetch the signing keys from Auth0.

Create an OAuth resource server configuration file called auth0-oauth.json using the previously stored environment variables and both ES256 and PS256 algorithms recommended by Auth0:

$ cat > auth0-oauth.json <<EOF
{
  "issuer_id": "${ISSUER}",
  "use_jwks": true,
  "audiences": ["${AUDIENCE_ADDR}"],
  "user_claim": "sub",
  "supported_algorithms": ["ES256", "PS256"],
  "jwks_uri": "${JWKS_URI}"
}
EOF

Create an OAuth resource server profile using the JSON file:

$ vault write sys/config/oauth-resource-server/auth0 @auth0-oauth.json

Success! Data written to: sys/config/oauth-resource-server/auth0

Read the profile to check for correctness.

$ vault read sys/config/oauth-resource-server/auth0

Key                     Value
---                     -----
audiences               [<audience_address>]
clock_skew_leeway       0
config_id               d2838e74-86b6-ef9f-5a8c-c0ff33e095fc
enabled                 true
issuer_id               <iss_url_from_auth0_app>
jwks_uri                <jwks_url_from_auth0_app>
jwt_type                access_token
no_default_policy       false
profile_name            auth0
supported_algorithms    [ES256 PS256]
use_jwks                true
user_claim              sub

Vault trims trailing slash from issuer URL

Vault normalizes issuer_id by trimming any trailing slash and casting the URL to lowercase while the iss claim for Auth0 ends in a slash (e.g., https://...auth0.com/). The trailing slash difference is expected.

Export the config_id for use in creating entity aliases.

$ export APP_CONFIG_ID="d2838e74-86b6-ef9f-5a8c-c0ff33e095fc"

Step 2: Create Vault entities for the external users

Map your external agent and human users to Vault entities.

Create a new subject entity in for the human user.

$ vault write identity/entity name="obo-human" external_id="${SUBJECT_EXT_ID}"

Key        Value
---        -----
aliases    <nil>
id         0427b0f5-ac11-4f25-75f6-5764b85176aa
name       obo-human

Create a new actor entity for the AI agent user.

$ vault write identity/entity name="obo-agent" external_id="${ACTOR_EXT_ID}"

Key        Value
---        -----
aliases    <nil>
id         ef897bd9-0060-1fa4-68ba-65ae5b0747ec
name       obo-agent

Save the IDs created for the human and agent entities to environment variables for later use:

$ export
  OBO_HUMAN_CANONICAL_ID="0427b0f5-ac11-4f25-75f6-5764b85176aa" \
  OBO_AGENT_CANONICAL_ID="ef897bd9-0060-1fa4-68ba-65ae5b0747ec"

Create a new subject entity in for the human user.

$ vault write identity/entity name="obo-human"

Key        Value
---        -----
aliases    <nil>
id         1b75bc66-28e3-9126-5c18-c0ff33d83c5c
name       obo-human

Create a new actor entity for the AI agent user.

$ vault write identity/entity name="obo-agent" external_id="${EXTERNAL_ID}"

Key        Value
---        -----
aliases    <nil>
id         0ca161e7-a74e-2827-f3a1-c0ff331f1599
name       obo-agent

Save the IDs for the human and agent entities to environment variables:

$ export
  OBO_HUMAN_CANONICAL_ID="1b75bc66-28e3-9126-5c18-c0ff33d83c5c" \
  OBO_AGENT_CANONICAL_ID="0ca161e7-a74e-2827-f3a1-c0ff331f1599"

Save the external IDs for the human and agent identities. Use the ${EXTERNAL_ID} value provided by Auth0 for the agent, and a unique identity for the human user. For example:

$ export                                         \
  HUMAN_USER_EXTERNAL_ID='auth0|obo-<name>-0001' \
  AGENT_EXTERNAL_ID="${EXTERNAL_ID}"

Step 3: Create entity aliases

Create aliases for the newly created Vault entities.

Normally, creating an entity alias requires a mount_accessor value. If you provide both an external ID and an issuer that matches your OAuth resource server profile, Vault synthesizes the correct mount accessor for you when you create aliases for agentic IAM.

Instead of associating the generated alias with an auth mount, the alias points to the issuer that grants access for the alias. Vault uses the following format for the mount accessor synthesis:

oauth-resource-server + _ + <namespace ID> + _ + <server profile config ID>

For example, a mount accessor in the root namespace would be:

oauth-resource-server_root_de81dc66-e00d-23c6-7dfc-9cdbc5aaf97e

Create an entity alias for the human user entity:

$ vault write identity/entity-alias        \
  name="jwt-binding-subject"               \
  canonical_id="${OBO_HUMAN_CANONICAL_ID}" \
  issuer="${ISSUER}"                       \
  external_id="${SUBJECT_EXT_ID}"

Key             Value
---             -----
canonical_id    0427b0f5-ac11-4f25-75f6-5764b85176aa
id              e3b9d5b0-c623-1f02-b1ef-95503ad7be03

Create an entity alias for the agent entity:

$ vault write identity/entity-alias         \
  name="jwt-binding-actor"                  \
  canonical_id="${OBO_AGENT_CANONICAL_ID}"  \
  issuer="${ISSUER}"                        \
  external_id="${ACTOR_EXT_ID}"

Key             Value
---             -----
canonical_id    ef897bd9-0060-1fa4-68ba-65ae5b0747ec
id              e929f437-f655-45c0-03e7-eb6212dba58d

Create an entity alias for the human user entity:

$ vault write identity/entity-alias         \
    name="jwt-binding-subject"              \
    canonical_id="${OBO_USER_CANONICAL_ID}" \
    issuer="${ISSUER}"                      \
 external_id="${HUMAN_USER_EXTERNAL_ID}"

Key             Value
---             -----
canonical_id    1b75bc66-28e3-9126-5c18-c0ff33d83c5c
id              5d463c84-d185-90df-0caf-c0ff33d0e165

Create an entity alias for the agent entity:

$ vault write identity/entity-alias          \
    name="jwt-binding-actor"                 \
    canonical_id="${OBO_AGENT_CANONICAL_ID}" \
    issuer="${ISSUER}"                       \
    external_id="${AGENT_EXTERNAL_ID}"

Key             Value
---             -----
canonical_id    0ca161e7-a74e-2827-f3a1-c0ff331f1599
id              a89e280e-f4b8-fe5d-3e79-c0ff33c7366c

Warning

The issuer field is required. An alias created without issuer= validates successfully but later causes JWT authentication to fail server-side with no alias found / error looking up entity. This is the single most common configuration mistake. You must set issuer on every OAuth resource server alias.

Step 4: Create a ceiling policy

Create a ceiling policy to encompass all the possible operations the agent might perform.

Create a policy configuration file called ceiling-policy.hcl. For example, to restrict access on the kv, pki, and transit plugins:

$ cat > ceiling-policy.hcl << EOF
# Allow KV2 read and write
path "secret-v2/data/shared-secret/*" {
  capabilities = ["read", "list", "update"]
}

path "secret-v2/metadata/shared-secret/*" {
  capabilities = ["list"]
}

# Allow PKI operations
path "pki/issue/example-dot-com" {
  capabilities = ["create", "update"]
}

path "pki/cert/*" {
  capabilities = ["read"]
}

path "pki/certs" {
  capabilities = ["list"]
}

# Allow transit engine operations
path "transit/encrypt/app-key" {
  capabilities = ["update", "create", "read"]
}

# Allow decrypt
path "transit/decrypt/app-key" {
  capabilities = ["update", "create", "read"]
}

# Optional: allow key metadata read (safe)
path "transit/keys/app-key" {
  capabilities = ["read"]
}
EOF

Write the ceiling policy to Vault:

$ vault policy write ceiling-all ceiling-policy.hcl

Success! Uploaded policy: ceiling-all

Step 5: Register the agent with Vault

Create an entry in the Vault agent registry using the canonical ID of the agent entity and your ceiling policy:

$ vault write agent-registry/register      \
    display_name="<descriptive_name>"      \
    description="<meaningful_description>" \
    entity_id="${OBO_AGENT_CANONICAL_ID}"  \
    ceiling_policies='["ceiling-all"]'

For example:

$ vault write agent-registry/register        \
    display_name="obo-danielle-agent"        \
    description="Personal code review agent" \
    entity_id="${OBO_AGENT_CANONICAL_ID}"    \
    ceiling_policies='["ceiling-all"]'

Key             Value
---             -----
display_name    obo-danielle-agent
id              ef897bd9-0060-1fa4-68ba-65ae5b0747ec

Step 6: Create temporary resources for testing

You can use KV version 2 operations with delegated RAR tokens to validate the ACL and ceiling policies. Vault does not consider actor (agent) policies when performing OBO operations. Vault only uses the intersection of the ceiling policy, policies assigned to the human user, and RAR constraints to evaluate agent access.

Enable a KV version 2 secrets engine at the path secret-v2.

$ vault secrets enable -path=secret-v2 kv-v2

Success! Enabled the kv-v2 secrets engine at: secret-v2/
Create a policy to perform KV operations and link it to the subject entity.

Create a policy file called kv2-policy.hcl with full access for the human (subject) entity:

$ cat > kv2-policy.hcl <<'EOF'
path "secret-v2/data/shared-secret/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "secret-v2/metadata/shared-secret/*" {
capabilities = ["list"]
}
EOF

Write the new policy to Vault.

$ vault policy write kv2-policy kv2-policy.hcl
Success! Uploaded policy: kv2-policy

Check existing policies for the human user entity (obo-human). Vault should return an empty list for the policy assignment:

$ vault read identity/entity/name/obo-human
Key                    Value
---                    -----
aliases                [map[canonical_id:dfee09b9-3b37-0ff3-0324-49b4909c566c creation_time:2026-06-16T12:03:12.361169Z custom_metadata:<nil> id:124d59ef-2efe-af30-bdda-c4cc9be4e184 last_update_time:2026-06-16T12:03:12.361169Z local:false merged_from_canonical_ids:<nil> metadata:<nil> mount_accessor:oauth-resource-server_root_774005a7-6e38-d8cf-37ce-9b91b2910322 name:jwt-binding-subject]]
creation_time          2026-06-16T12:03:12.085015Z
direct_group_ids       []
disabled               false
group_ids              []
id                     dfee09b9-3b37-0ff3-0324-49b4909c566c
inherited_group_ids    []
last_update_time       2026-06-16T12:23:59.527254Z
merged_entity_ids      <nil>
metadata               <nil>
mfa_secrets            map[]
name                   obo-human
namespace_id           root
policies               []

Link the kv-policy policy to the obo-human entity:

$ vault write identity/entity/name/obo-human policies='kv2-policy'

Verify the policy linkage:

$ vault read identity/entity/name/obo-human
Key                    Value
---                    -----
aliases                [map[canonical_id:dfee09b9-3b37-0ff3-0324-49b4909c566c creation_time:2026-06-16T12:03:12.361169Z custom_metadata:<nil> id:124d59ef-2efe-af30-bdda-c4cc9be4e184 last_update_time:2026-06-16T12:03:12.361169Z local:false merged_from_canonical_ids:<nil> metadata:<nil> mount_accessor:oauth-resource-server_root_774005a7-6e38-d8cf-37ce-9b91b2910322 name:jwt-binding-subject]]
creation_time          2026-06-16T12:03:12.085015Z
direct_group_ids       []
disabled               false
group_ids              []
id                     dfee09b9-3b37-0ff3-0324-49b4909c566c
inherited_group_ids    []
last_update_time       2026-06-16T12:23:59.527254Z
merged_entity_ids      <nil>
metadata               <nil>
mfa_secrets            map[]
name                   obo-human
namespace_id           root
policies               [kv2-policy]

Tip

To clear the policy from an entity, you can write a set of empty quotes:

$ vault write identity/entity/name/obo-human policies=''

Step 7: Validate the OBO flow

Create an authorization details file, rarRequest.json, that only allows create and read access to kv secrets:

{
  "type": "vault:path_access",
  "path": "secret-v2/data/shared-secret/foo",
  "capabilities": ["create", "read"]
}

Use curl to request a delegation token from Verify and save it to an environment variable:

$ export AGENT_TOKEN=$(curl --request POST             \
    --variable authz_request=[@rarRequest.json]        \
    --expand-data                                      \
    --data 'authorization_details=[{{authz_request}}]' \
    ${ISSUER} | jq -r '.access_token)

Use the delegation token from the token exchange to write a new secret:

$ echo '{"data": {"foo": "bar"}}' | \
  VAULT_TOKEN=${DELEGATION_TOKEN} vault write secret-v2/data/shared-secret/foo -

Key                Value
---                -----
created_time       2026-06-11T07:41:13.074Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

Try to perform vault write secret write on the same path to update the secret:

$ echo '{"data": {"foo": "bar_new"}}' | VAULT_TOKEN=${DELEGATION_TOKEN} \
  vault write secret-v2/data/shared-secret/foo -

Error writing data to secret-v2/data/shared-secret/foo: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/secret-v2/data/shared-secret/foo
Code: 403. Errors:
* 2 errors occurred:
    * RAR_NO_MATCH: No valid authorization_details claim found matching this request.
    * permission denied

Vault prohibits the update because the current RAR policy only allows create and read.

Update rarRequest.json to include update and delete permission:

{
  "type": "vault:path_access",
  "path": "secret-v2/data/shared-secret/foo",
  "capabilities": ["create", "read", "update", "delete"]
}

Request an updated RAR token:

$ export AGENT_TOKEN=$(curl --request POST             \
    --variable authz_request=[@rarRequest.json]        \
    --expand-data                                      \
    --data 'authorization_details=[{{authz_request}}]' \
    ${ISSUER} | jq -r '.access_token)

Update the existing secret:

$ echo '{"data": {"foo": "bar_new"}}' | VAULT_TOKEN=${DELEGATION_TOKEN} \
  vault write secret-v2/data/shared-secret/foo -
Key                Value
---                -----
created_time       2026-06-11T08:02:39.161111Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            2

Read the new secret value with the updated token:

$ VAULT_TOKEN=${DELEGATION_TOKEN} vault read secret-v2/data/shared-secret/foo

Key         Value
---         -----
data        map[foo:bar_new]
metadata    map[created_time:2026-06-11T08:04:13.817972Z custom_metadata:<nil> deletion_time: destroyed:false version:2]

Try to delete the secret value with the updated token:

$ VAULT_TOKEN=${DELEGATION_TOKEN} vault delete secret-v2/data/shared-secret/foo

Error deleting data from secret-v2/data/shared-secret/foo: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/secret-v2/data/shared-secret/foo
Code: 403. Errors:
* 2 errors occurred:
    * RAR_NO_MATCH: No valid authorization_details claim found matching this request.
    * permission denied

Vault prohibits the delete even though the current RAR policy allows delete because the ceiling policy on the agent does not.

Create a helper script that uses two environment variables (RAR_PATH and RAR_ACTION) along with oauth2 to push authorization requests to the PAR endpoint of your Auth0 tenant with the RAR claim in authorization_details.

The request URI returned by the script is short-lived (30 seconds) and single use. If you wait too long, refresh the URL, or open it once with curl before using the browser, Auth0 shows an Oops!, something went wrong page with invalid_request_uri: request_uri not found.

Create get-rar-auth-token-url.sh with the following example code:

# !/usr/bin/env bash
# rar-authorize-url.sh: RAR token authorization automation script

 set -euo pipefail

 : "${APP_ID:?Set APP_ID first.}"
 : "${SECRET_VALUE:?Set SECRET_VALUE first.}"

 if [ -z "${APP_DOMAIN:-}" ]; then
     : "${APP_AUTH_URL:?Set APP_DOMAIN or APP_AUTH_URL first.}"
     APP_DOMAIN="${APP_AUTH_URL#https://}"
     APP_DOMAIN="${APP_DOMAIN%%/*}"
 fi
 APP_DOMAIN="${APP_DOMAIN#https://}"
 APP_DOMAIN="${APP_DOMAIN%%/*}"

 CODE_VERIFIER="$(openssl rand -base64 96 | tr -d '\n=+/' | cut -c1-64)"
 CODE_CHALLENGE="$(printf '%s' "${CODE_VERIFIER}" | \
     openssl dgst -binary -sha256 |                 \
     openssl base64 | tr '+/' '-_' | tr -d '=\n')"
 AUTHORIZATION_DETAILS="$(jq -cn        \
     --arg path "${RAR_PATH}"           \
     --arg action "${RAR_ACTION:-read}" \
     '[{type:"vault:path_access",path_constraint:$path,action:$action}]')"

 PAR_RESPONSE="$(curl -sS -X POST "https://${APP_DOMAIN}/oauth/par" \
     -d "client_id=${APP_ID}"                                       \
     -d "client_secret=${SECRET_VALUE}"                             \
     -d "response_type=code"                                        \
     -d "redirect_uri=http://localhost:9876/callback"               \
     -d "scope=openid profile email"                                \
     -d "audience=${AUDIENCE_ADDR}"                                 \
     -d "code_challenge=${CODE_CHALLENGE}"                          \
     -d "code_challenge_method=S256"                                \
     --data-urlencode "authorization_details=${AUTHORIZATION_DETAILS}")"

 REQUEST_URI="$(jq -er '.request_uri' <<<"${PAR_RESPONSE}" 2>/dev/null)" || {
     printf 'Auth0 PAR request failed:\n%s\n' "${PAR_RESPONSE}" >&2
     exit 1
 }

 {
     printf 'export APP_DOMAIN=%q\n' "${APP_DOMAIN}"
     printf 'export CODE_VERIFIER=%q\n' "${CODE_VERIFIER}"
     printf 'export CODE_CHALLENGE=%q\n' "${CODE_CHALLENGE}"
     printf 'export REQUEST_URI=%q\n' "${REQUEST_URI}"
 } >.rar-pkce.env
 chmod 600 .rar-pkce.env

 jq -nr \
     --arg domain "${APP_DOMAIN}" \
     --arg client_id "${APP_ID}" \
     --arg request_uri "${REQUEST_URI}" \
     '"https://\($domain)/authorize?client_id=\($client_id|@uri)&request_uri=\($request_uri|@uri)"'

Make the script executable:
```
$ chmod +x rar-authorize-url.sh
```

Use the script to get a request URI with vault.read and vault.create scope for the secret-v2/data/shared-secret/* path:

$ RAR_PATH="secret-v2/data/shared-secret" \
  RAR_ACTION="create, read"               \
  ./rar-authorize-url.sh

Open the printed authorize URL in a browser to approve the pushed request by signing in as the agent user if necessary and clicking Accept.
Auth0 redirects you to http://localhost:9876/callback?code=... but the browser shows a connection error because no server listens on that port. The code value displayed in the browser address bar is the newly minted token.
Copy the code value from the address bar and save as an environment variable:
```
$ export AUTH_CODE="c0ff33..."
```

Use cURL to request a delegation token from your Auth0 application and save it to an environment variable:

$ export DELEGATION_TOKEN="$(curl -s -X POST "https://${APP_DOMAIN}/oauth/token" \
    -d "grant_type=authorization_code"                                      \
    -d "client_id=${APP_ID}"                                                \
    -d "client_secret=${SECRET_VALUE}"                                      \
    -d "code=${AUTH_CODE}"                                                  \
    -d "redirect_uri=http://localhost:9876/callback"                        \
    -d "code_verifier=${CODE_VERIFIER}" | jq -r '.access_token')"

Use the delegation token from the token exchange to write a new secret:

$ echo '{"data": {"foo": "bar"}}' | \
  VAULT_TOKEN=${DELEGATION_TOKEN} vault write secret-v2/data/shared-secret/foo -

Key                Value
---                -----
created_time       2026-06-11T07:41:13.074Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

Try to perform vault write secret write on the same path to update the secret:

$ echo '{"data": {"foo": "bar_new"}}' | VAULT_TOKEN=${DELEGATION_TOKEN} \
  vault write secret-v2/data/shared-secret/foo -

Error writing data to secret-v2/data/shared-secret/foo: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/secret-v2/data/shared-secret/foo
Code: 403. Errors:
* 2 errors occurred:
    * RAR_NO_MATCH: No valid authorization_details claim found matching this request.
    * permission denied

Vault prohibits the update because the current RAR policy only allows create and read

Request an updated RAR token that includes update permission:

Use the script to get a new request URI that includes the update scope:

$ RAR_PATH="secret-v2/data/shared-secret"   \
  RAR_ACTION="create, read, update, delete" \
  ./rar-authorize-url.sh

Walk through the OAUth flow in the browser to get a new authentication code.
Copy the code value from the address bar and save as an environment variable:
```
$ export AUTH_CODE="c0ff33..."
```

Use cURL to request a new delegation token from your Auth0 application and save it to an environment variable:

$ export DELEGATION_TOKEN="$(curl -s -X POST "https://${APP_DOMAIN}/oauth/token" \
    -d "grant_type=authorization_code"                                      \
    -d "client_id=${APP_ID}"                                                \
    -d "client_secret=${SECRET_VALUE}"                                      \
    -d "code=${AUTH_CODE}"                                                  \
    -d "redirect_uri=http://localhost:9876/callback"                        \
    -d "code_verifier=${CODE_VERIFIER}" | jq -r '.access_token')"

Update the existing secret:

$ echo '{"data": {"foo": "bar_new"}}' | VAULT_TOKEN=${DELEGATION_TOKEN} \
  vault write secret-v2/data/shared-secret/foo -
Key                Value
---                -----
created_time       2026-06-11T08:02:39.161111Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            2

Read the new secret value with the updated token:

$ VAULT_TOKEN=${DELEGATION_TOKEN} vault read secret-v2/data/shared-secret/foo
Key         Value
---         -----
data        map[foo:bar_new]
metadata    map[created_time:2026-06-11T08:04:13.817972Z custom_metadata:<nil> deletion_time: destroyed:false version:2]

Try to delete the secret value with the updated token:

$ VAULT_TOKEN=${DELEGATION_TOKEN} vault delete secret-v2/data/shared-secret/foo

Error deleting data from secret-v2/data/shared-secret/foo: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/secret-v2/data/shared-secret/foo
Code: 403. Errors:
* 2 errors occurred:
    * RAR_NO_MATCH: No valid authorization_details claim found matching this request.
    * permission denied

Vault prohibits the delete even though the current RAR policy allows delete because the ceiling policy on the agent does not.

Note

vault kv put and vault kv get use a special type of unauthenticated preflight check path (/sys/internal/ui/mounts) internally to determine whether the requested KV path is a KV version 1 or version 2 engine.

The request handling flow does not recognize external tokens when routing to this unauthenticated endpoint and results in an error. This is a known bug, and you are encouraged to use vault read and vault write commands to work around the issue.