Storing secrets for unattended scripts: systemd credentials, DPAPI, macOS keychain — and what not to do

Goal

Give an unattended script or service the secret it needs at runtime without exposing it in the environment of other processes, in a process listing, or in a world-readable file.

Prerequisites

systemd 247+ for LoadCredential=, 250+ for systemd-creds and LoadCredentialEncrypted= (encryption uses a TPM2-derived key, the host key /var/lib/systemd/credential.secret, or both, so no TPM is strictly required); PowerShell 5.1+ for Export-Clixml, or the Microsoft.PowerShell.SecretManagement module for a fuller secret-store abstraction; macOS with the security command-line tool (built in).

Steps

1. Linux/systemd: as root, systemd-creds encrypt --name=mysecret plaintext.txt /path/mysecret.cred, then delete plaintext.txt and reference it in [Service] with LoadCredentialEncrypted=mysecret:/path/mysecret.cred. The embedded name must match the credential ID; without --name= it is taken from the output file name. The service reads the decrypted value at $CREDENTIALS_DIRECTORY/mysecret, a read-only copy accessible only to the service (it works with DynamicUser=), rather than an environment variable inherited by every child process.
2. Windows: Get-Credential | Export-Clixml -Path secret.xml serializes a credential object; Microsoft's documentation notes this relies on the Windows Data Protection API (DPAPI), so the resulting file can only be decrypted by the same user account on the same machine that created it — copying it to another host or user makes it unusable, so create it while running as the account that will read it. This holds only on Windows: PowerShell on Linux/macOS writes the password merely encoded, not encrypted. Import-Clixml -Path secret.xml reads it back inside the script. For named secrets, Microsoft.PowerShell.SecretManagement needs a vault extension such as Microsoft.PowerShell.SecretStore, which asks for a password by default unless its authentication is reconfigured.
3. macOS: store a secret once with security add-generic-password -a "myservice" -s "myservice-token" -T /usr/bin/security -w; with -w last and no value, it prompts, keeping the secret out of ps and shell history. A script retrieves it with security find-generic-password -a "myservice" -s "myservice-token" -w, which prints only the value. The keychain must be unlocked, which a user's login keychain often is not in SSH sessions or for LaunchDaemons, and a tool missing from the item's access list (-T) triggers a GUI prompt.
4. In all three cases, restrict the file or credential store to the service's own account (Linux: rely on LoadCredential='s per-service directory rather than a shared path; a manual file should still be chmod 0600).

Expected result

The secret is readable by the intended service account at runtime and by no other account; ps//proc/<pid>/environ-style inspection of the running process shows no plaintext secret, and killing and restarting the process does not require re-entering it manually.

Limits and test basis

None of these mechanisms stop a process running with the same privileges as the service itself, or a user able to sudo/Run as Administrator, from reading the plaintext once decrypted. What they do avoid: putting a secret in an environment variable (visible to every child process and often logged), a command-line argument (visible in ps/Task Manager and shell history), or a plain file with default permissions.