Not always. Content you encrypt with Ansible Vault stays encrypted after a run, with one exception: if you pass an encrypted file as the src of the copy, template, unarchive, script or assemble modules, the file arrives decrypted on the target host when the right password is supplied.
Why this is by design
The documentation calls this intended and useful. You may encrypt a configuration file or template to avoid sharing its details in your repository. Servers then need the plain version so local users and processes can read it. Vault protects the file in source control and on the control node, not on the target.
What Vault protects
| Location | Protected by Vault |
|---|---|
| In your Git repository | Yes, if encrypted |
| In a log of the file contents | No, unless output is suppressed |
| On the target after copy or template | No, it is plain |
| In transit | Governed by the connection method, such as SSH |
Vault is encryption at rest for your automation source. It is not a secret store for running systems.
Risks after decryption
- The file's permissions on the target decide who can read it. Set
modeandownerexplicitly. - Backups of the target may capture it in plain form.
- A later task that reads the file into a registered variable could print it.
- Debug output can expose the content, so protect tasks with
no_log: trueas appropriate.
Safer handling
- Set tight
modeandowneron every task that places a secret file. - Place secrets in a directory with restricted access.
- Keep short lived secrets short lived: rotate them after deployment where you can.
- Consider whether the application can fetch its secret from a manager at start up, rather than from a file you push.
- Add
no_log: trueto the task, since the file's contents may appear in a diff.
Format notes
Vault files are UTF-8 text with a header line such as $ANSIBLE_VAULT;1.1;AES256 followed by the encrypted body. The header can include a vault ID label. Anyone can see that a file is a vault file, so do not rely on hiding the fact that it exists.
Quick check
Are vaulted variables decrypted on the target too?
Variables are decrypted for use during the run. What lands on disk depends on what each task writes.
Does Vault help with secrets at runtime?
It protects stored automation content. It is not a runtime secret manager.
Is the decrypted file removed after the run?
Not unless your playbook removes it.
Safeguard offers SBOM and dependency scanning and policy gates that can block a pull request on findings, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
