Local-first vs cloud-first secretsHonest tradeoffs. No winner by default.

Most teams do not choose a secrets management model. They inherit one. A developer sets up a project, exports a few variables, commits a .env.example, and the pattern is locked in before anyone asks whether it fits. Six months later the team is twelve people and the model still has not been revisited.

The question of cloud-first vs local-first is not which tool has a better UI. It is a question about your threat model: who do you trust with cleartext credentials at rest, and what happens when that trust is violated?

Getting this right early is cheap. Fixing it after a breach, an audit finding, or a $82K cloud bill from a leaked key is not.

What to know in 60 seconds

• Cloud-first secrets managers (AWS Secrets Manager, Doppler, Infisical, HashiCorp Vault-as-a-service) store your credentials on their infrastructure. You get team sync, rotation pipelines, and central revocation. You trust the provider.
• Local-first managers store credentials in an encrypted vault on your laptop or in your infrastructure. Nothing leaves your machine without your action. You trust your disk encryption.
• The worst pattern in common use: pull credentials out of a cloud manager into a downloaded .env file. You pay the trust cost of cloud and the inheritance cost of a file. You get the benefits of neither.
• For AI coding agents, the exposure surface is roughly the same regardless of which manager you use. The agent reads decrypted values at runtime. The question is where cleartext sits at rest and who holds it.
• Team size is the strongest predictor of which model fits. Solo dev: local-first wins. Fifty engineers: cloud-first or self-hosted Vault, almost always.

When cloud-first wins

Cloud-first storage makes sense when coordination is the primary cost.

A team of fifteen engineers shipping a SaaS product rotates database passwords on a schedule. Without central management, each developer needs a copy. Each copy is a synchronization problem. One engineer leaves, and you need to know which services they had access to, revoke their specific grants, and confirm the credential is no longer reachable from their machine. A cloud manager with per-user access tokens makes that a dashboard action.

The same logic applies to on-call workflows. If a production secret rotates during an incident at 2am, the on-call engineer needs the new value without waking up the person who runs the local vault. Cloud managers serve that pattern directly.

Rotation pipelines are another clear win. AWS Secrets Manager and Vault both support automatic rotation with lambda functions or plugins that update the downstream service before the old credential expires. That loop is hard to close with local-first tooling.

The trust model for cloud-first: you are trusting the provider's encryption at rest, their access controls, their audit logging, and their incident response. For well-resourced providers, that trust is reasonable. The failure mode is provider breach, account compromise, or a misconfigured IAM policy that grants access more broadly than intended. Okta's 2023 breach, which exposed customer support data through a compromised third-party tool, is a useful reference point. The provider chain extends further than the provider itself.

When local-first wins

Local-first storage makes sense when your threat model centers on supply-chain and provider exposure.

A solo developer working on a paid API product has one machine, one set of credentials, and no team synchronization problem. The only person who needs the keys is already authenticated to the machine. A cloud manager adds an account to manage, a SaaS dependency to trust, and an internet call on every credential fetch. Local-first storage removes all three.

Offline work is another common case. Embedded developers, security researchers, and developers in air-gapped environments cannot reliably reach a cloud API. A local vault encrypted with Argon2id works on a plane.

The provider breach exposure is the clearest argument. GitGuardian's 2026 State of Secrets Sprawl report shows AI-service token leaks up 81% year-over-year. A meaningful slice of that growth comes from compromised cloud manager credentials, not direct application breaches. If your credentials never leave your machine, a provider breach cannot expose them.

The trust model for local-first: you are trusting your disk encryption, your machine's physical security, and your backup process. The failure mode is a lost or stolen machine with a weak passphrase, or a compromised backup. Both are real risks; they are just under your control rather than a third party's.

Where teams pick the wrong one

Two failure patterns show up repeatedly.

The downloaded .env file. A developer connects to Doppler or AWS Secrets Manager, pulls credentials into a local .env, and commits that file to git or leaves it in their home directory indefinitely. The cloud manager provided audit logging and central revocation for as long as the credential lived in the manager. Once it lands in a file, those properties disappear. If you are downloading credentials from a cloud manager to a file, you are paying the trust cost of cloud (you trust the provider with the master copy) while also creating all the risks of local file sprawl. Rotate often enough that downloaded files expire quickly, or stop downloading.

The wrong model for the team size. A 2-person startup running AWS Secrets Manager is not wrong, but it is overhead for a problem that does not exist yet. Synchronization is not hard for two people who sit next to each other. The real cost is the IAM configuration complexity and the account dependency. Conversely, a 50-person team where each developer maintains their own local vault is a revocation nightmare. When an engineer leaves, you need to know every credential they held and confirm rotation. Local-first tooling at that scale requires a separate inventory system, which is most of the work of a cloud manager anyway.

