← Problem Library
Security L6 SECURITY-1322 · 14 min

A Vault policy looks permissive and KV reads still fail because the team granted metadata paths while the application uses data paths on a versioned KV v2 mount

The token can list and inspect metadata, yet the real secret read fails because the path family is wrong for KV v2 access.

SecurityPlatform ReliabilityLevel 6Pro14 min
Scenario

A service token is updated and later can enumerate secrets but cannot actually read the intended values from Vault.

What to check first
  • Identify the primary failure signal in the The Policy Opened the Secret Catalog but Not the Secret Itself scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Validate KV v2 path semantics before broadening token capabilities across the mount.

Questions worth viewing together
What should you verify first when A Vault policy looks permissive and KV reads still fail appears?

Community-field security problem inspired by HashiCorp Discuss threads where KV v2 policies allowed metadata paths but blocked actual data reads. Vault path issues often look like auth failures even when the token is otherwise valid.

What usually causes A Vault policy looks permissive and KV reads still fail in production?

Teams often blame expired tokens when the policy simply points at metadata instead of data.

What should you document after resolving A Vault policy looks permissive and KV reads still fail?

KV v2 pathing doubles the room for mistakes because metadata and data are separate APIs.