← Problem Library
Security L6 SECURITY-1302 · 14 min

Vault KV access works in the UI and fails in automation because the policy covers metadata paths while the API client actually reads the data endpoint

Browsing secret names succeeds, yet application reads get denied because the policy was written for listing semantics instead of real payload paths.

SecurityIAMPlatform ReliabilityLevel 6Pro14 min
Scenario

Operators validate access in the UI and later the service account still gets permission denied on KV reads.

What to check first
  • Identify the primary failure signal in the IAM 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

Check KV v2 data and metadata path differences before expanding policy wildcards.

Questions worth viewing together
What should you verify first when Vault KV access works in the UI and fails in automation appears?

Community-field security problem inspired by HashiCorp Discuss cases where Vault UI access worked but KV v2 API reads were denied. Successful listing in Vault does not prove a token can read the actual secret payload.

What usually causes Vault KV access works in the UI and fails in automation in production?

Teams often blame token caching when the policy path is simply written against the wrong endpoint flavor.

What should you document after resolving Vault KV access works in the UI and fails in automation?

KV v2 path semantics split browsing and reading into different policy targets.