Threat Model

What vars protects against

Accidental commits — the .vars file only contains encrypted blobs for secrets. You can commit it safely.
Log leaks — Redacted<T> keeps secrets out of structured logs, error reporters, and console.log dumps.
Unauthorized file access — if someone gets your .vars file (leaked backup, overly-permissive S3 bucket), they get ciphertext. Useless without the PIN or VARS_KEY.
Lateral access within a team — owner PINs mean the frontend team can't decrypt backend secrets, even with access to the same repo and key file. Different keys, not just different permissions.
Automated tools and AI agents — a tool with file-system access can read the file but can't decrypt it. The PIN prompt blocks it.

A compromised machine where the attacker also knows the PIN. If they can sit at your keyboard and type your PIN, they can decrypt everything. vars doesn't solve physical security.
Memory on a live system. Once values are decrypted in memory for your running app, an attacker with OS-level access can read them. This is true of every secret manager, not just vars.
PIN brute-forcing with offline access. If an attacker copies your .varskey file, they can attempt to guess the PIN offline. Argon2id makes it slow and expensive, but a weak PIN is still a weak PIN.
Supply chain attacks. vars can't help if a dependency is exfiltrating process.env values after injection. Audit your dependencies.
VARS_KEY exposure. If your CI secrets are compromised and VARS_KEY leaks, rotate immediately with vars key rotate. On a serverless bundle, an attacker who obtains both VARS_KEY and the deployed artifact can decrypt every secret in that artifact — same blast radius as pushing each secret individually into the platform dashboard, but concentrated on one key. Treat VARS_KEY with the same care you'd give a root deploy token.