The cloud manager that becomes a credential dispenser. Many teams use a cloud manager correctly for production secrets and then build a developer workflow where the manager's CLI fetches credentials into the local environment on session start. That pattern is convenient. It is also a shape where every developer machine holds a live cloud manager token that, if compromised, grants access to pull any credential the developer is authorized for. The manager token is itself a secret that needs management.

A local process broker avoids that specific trap. hasp holds credentials in an on-disk encrypted vault and delivers them into a child process at exec time rather than populating the shell environment. The token that would otherwise sit in ~/.zshrc or an environment variable simply does not exist in that model; the vault's Argon2id passphrase, combined with the OS keychain on subsequent unlocks, is the only authentication surface.

What most advice gets wrong

The conventional framing treats cloud-first as "enterprise" and local-first as "indie dev." That framing misses regulated industries.

HIPAA-covered entities and financial services firms under SOC 2 or PCI DSS often run a split model: cloud-first for production (central audit, rotation, revocation) and local-first per developer for development credentials (nothing patient- or cardholder-adjacent reaches a SaaS vault). The development secrets are synthetic data connections, staging endpoints, and CI tokens. The production secrets never touch a developer machine. The audit story stays clean at each layer.

The other misread is the AI coding agent question. Several engineers have asked whether local-first managers are safer for use with Claude Code, Cursor, or Codex. The answer is nuanced. Both Knostic (February 2026, Claude Code settings.local.json) and the earlier Cursor .cursor/ directory disclosure showed that coding agents persist state files that can capture environment data. Whether that environment came from a cloud manager or a local vault does not change what the agent sees at runtime. The agent reads decrypted values. The difference between cloud-first and local-first is where cleartext sits at rest and who can reach it without running code on your machine. A local manager with process-tree scoping (values injected into a specific child process, gone when it exits) reduces the agent's exposure window. A cloud manager that populates your shell environment before you launch the agent does not.

1Password's model is worth naming as a genuine hybrid. Each user maintains their own vault, synced through 1Password's cloud infrastructure. You trust 1Password for sync but each vault key is derived from the user's account password, which 1Password does not hold. A provider breach exposes encrypted blobs, not cleartext. For 2-5 person teams, this is a reasonable middle ground: you get team sharing without a full cloud manager deployment, and the trust surface is narrower than a traditional SaaS vault.

Scenario checklist

Use this to frame the decision for your team:

## Secrets model decision checklist

Team and workflow
- [ ] Solo dev or 1-2 person team: start with local-first
- [ ] 2-5 person team without on-call rotation: hybrid (1Password or similar)
- [ ] 6+ person team with on-call: cloud-first or self-hosted Vault
- [ ] 50+ engineers: cloud-first with per-user IAM grants, not per-team tokens
- [ ] Air-gapped or offline development: local-first required

Threat model
- [ ] Worried about provider breach: local-first or hybrid with zero-knowledge sync
- [ ] Worried about developer machine compromise: cloud-first with session tokens
- [ ] Regulated data (HIPAA, PCI, SOC 2): split model, local dev + central prod

AI coding agents
- [ ] Agent reads from ambient shell environment: both cloud and local have same risk
- [ ] Agent reads from process-scoped injection: local-first with scoping wins
- [ ] Confirmed no agent state files (.cursor/, .claude/, .aider/) in gitignore: fix this regardless

Hygiene
- [ ] No .env files downloaded from cloud manager older than 24 hours
- [ ] Rotation schedule exists and is tested
- [ ] Revocation for departed team members has a runbook
- [ ] Audit log covers who pulled what credential and when

What this means for your stack

The core problem with most secrets setups is not the tool. It is that the trust model was never made explicit. A team that downloads credentials from a cloud manager into a .env file has decided, without deciding, to trust the SaaS provider and to create a local file. A team that keeps secrets local but runs a coding agent against the full shell environment has decided, without deciding, to hand everything to the agent.

Making the trust model explicit forces the question of whether it fits. For development secrets on a developer machine, local-first with process-tree-scoped injection keeps cleartext out of state files, out of shell history, and out of agent logs. hasp works this way: curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the agent gets a reference instead of a key. Source-available (FCL-1.0), local-first, macOS and Linux, no account required.

Whatever tool you use, the durable position is the same: pick a model deliberately, match it to your team size and compliance context, and stop treating the downloaded .env file as a neutral step.