A secret is only safe if it’s stored and handled correctly, not because you called it a secret. Paste an API key into a chat, drop it in a public repository, or send it in a screenshot, and the access it carries is now loose.
Think of a secret like a company keycard. It’s small enough to sit in your wallet, but if someone else gets it, they can walk into places they shouldn’t. The danger is the access attached to it, not the plastic.
How it shows up
In agent work, secrets show up fast. Claude Code or Codex may need to call QuickBooks, Slack, Gmail, or GitHub, and each needs access. A secret manager like Infisical or 1Password keeps those values out of normal project files. An environment variable is one common way a program receives a secret at runtime without hardcoding it, which keeps it out of the repository. Encryption protects secrets while they’re stored or sent, but it doesn’t remove responsibility: an agent allowed to use a secret can act with everything that secret grants, so a read-only key is very different from an admin key that can delete records.
Why you care
There’s real supply chain risk: a random script or external skill can ask for secrets in ways that look harmless. If you wouldn’t hand a stranger your keycard, don’t hand an unreviewed tool your API keys. And if a key leaks, you rotate it, the digital version of changing the lock. Once a secret is out, the question is what doors that value could open, not whether the file looked harmless.