Skip to main content
SecRefs separates failures into two categories, because they have different causes and different fixes.

​
”Cannot authenticate to provider”

Your references are fine. Your credentials are missing or expired. This is reported once for the whole provider, with the list of references that were blocked — not once per reference, which would read as three broken secrets. Common causes:
SSO sessions last 8–12 hours. Run:
A long-running process recovers on its own once you do — SecRefs does not cache failures, so the next resolution succeeds without a restart.
Could not load credentials from any providers means the whole AWS credential chain came up empty. Set AWS_PROFILE, export static keys, or attach an instance role.
Set BWS_ACCESS_TOKEN for Bitwarden, or VAULT_ADDR and VAULT_TOKEN for Vault. Both are read from the environment; SecRefs never stores them.

​
”Failed to resolve N secret reference(s)”

Here the reference really is the problem. Each one is listed individually because each may be wrong in a different way.
AccessDenied is deliberately not treated as an authentication failure. Your credentials worked — a policy said no to one secret. Sending you to re-login would waste your time.

​
Diagnosing without resolving

check validates every reference and never returns a plaintext value:
It reports provider health separately from reference validity, so you can tell “my credentials are broken” from “these two references are wrong”.