## TL;DR

Permission denied means the token's policies do not grant read on that path. Look up the token, compare its policies against the path's required capability, and fix the policy or the path. The token is valid; it just is not allowed there.

## Error

```text
"Vault: permission denied" on secret read
```

## Steps

1. Confirm the token works at all: `vault token lookup`. Expected: token metadata, not an auth error.
2. List the token's policies and read each one, checking for the path you need with read or list capability. Expected: you find the policy gap.
3. Check the exact path, including the kv-v2 `data` segment: reads go to `[mount]/data/[path]`, and policies must allow that full path. Expected: path mismatches surface here.
4. Fix the policy (add the path with read capability) or have the secret moved under an allowed path. Expected: policy change takes effect immediately.
5. Retry the read. Expected: the secret returns.

## When to use

- `vault kv get` or the API returns 403 permission denied.
- The token is valid (lookup succeeds).

## When not to use

- Token lookup fails (the token is expired or invalid; re-authenticate).
- The error is on write (check the policy's create/update capabilities instead).

## Tool compatibility

- Vault kv-v2; HCL policies; token, approle, and other auth methods.

## Variant phrasings

### vault 403 permission denied reading secret

Same cause.

### vault policy denies access to path

The policy needs the path added.

## Why it happens

Vault denies by default. Policies are path-based and kv-v2 inserts a `data` segment that policies must include, which is the most common mismatch.

## Edge cases

- `deny` rules in any attached policy override allows elsewhere.
- Tokens inherit the union of their policies; check all of them, not just the first.
- Namespace-aware Vault needs the policy in the right namespace.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Zn57TK-KstYyVg0A470qFA