Stop putting secrets in Windows env vars: broker identity-bound, short-lived tokens to your OpenCode agents
Asked (summary):
We use OpenCode with skills and plugins that call private app APIs, and user credentials sit in plain Windows user environment variables — globally readable, no authorization. What is the modern 2026 way to centralize and protect passwords and secrets for agent usage? Give best practices and ideas.
This report draws on 70 sources across 20 hosts — Microsoft, OpenCode, OWASP, IETF, HashiCorp, 1Password, Bitwarden documentation and security analyses — grouped into four areas: Windows/Microsoft options (15 rows), central vaults and runtime delivery (20), OAuth and token security (15), and OpenCode-specific behaviour (20). The modern target is not an encrypted environment variable; it is an identity-first credential broker that keeps raw secrets away from the agent entirely.
Target architecture: agent → broker → vault and APIs
preferred identity pathsbroker-mediated API callsfallback: process-lifetime secret (not a security boundary)
Hover or tap a path for what it is and when to use it. The agent tier holds no raw secrets; the broker enforces user identity, tool identity, scope, consent and audit.
What the architecture cannot say alone
A temporary child-process environment variable only reduces persistence — OWASP notes env vars are generally readable by processes and can leak into logs and dumps, so they are a fallback, not a boundary. cheatsheetseries.owasp.org
RFC 9700 (OAuth 2.0 Security BCP, Jan 2025) recommends asymmetric client authentication (mTLS or private-key JWT) over symmetric secrets, and calls the password grant insecure — never give a plugin a user's reusable password. self-issued.info
OpenCode already supports the better path: remote MCP servers authenticate with OAuth automatically and tokens are stored in a dedicated credentials file, not in your config. opencode.ai
But by default all OpenCode tools are enabled and run without permission — set explicit allow/ask/deny rules, including wildcards per MCP server, before wiring in anything credentialed. opencode.ai
PowerShell SecretManagement/SecretStore beats persistent env vars locally, but the modules are feature-complete and archived — do not make them the strategic enterprise platform. learn.microsoft.com
Best-practice checklist
Inventory every secret: owner, consumer, privilege, environment, expiry, rotation.
Prefer identity and delegated tokens over passwords and API keys.
Separate identities per user, tool, app and environment; never share a broad production credential.
Least privilege: scope, audience, allowed operations and network destination.
Short TTL, just-in-time issuance, automated rotation, revocation, rapid offboarding.
Central audit correlating user → agent/session → tool → downstream API call; never log values.
The agent never sees raw credentials; use a broker, proxy or signing service where possible.
Egress allowlists, sandboxing, separate OS account/process boundaries, explicit approval for sensitive tools.
Secret scanning and redaction across repos, config, logs, dumps, prompts and exported sessions; canary credentials for leak tests.
Define break-glass, vault outage, laptop loss and incident response; rotate anything that ever lived in a persistent environment variable.
Implementation roadmap
Now
Remove credentials from persistent Windows user/system env vars; rotate every migrated value.
Put team secrets in a central vault; a PowerShell/CLI launcher injects values only into the OpenCode subprocess for legacy plugins.
Configure OpenCode permission allow/ask/deny for every tool and MCP wildcard; use --pure for sensitive sessions.
Keep secrets out of opencode.json, AGENTS.md, SKILL.md, prompts, transcripts and project .env files.
Next quarter
Move private apps to Entra ID/OIDC; Authorization Code + PKCE for users, device flow only where appropriate.
Refresh tokens only in OS-protected storage, rotated; short access-token TTLs, narrow scopes and audiences.
On-behalf-of / RFC 8693 token exchange where a tool must act with the user's downstream permissions.
Allowlist, review, and pin skills and plugins by version/hash; treat them as executable code.
Strategic target
A credential broker or OAuth-enabled remote MCP gateway between OpenCode and private APIs; the agent sends operations plus an opaque handle, the broker returns business data, never credentials.
Workload identity / managed identity or token federation for unattended automation.
Per-use approval or Windows Hello confirmation for high-risk actions.
Central audit from user to downstream API call, with canary-credential leak tests.
Decision matrix
Option
Best for
Key strength
Key limitation
Entra ID + Azure Key Vault + RBAC
Microsoft-first central governance
Managed/workload identity, DefaultAzureCredential works locally and hosted; unavoidable passwords live in Key Vault
Managed identity grants service-level access — use on-behalf-of when user-level permissions matter (learn.microsoft.com)
HashiCorp Vault
Multi-cloud / on-prem, dynamic secrets
Policy, leases, dynamic just-in-time credentials, JWT auth with Entra OBO tokens, audit to SIEM
Adds a Vault availability dependency; static roles with rotation can blur attribution (developer.hashicorp.com)
1Password Business developer tools
Interactive, user-owned tokens; human-in-the-loop
Biometric approval; Environments MCP server never returns secret values to the agent
Locally mounted .env Environments support only Mac and Linux in the rows’ 2026 docs (developer.1password.com)
Bitwarden Secrets Manager
Centralized secrets on a budget
CLI injection (bws run) into pipelines and processes
The machine access token is itself a bootstrap secret and must be protected (bitwarden.com)
Materially better than persistent env vars; DPAPI-encrypted, session unlock
Not team governance, no sandbox against same-user code; modules archived (learn.microsoft.com)
All 70 sources
Area
Option / guidance
Key limitation or caveat
Source
Method: 70 documentation and analysis rows gathered across four shaped result sets — 15 Microsoft/Windows, 20 central-vault/runtime-delivery, 15 OAuth/token-security, 20 OpenCode-specific — from 70 distinct URLs on 20 hosts; no URL backs more than one row. Each table row shows the option described and its stated limitation, shortened for space; full protection, bootstrap-auth and lifecycle details were cut. Primary vendor and standards documentation (Microsoft, OpenCode, IETF, OWASP, HashiCorp, 1Password) is preferred over secondary commentary. Snapshot of 2026 documentation; verify current vendor docs before rollout.