Kill the Long‑Lived Token: A CTO Playbook for Secrets in the Age of Agents

Your secrets are one package install away from theft. After reports that a popular password-manager CLI was targeted in a broader supply-chain campaign, and with AI tools now requesting direct connections to your SaaS, trusting developer machines and agent sandboxes with long-lived tokens has become indefensible. This isn’t FUD; it’s an architecture gap. The fix is not another vault; it’s changing how credentials are issued, scoped, and used — everywhere.

The threat changed. Your secret model probably didn’t.

In the last year, three trends converged:

• Supply-chain attacks moved up-stack — from compromised registries and typosquats to trojanized CLIs and extensions. Checkmarx tracked a campaign attempting to compromise developer tooling, including a Bitwarden CLI package, via package managers. Whether you used that exact package or not, the takeaway is simple: your friendly CLI is now part of the attack surface.
• AI agents are asking for real keys — OpenAI and Anthropic are shipping agent connectors to personal and enterprise apps. Google launched an official skills repository for agents. The convenience is real — so is scope sprawl. Without a broker, you are handing OAuth refresh tokens or API keys to code you didn’t write running in contexts you don’t fully control.
• Remote and nearshore teams increased the blast radius — every new laptop, home network, and region multiplies the places a token can be cached, captured, or exfiltrated. If you’re augmenting with senior engineers in Brazil (good call), you still need a uniform, enforceable control plane for secrets.

If your current model is: "password manager + .env + GitHub PAT + cloud access key + DB password + SSH key," then you’re depending on endpoint hygiene and developer discipline. That’s not a strategy; that’s a wish.

Principle, not product: Brokered, ephemeral, auditable

A modern secrets program has three properties:

• Brokered: Workflows get credentials from a policy enforcement point (PEP), not stored on endpoints. Identities reach resources through a broker that can enforce device posture, user group, time-of-day, environment, and scope.
• Ephemeral: Credentials expire fast. Cloud roles via STS typically last 15–60 minutes. SSH certs 1–8 hours. DB access via IAM or short-lived certs. OAuth tokens with narrow scopes and short TTLs. No long-lived access keys or PATs.
• Auditable: Every grant is logged and attributable to a user/workload identity. You can answer “who accessed prod DB on Friday at 14:03 UTC?” without scraping terminal history.

Vaults still matter — but a vault is a store. The risk is in use. The broker is the choke point where you can apply policy, emit logs, and revoke access.

A CTO’s decision framework: Three planes to fix, in order

1) Identity plane: establish who/what is asking

• Human identity: Enforce SSO with phishing-resistant MFA (WebAuthn/passkeys). Eliminate legacy MFA wherever possible. Limit SSO session duration to a working day (8–12 hours) and require reauth for privilege escalation.
• Workload identity: Stop baking secrets into containers and VMs. Use SPIFFE/SPIRE or cloud-native workload identity federation (GCP WIF, AWS STS, Azure workload identities). Your CI/CD should exchange an OIDC token for a role; no static cloud keys in CI secrets.
• Device posture: Tie access to verified, managed devices (MDM/EDR attestation); if the laptop is not encrypted, up to date, and monitored, it doesn’t get production access — full stop.

2) Issuance plane: remove static credentials

• Cloud roles: Use OIDC to obtain short-lived role credentials. Default to 15–60 minute lifetimes. Ban IAM users with access keys. Enforce role chaining with external IDs for vendors.
• Git operations: Replace classic PATs with SSO-backed fine-grained tokens or SSH certs with 8-hour TTL. Enforce organization SSO on GitHub or GitLab; disable password-based Git over HTTPS.
• Databases: Use IAM auth (AWS RDS, Cloud SQL) or short-lived x509 certs from a broker (e.g., Teleport DB access, HashiCorp Boundary, or Vault PKI). Rotate root/passwords to break-glass only.
• SSH: Move from static keys to signed SSH certificates (CA issues 4–8 hour certs). Keys never live on servers; revocation is instant by stopping the CA.
• OAuth to SaaS: When connecting agents or CLIs to SaaS, use least-privilege scopes and short-lived access tokens. Prefer out-of-band brokers that can mint and refresh on behalf of the agent so the agent never holds a long-lived refresh token.

3) Egress plane: control how secrets are used

• Credential brokers: Route DB/SSH/Kubernetes access through a broker that terminates at the resource and mints ephemeral credentials on demand (Teleport, Boundary, strongDM). For AI agents, use a dedicated secrets proxy (the HN project Agent Vault is one open-source example) so the agent never touches raw credentials.
• Network policy: Prod egress should be default-deny with explicit allowlists to SaaS endpoints you rely on. If an agent tries to exfiltrate a token to a paste site, it should fail fast and loud.
• Logging and canaries: Log every grant and session. Plant canary tokens in places they should never be used; alert on first touch.

What this looks like in practice

Here’s a minimal, sane pattern we’ve implemented for US startups scaling engineering with nearshore teams in Brazil:

• Developers authenticate with SSO + WebAuthn. Their device posture is verified (Kandji/Intune + EDR). From São Paulo or Austin, posture gates are the same.
• To access AWS, the dev runs a signed, pinned CLI that exchanges SSO for a 45-minute AWS role via STS. No access keys on disk.
• To query prod Postgres for a 15-minute incident, the dev requests access in the broker. Policy approves based on on-call role and device posture. The broker opens a TCP tunnel and issues a 15-minute DB cert. Query log is mapped to the identity.
• To push to GitHub, the dev uses SSH certs with 8-hour TTL issued on login. The org enforces SSO and disallows classic PATs.
• AI coding agents run in ephemeral containers. When they need to call internal APIs or JIRA, they request a capability from the agent secrets proxy. The proxy mints a narrow, short-lived token with an allowlist of endpoints and verbs, and logs every use.

