# Postman's 3 Layers of API Secret Protection Explained

Most API platforms handle secret security as an afterthought. A vault here, an environment variable there, and a reminder in the docs to "never hardcode credentials." Then developers do it anyway, a secret gets exposed, and the security team finds out weeks later when something breaks, or worse, when an attacker finds it first. That's not good enough. And patching one hole at a time isn't a security posture. According to the Verizon 2025 Data Breach Investigations Report, credential abuse causes 22% of all breaches. The root cause is almost always the same: developers sharing plain-text credentials in Environments and Collections, in Git commits, in cloud-synced files. The fix isn't to tell developers to be more careful. It's to build a system where being careless doesn't create risk in the first place. That's what Postman's secret security model is designed to do. Not one layer of protection, but three.

## The problem with single-layer security

 Most teams think about secrets protection at one moment in time: before they deploy. They scan repos, rotate keys periodically, and trust that developers are following the rules. But secrets don't only escape at deployment. They escape at save. They escape in sync. They escape at runtime when a value gets logged or cached somewhere it shouldn't be. A single detection point means every other moment is a blind spot. Postman's approach is different: it scans local data before it's saved or synced to the cloud, catches anything that already slipped through, and ensures the value is never exposed when it's actually used. ## Layer 1: Stop it before it's ever saved

 The first layer is [Local Secret Protection (LSP)](https://learning.postman.com/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works), and it runs before anything touches the cloud. When you save data in Postman, a scan runs at that exact moment, before the data reaches the cloud, the local file system, or a connected Git repository. If a secret is detected, it doesn't get saved. Instead, it's automatically moved to a vault and replaced with a reference. The original value never lands anywhere it shouldn't. This matters because most security tools sit downstream of the problem. They catch secrets after they've already been written somewhere: a commit, a sync, a log file. By then, the damage is done, and remediation becomes a scramble. Scanning at the point of save means the window of exposure is measured in milliseconds, not weeks. The automatic move to the vault also makes it easy for developers to do the right thing. You no longer have to hope they remember. Postman treats secret protection as baseline security, not a premium feature, which is why Local Secret Protection is available on every plan. ## Layer 2: Find what already slipped through

 Even with prevention in place, secrets that existed before can still be lurking in synced Workspaces. That's what the second layer addresses: [Cloud Secret Detection](https://learning.postman.com/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). When data syncs to the cloud, Postman scans it for exposed secrets. In public Workspaces, detected secrets are deleted immediately. No manual review required, no waiting for a security ticket to get triaged. For private Workspaces, Enterprise admins get full reporting visibility: what was found, where it was, and when. That means your security team can act on exposure rather than just prevent future instances of it. The distinction matters. Prevention is not the same as remediation. Most teams only have one without the other. ## Layer 3: Ensure the value is never exposed at runtime

 The third layer is where most platforms stop thinking about secrets entirely: runtime. In Postman, variables hold references to vault entries, not the secret values themselves. When the default policy for a Workspace is set to shared vault, variable references replace the secret and the value moves to a shared vault where teammates with access can use it. This is supported across Postman Monitors, Flows, and scheduled runs, along with the desktop app and the Postman CLI. It's also backward compatible with existing vault references, so you don't need to rebuild anything to benefit from it. The implication is significant: even if someone gains access to your environment file or Collection, they get references, not secrets. The value only exists at the moment it's needed, in the place it's needed, and nowhere else. ## Choosing where your secrets live

 Protection layers are only as strong as the vault they're protecting. Postman supports three storage models, so teams can match their approach to their risk tolerance and existing infrastructure. [**Postman Local Vault**](https://learning.postman.com/latest-v-12/docs/use/postman-vault/postman-vault-secrets) keeps secrets on-device. Values are never synced to Postman's cloud. If you need absolute certainty that sensitive values never leave your machine, this is it. [**Postman Shared Vault**](https://learning.postman.com/docs/use/postman-vault/postman-vault-key) is designed for team collaboration. One vault per Workspace, with access inherited from Workspace permissions. Team members can work with secrets together. Secrets in a shared vault are end-to-end encrypted, with encryption keys managed by Postman. You can also use them with cloud-based features such as Monitors and scheduled runs. Enterprise admins can turn the Shared Vault on or off by Workspace or across the whole team. [**Postman Vault Integrations**](https://learning.postman.com/docs/use/postman-vault/postman-vault-integrations) let you keep your existing infrastructure as the source of truth. Postman resolves secrets directly from AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or 1Password at request time. No values are stored in Postman at all. Your vault stays your vault. ## Going further: bring your own key

 For organizations with strict compliance requirements, BYOK (Bring Your Own Key) adds one more layer: your own encryption keys on top of any vault option. Enterprise customers supply and manage their own keys. Every encryption event is logged for compliance, and you retain full ownership of encrypted data in Postman Cloud. This is critical for teams operating under SOC 2 or HIPAA. ## Three layers, one posture

 The reason credential abuse drives so many breaches isn't that developers are reckless. It's that most tools only protect against one kind of mistake, at one point in time. That leaves the other moments (the save, the sync, the runtime execution) unguarded. Secrets are saved to a vault, stored as references, and resolved only at execution. That's defense in depth: three different types of control, preventive at save, detective in the cloud, and protective at runtime. It's one security posture, designed so that no matter where in the workflow a secret could be exposed, there's already something in place to stop it. No other API platform covers all three. Most don't even try. ## Resources

- [How Postman Secret Scanner works](https://learning.postman.com/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works)
- [Postman Vault: storing secrets locally](https://learning.postman.com/docs/sending-requests/postman-vault/postman-vault-secrets/)
- [Postman Vault integrations with external secret managers](https://learning.postman.com/docs/sending-requests/postman-vault/postman-vault-integrations/)
- [Verizon 2025 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/)
- [Postman Enterprise security and compliance](https://www.postman.com/trust/)
- [OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0x11-t10/)