Secretless approaches for AI coding agentsSix patterns. Real tradeoffs. One honest matrix.

"Secretless" sounds like the problem disappears. It does not. The pattern takes the long-lived static credential out of the application config and replaces it with something shorter-lived: a federated identity assertion, a dynamically leased secret, or a broker-mediated injection. The secret still exists somewhere. The question is where, for how long, and who can read it.

For traditional server workloads, the established patterns work well. For AI coding agents running locally on developer machines, the picture is messier. Agents inherit ambient environment variables, persist state to disk inside project directories, and run across long sessions that span many tool calls. Knostic's February 2026 disclosure about Claude Code's settings.local.json capturing environment variables and shipping them in npm packages illustrated what happens when a secretless posture at the pipeline layer coexists with ambient long-lived credentials on the developer's machine. The CI runs clean. The laptop leaks.

Six patterns follow, each with a real use case and a real gap when applied to local coding agent contexts.

What to know in 60 seconds

• "Secretless" means different things depending on who says it. CyberArk's Secretless Broker is a sidecar that intercepts connections. GitHub Actions OIDC is a federation mechanism that issues short-lived tokens. They are solving different problems under the same umbrella term.
• No pattern eliminates secrets entirely. They eliminate secrets from one location by moving them to another (a federated identity provider, a vault, a sidecar's connection pool). The security improvement is real; the semantics of "secretless" are not.
• OIDC federation is excellent for cloud CI and zero-trust server deployments. It requires a trusted identity provider and does not apply to a developer running Claude Code locally.
• Vault dynamic secrets and sidecar brokers are powerful for server workloads. They add operational complexity most small dev teams cannot absorb.
• Process-tree-scoped injection brokers are the pattern closest to "secretless" for local coding agent use. The agent never sees the credential value directly.
• GitGuardian's State of Secrets Sprawl 2026 puts AI-service token leaks at 81% year-over-year growth. The mechanism is not sophisticated: ambient credentials in the developer environment, agents that read and persist that environment.

What "secretless" actually means

The term entered common usage through CyberArk's open-source Secretless Broker project, which took a specific technical stance: applications should not have credentials at all, not even at startup. Instead, a sidecar proxy intercepts the application's outbound connection attempts and injects credentials at the connection level. The application's code contains no secret. It calls localhost:5432 and the sidecar authenticates to the real Postgres with a credential the application never touched.

AWS, GitHub, and most SaaS security vendors then borrowed the term to describe any pattern that moves secrets out of application config, even if the application still receives a short-lived token it holds for the duration of a session. The latter is better than long-lived static keys but is not "secretless" in CyberArk's original sense.

The honest taxonomy has three tiers:

Credential-free. The application code never handles any credential. Connection-intercepting sidecars like CyberArk Secretless Broker achieve this. The app calls a local proxy; the proxy authenticates.

Short-lived credential. The application receives a credential, but it expires quickly (minutes to hours). OIDC federation, AWS IAM Identity Center SSO tokens, and Vault dynamic secrets all fall here. Better than long-lived static keys; not fully secretless.

Brokered injection. A broker holds the credential and injects it into a subprocess at exec time. The agent's main process does not see the value, but the subprocess does. Process-tree-scoped brokers sit here. The agent works; the value is not in the agent's context window or ambient environment.

Knowing which tier a pattern targets tells you what threat it addresses.

The patterns that work

CyberArk Secretless Broker (sidecar intercept)

CyberArk's Secretless Broker is open source and runs as a sidecar container or process alongside an application. The application connects to a local listener (say, localhost:5432). The sidecar authenticates to the real backend using credentials stored in a CyberArk PAM vault, AWS Secrets Manager, Kubernetes secrets, or a local file. The application code is entirely credential-free.

CyberArk's pattern is the gold standard for server workloads. The threat model is a compromised application container: if an attacker gets code execution inside the app container, there is no credential to extract. The app container never had one. The sidecar holds the credential and uses it on the app's behalf.

For local coding agents, the sidecar pattern assumes a containerized or similarly bounded execution context. A developer's macOS terminal is not that. You cannot run CyberArk Secretless Broker as a sidecar in a Claude Code session without significant custom infrastructure. The pattern is correct for production services; it does not map cleanly to local development.

AWS IAM Identity Center and SSO short-lived credentials

AWS IAM Identity Center (formerly AWS SSO) replaces static AWS access keys with short-lived session tokens issued by an identity provider. The developer authenticates via aws sso login, receives credentials that expire (typically 8-12 hours), and those credentials are stored in ~/.aws/credentials under a named profile. No long-lived AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY pair lives in the environment or config.

For AWS-heavy teams, this is the right baseline. Rotating long-lived keys becomes unnecessary. The blast radius of a leaked token is bounded by the expiry time. AWS CloudTrail logs tie every API call to an SSO session identity, which is better for forensics than a shared service account key.

The credential is still short-lived, but it lands in ~/.aws/credentials as plaintext. An AI coding agent running in a shell that has completed aws sso login can read ~/.aws/credentials and inherit the active session token. It is short-lived, which limits the damage window, but it is not invisible to the agent. The Knostic pattern (agent persists what it sees in the environment) applies here too if the profile's environment variables are exported.

GitHub Actions OIDC (federate to cloud roles)

GitHub Actions OIDC is the closest thing to genuinely secretless for CI pipelines. A workflow job presents an OIDC token signed by GitHub to AWS, GCP, or Azure. The cloud provider validates the token against a configured trust relationship (this GitHub repo, this branch, this environment) and issues a short-lived cloud credential. No secret is stored in GitHub. The GitHub Actions secrets store is not involved.

GitHub Actions OIDC eliminates an entire category of pipeline secret leak. No stored AWS keys to rotate, no AWS_SECRET_ACCESS_KEY in GitHub Secrets to accidentally log, no token that outlives the job. The credential exists for the duration of the job and expires.

OIDC federation applies only to workloads running inside GitHub Actions (or equivalent OIDC-aware CI platforms). A developer running the same deployment script locally still needs credentials, and those credentials are often long-lived static keys. The "secretless CI" and "credentials everywhere on developer laptops" states coexist in the same organization frequently.

Workload identity and SPIFFE/SVID

SPIFFE (Secure Production Identity Framework for Everyone) and its reference implementation SPIRE give each workload a cryptographically signed identity document (SVID) based on what it is rather than a shared secret. A service running on a particular Kubernetes node with a particular service account gets an SVID signed by a trusted SPIRE server. Other services accept that SVID as proof of identity without sharing a password.

SPIFFE/SPIRE targets zero-trust architectures at scale. The security property is strong: workloads authenticate to each other with verifiable identity rather than shared secrets. SPIFFE SVIDs have short lifetimes (typically hours) and rotate automatically.

SPIFFE is designed for infrastructure-to-infrastructure authentication in distributed systems, and the operational cost is where most teams stop reading. It requires a SPIRE server cluster, proper attestation plugins, and PKI management. A team of four engineers building a SaaS product with one or two AI coding agents is not the target deployment. SPIFFE also does not address the local agent credential problem: an agent running on a developer laptop is not a SPIFFE workload with a verifiable identity by default.

Vault dynamic secrets (HashiCorp's lease-based ephemeral credentials)

HashiCorp Vault's dynamic secrets engine generates credentials on demand with a lease: you ask Vault for a Postgres credential, Vault creates a new user in the database, returns the credentials, and revokes them when the lease expires. No static password exists in Vault; Vault generates a fresh one per request.

Vault's dynamic secrets engine is the right pattern for database credentials in production. The blast radius of a leaked credential is bounded by the lease TTL (configurable, often 1 hour for databases). Vault's audit log records every request with caller identity. Lease revocation lets you force-expire credentials if a breach is detected.

For coding agent contexts specifically, Vault's dynamic secrets are accessible via API or CLI. You can write a wrapper that calls Vault before launching an agent session and injects the resulting credential. That wrapper is custom work, but the primitives exist. The Vault AppRole auth method lets you issue a short-lived Vault token for the agent session.

Vault carries significant operational overhead. A hardened Vault cluster with TLS, HA, a working unseal strategy, and proper audit-log shipping takes weeks to configure correctly. The IBM acquisition of HashiCorp in 2024 and the earlier Business Source License change pushed some teams toward OpenBao (Linux Foundation fork), but the operational profile is similar. For small teams without dedicated platform engineering, this is real cost.

Just-in-time injection brokers (process-tree scoped)

The sixth pattern is the one most specific to local coding agent contexts: a broker that holds credentials in an encrypted local vault, mints a time-bounded grant for a specific agent session, and injects the credential value into a subprocess environment at exec time. The agent's main process (and context window) never sees the credential directly. The value appears inside a specific child process when it is needed and disappears when the process exits.

JIT injection addresses the threat the other patterns leave open on the developer machine: the agent reads ambient environment variables, persists them to disk, and those files end up in unexpected places. If the credential was never in the ambient environment, never in the agent's context window, and only briefly in a short-lived subprocess, the state files the agent writes cannot contain the value.

The tradeoff: JIT injection brokers are local-first and single-developer in their typical implementation. They do not address server-to-server authentication, do not integrate with cloud IAM, and do not replace Vault or OIDC for production workloads. The correct layer is the developer machine, not infrastructure.

Comparison matrix

Where each pattern fails specifically for coding agents:

• CyberArk and SPIFFE require containerization or a running daemon the coding agent can authenticate to. Local agent sessions typically run as your user process without a workload identity.
• GitHub Actions OIDC does not exist outside CI. A developer running claude code locally has no OIDC token.
• IAM Identity Center tokens expire in hours, which is better than static keys, but the token still sits in ~/.aws/credentials where an agent can read it. It is short-lived credential exposure, not zero exposure.
• Vault dynamic secrets require a wrapper script. No coding agent ships one out of the box. If you build the wrapper, you have a workable setup; if you do not, the agent still inherits whatever is in your shell.
• JIT injection brokers do not federate, do not issue cloud IAM credentials, and do not replace any of the above for server workloads. They are the last-mile solution for the local development surface.

Why coding agents are a hard case

Standard secretless patterns assume one of two execution contexts: a network service with a stable identity (server, container, pod), or a CI job with a short, bounded lifetime. Coding agents are neither.

A Claude Code session runs for hours. Within that session, the agent spawns dozens of subprocesses: git, npm, bash, test runners, build tools, deployment scripts. The agent's parent process lives for the duration. Any credential in the parent's environment is accessible to every subprocess it spawns unless you explicitly scrub it.

Coding agents also write files. Claude Code, Cursor, Aider, and Codex CLI all maintain state files in or near the project directory. Those files accumulate context across the session. The Knostic disclosure found that settings.local.json was recording environment variables from agent sessions and those recordings ended up in npm packages. That is not a Claude Code-specific bug; it is a category behavior. State files that live in the repo tree, combined with publishing pipelines that include everything not explicitly ignored, produce credential leaks. The GitGuardian State of Secrets Sprawl 2026 report puts the AI-assisted commit leak rate at twice the baseline.

The multi-tool-call problem is less obvious. When an agent calls a tool that needs a database credential, the credential has to come from somewhere. If it comes from an environment variable the agent inherited at startup, it has been accessible for the entire session. If it comes from a sidecar or broker that injects it just before the subprocess runs, the exposure window is seconds.

Long-running sessions also defeat short-lived credential strategies if the session outlives the token. An AWS SSO session token that expires in 8 hours sounds safe until the developer starts a coding session at noon and the agent needs a credential at 11pm. The token-refresh ceremony interrupts the agent mid-task unless you build automation around it.

When "secretless" is the wrong answer

Long-lived static credentials are the right choice in a few specific scenarios.

Local development with no external exposure. If a developer's environment never sends credentials to a public network (fully local inference, local database, no cloud calls), the cost of federation infrastructure outweighs the benefit. The risk is internal to the machine. The practical mitigation is machine encryption, a strong account password, and keeping agents from writing state to paths that land in artifacts. A company spending a week building SPIFFE integration to secure a local SQLite credential is solving the wrong problem.

Simple tooling where complexity buys nothing. A solo developer running a personal project with one Stripe key and no team access does not benefit from a full Vault cluster. The overhead of a dynamic secrets engine exceeds the marginal security improvement over a well-isolated secret manager that injects at subprocess exec time.

Operational continuity during outages. A credential broker that requires a cloud service to issue tokens is not secretless in a meaningful sense during a service outage. It is "credentials plus an external dependency." For workloads that must continue operating when the identity provider is unavailable, a local credential store with appropriate controls is more reliable than federation that cannot issue new tokens when the IdP is down.

Legacy systems that cannot accept dynamic credentials. Some databases, APIs, and internal services do not support short-lived rotating credentials. You cannot make Vault dynamic secrets work if the downstream service requires a static password that you set in an admin panel months ago. Short-lived or not, if the credential cannot change, dynamic issuance is theater.

The pattern to reject: building secretless architecture at the CI and production layer (correctly), then relying on a long-lived personal access token or API key on every developer's laptop for local work, and calling the overall posture "secretless." That is common. It is not secretless.

A checklist you can paste into a PR or decision doc

## Secretless pattern evaluation checklist

Understand the execution context
- [ ] Is the workload a long-running server, a CI job, or a local agent session?
- [ ] Does the execution context have a stable workload identity (k8s service account, IAM role)?
- [ ] How long does the typical session run? Does it exceed your token TTL?

For CI pipelines
- [ ] GitHub Actions OIDC configured for AWS / GCP / Azure (eliminates stored secrets)
- [ ] No static cloud keys stored in GitHub Secrets for production environments
- [ ] Ephemeral runner or job-scoped credential where OIDC is not available

For server / container workloads
- [ ] IAM roles attached to EC2 / ECS / Lambda (no static keys in environment)
- [ ] Vault AppRole or K8s auth for dynamic database credentials
- [ ] SPIFFE/SPIRE evaluated for service-to-service auth at scale

For local coding agent sessions
- [ ] No long-lived API keys exported in ~/.zshrc or ~/.bashrc
- [ ] Agent state directories (.claude/, .cursor/, .aider/) in .gitignore and .npmignore
- [ ] Credentials injected at subprocess exec time, not in parent shell environment
- [ ] Audit log reviewed after each session for unexpected credential access
- [ ] 24-hour maximum grant window enforced; no indefinite agent access to production keys

Cross-cutting
- [ ] Short-lived token TTL shorter than typical agent session? Refresh strategy defined?
- [ ] Offline operation tested: what fails when IdP / cloud manager is unavailable?
- [ ] Audit log answers "which process accessed which credential and when?" without manual join
- [ ] Dynamic credential support confirmed for all target backends (not all accept rotation)

What this means for your stack

The pattern that eliminates most real-world credential leaks from coding agent sessions is exec-time injection: a broker holds the credential in an encrypted local vault, mints a session-bounded grant, and injects the value into the subprocess that needs it. The agent's context window stays clean. State files the agent writes contain references, not values. The audit log records every grant with a verifiable HMAC chain.

hasp is one working implementation of that model. It is a local-first ephemeral injection broker with process-tree scope. It holds credentials in an Argon2id-encrypted vault, never exposes values directly to the agent process, supports six agent profiles (claude-code, codex-cli, cursor, aider, hermes, openclaw), and maintains a tamper-evident audit log at ~/.hasp/audit.jsonl verifiable with hasp audit --verify. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the next session gets a reference instead of a key. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

What hasp does not do: federation, OIDC, cloud IAM integration, dynamic database credential generation. It is the last-mile solution for the developer machine. It does not replace GitHub Actions OIDC in CI or Vault dynamic secrets in production. Those layers are complementary, not competing.

The durable takeaway: a secretless posture at the pipeline layer and local ambient credentials on the developer machine are not equivalent. Most real leaks in 2026 come from the latter. Fixing the pipeline and ignoring the developer machine is solving the visible problem while leaving the actual attack surface intact.