Why Vault Can Say Invalid Token and Permission Denied at the Same Time

This was one of those errors that looks contradictory until you think about how the script is actually authenticating.

The pattern was:

a script tries to issue or configure something in Vault
Vault responds with 403
the error mentions both invalid token and permission denied
a manual login still seems to work

The important point is that those two checks do not have to be using the same token.

What usually happened

The real problem was often a stale operational token stored on disk.

Manual testing might use a fresh root token or a fresh admin session. The automation path might silently pick up an older token file from a previous init, a different environment, or a token that no longer maps to the current Vault state.

That creates a confusing split:

your manual session works
the script still fails

Once you assume those are two different identities, the error starts to make sense.

Why the message looks messy

Vault is effectively telling you two things:

it cannot use the token in the way the script expects
even if the request shape is correct, the token context does not authorize the action

That is why this error class should be debugged as an identity problem first, not as a PKI problem.

The operational lesson

Any automation that reuses a stored admin token should validate it immediately before doing real work.

If the script just says "token file exists, so I will use it," you are one stale file away from losing time on a fake policy hunt.

The safer pattern is:

verify reachability
verify the exact token the script will use
only then run the privileged Vault operation

What I changed mentally after this

I stopped treating admin-token files as passive configuration. They are active state.

If that state is stale, everything after it becomes misleading. So the right fix is usually not "tune the PKI role." It is "prove the automation is holding a valid identity for this Vault right now."