The common case is that you do not want to see the secret at all. You want your application to have it. That is one command:
# run a program with secrets injected as environment variables
secretsmgr run --vault dev -- ./manage.py runserver
# or write a .env file for tools that insist on one
secretsmgr env --vault dev --template config/backend.env.tmpl > .env
The first form never writes the values to disk at all. They go straight into the child process's environment. Prefer it. The second exists because plenty of frameworks demand a file; the tool refuses to write one to a path that is not covered by .gitignore unless you insist.
When you genuinely need to look at a value:
secretsmgr get dev/database/password
secretsmgr list dev # names only, no values
secretsmgr describe dev/database/password # versions, who wrote them, when
Behind the scenes, each of these unlocks your private key using your key provider (which may ask for a passphrase or a touch), fetches the encrypted file, and peels the layers from how the layers stack. If you are not a member of the vault, it fails. No server said no; there is simply no copy of the vault key that your private key can open.