No raw credentials are stored on laptops or in agent sandboxes. If a malicious CLI tries to read ~/.aws/credentials, it finds nothing. If it tries to exfiltrate a token, the brokered token is expired or constrained to a single action and IP range.

Implementation: a 90-day plan

Days 0–30: Kill obvious long-lived tokens

• Inventory: Enumerate secrets used by humans, CI, and services. Focus on GitHub/GitLab PATs, cloud access keys, DB passwords, and SSH keys.
• Immediate policy: Require SSO + WebAuthn. Enforce PAT expiration and scope minimization. Disable classic PATs for org access. Turn off password-based Git over HTTPS.
• Start with cloud: Move CI to OIDC-based role assumption (GitHub Actions OIDC to AWS/GCP/Azure). Rotate and delete long-lived cloud keys.
• Protect endpoints: Block developer shell history for secrets and enforce OS keychain storage for any short-term tokens. Turn on pre-commit secret scanning and org-level scanning in VCS.

Days 31–60: Introduce brokers and certs

• Pick a broker: Choose Teleport, Boundary, strongDM, or a comparable tool your team can run. Stand up HA in your cloud.
• SSH and DB first: Migrate SSH to CA-signed certs (8-hour TTL). Replace DB passwords with broker-issued short-lived certs or IAM access. Lock away DB superuser creds behind break-glass.
• Git hardening: Enable organization SSO, fine-grained tokens, and required SSH signing. Enforce 7-day max TTL for Git tokens if your VCS allows; otherwise use SSH certs.

Days 61–90: Bring agents and SaaS into scope

• Agent secrets proxy: Introduce a minimal proxy service for AI agents. It should mint narrow, time-limited capability tokens per tool (e.g., JIRA issue create only) and keep refresh tokens server-side.
• Network and canaries: Tighten prod egress allowlists. Plant canary tokens in likely exfil paths (dotfiles, build logs) and alert on first use.
• Drills: Run a purple-team exercise: drop a fake trojanized CLI binary into a sandbox and measure time to detection, blast radius, and revocation speed.

Tooling notes and concrete numbers

• STS and token lifetimes: AWS STS role sessions are commonly 15–60 minutes; set to 45 minutes for balance. GCP WIF issues 1-hour tokens. SSH certs of 4–8 hours fit a working block. DB certs at 15 minutes nudge good behavior.
• Brokers: Teleport’s DB/SSH/K8s access centralizes policy and gives you per-session recordings. Boundary is solid if you’re already on HashiCorp. If you must roll your own for agents, copy their principles: ephemeral creds, policy at the edge, full audit logs.
• Supply chain hardening: Pin and verify CLIs with Sigstore/cosign signatures. Lock npm to ignore-scripts=true for sensitive environments. Use pipx or isolated envs for Python tooling. Maintain an internal, signed tap for Homebrew formulas.

What you’ll trade off

• Friction vs. risk: Short TTLs cause occasional reauth pain. Accept it. Your alternative is a cached 90-day token living in a shell history on a stolen laptop.
• Legacy tool gaps: Some third-party tools don’t support OIDC or certs. Use the broker to wrap them, or quarantine them to non-prod until they do.
• Centralization risk: A broker is a critical path. Run it HA across zones, test failover, and have a break-glass plan that doesn’t revert to long-lived secrets.

Cost and ROI, realistically

• Engineering effort: Expect 2–3 senior engineers for 8–10 weeks to land the core changes in a 50–150 engineer org. That includes cloud, VCS, DB, SSH, and initial agent proxying.
• Licensing: Teleport/strongDM/Broker tools typically run $20–$40 per user per month. Boundary and Vault are open-source but you’ll pay in ops. You’ll save that in a single avoided incident or in audit prep hours.
• Blast radius reduction: Moving from 90-day PATs and indefinite DB passwords to 45-minute role creds and 15-minute DB certs makes stolen tokens expire in place. Most exfil attempts become noisy and useless.

Nearshore teams: same control plane, different ergonomics

Brazilian engineers working 6–8 hours overlap with US teams should have identical posture gates and brokered paths. The only tweaks we recommend:

• Latency-aware brokers: Place a broker edge near São Paulo (AWS sa-east-1, GCP southamerica-east1) to keep DB tunnels snappy. Terminate to resources where they live.
• Data jurisdiction: If you mirror data to Brazil for latency, ensure your broker enforces resource-level policies so PII stays where it must. Keep audit logs centralized in the US for compliance.
• Connectivity hygiene: Require split DNS and VPN with device posture for sensitive resources; don’t rely on public internet for prod DB access even with certs.

Don’t wait for the next headline

The Bitwarden CLI news cycle will fade. The agent integrations will get flashier. Another CLI will get popped. Your job is to make those events uninteresting for your org. You do that by eliminating long-lived secrets, brokering access at the edge, and shrinking every token’s authority and lifetime until it’s barely useful to an attacker.

You don’t need a 12-month zero-trust program to get there. In 90 days, with focused effort and the right brokers, you can make the next compromised package or over-scoped agent connector a non-event.

Key Takeaways

• Stop storing powerful, long-lived secrets on developer machines and in agent sandboxes; the risk profile has changed.
• Adopt a brokered, ephemeral, auditable model: short-lived creds via STS/OIDC, SSH certs, IAM DB auth, and a policy-enforcing access broker.
• Control egress and scope for AI agents with a secrets proxy; don’t hand agents refresh tokens.
• Implement in 90 days: kill long-lived tokens, stand up brokers, move SSH/DB to certs, and bring agents and SaaS into scope.
• Expect minor friction and tool gaps; the blast-radius reduction and auditability are worth it.
• Nearshore teams in Brazil fit naturally into this model; place broker edges regionally and keep policy identical.