Keep API keys out of chat: secret-safe coding agents

At a glance

What this is: This is Delinea's practical guide to keeping API keys and other secrets out of coding-agent workflows by fetching them at runtime instead of pasting or storing them locally.

Why it matters: It matters because secret handling now sits inside developer productivity tools, which means IAM, PAM, and NHI teams have to govern ephemeral access, auditability, and rotation across human and machine-assisted workflows.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Delinea's guide to secret-safe coding agents and MCP-based secret handling

Context

API keys, tokens, and certificates are secrets, and once they move into chat windows, shell history, local files, or copied snippets, they stop behaving like controlled credentials and start behaving like exposed data. In coding-agent workflows, that boundary matters because the tool itself becomes part of the secret-handling path, which puts IAM and PAM assumptions under pressure.

Delinea's article focuses on a common development pattern that security teams are already seeing in practice: agents need credentials to test, debug, deploy, and troubleshoot, but the usual handling methods were never designed for persistent or semi-persistent machine assistance. That makes the problem less about convenience and more about whether access is still governable when the workflow is mediated by an agent.

This is a machine-identity and secrets-governance problem first, but it also affects human programme design because developers are the ones deciding how secrets are disclosed to tools. The starting point is typical, not unusual: teams want speed, but they inherit leakage risk unless access is re-shaped around short-lived retrieval and traceable control.

Key questions

Q: How should security teams handle secrets in coding-agent workflows?

A: Security teams should treat coding-agent workflows as privileged secret paths. Secrets should be fetched at runtime through an authenticated identity flow, kept in memory only for the task, and cleared immediately after use. Avoid paste-once controls, .env files, and shell history exposure, because they do not prevent persistence across the full workflow.

Q: Why do coding agents increase the risk of secret leakage?

A: Coding agents expand the places where a secret can be exposed, including chat logs, local files, terminal history, and provider retention. That means a single disclosure can create multiple persistent traces, turning one action into a longer-lived access problem. The risk grows whenever the secret is visible outside a tightly controlled retrieval path.

Q: What breaks when secrets are handled through files or chat with agents?

A: What breaks is the assumption that a secret only exists in one controlled place at one controlled time. Files, chat windows, and copied snippets create durable copies that can be committed, synced, or reused later. Once that happens, the organisation loses both lifecycle control and reliable audit scope.

Q: Who should own secret governance for coding agents?

A: Ownership should sit with identity, PAM, and platform security teams together, because the problem spans authorization, session control, and auditability. Developer teams can use the workflow, but they should not define the trust boundary. The governing question is whether access is short-lived, traceable, and revoked as soon as the task ends.

Technical breakdown

Why coding agents turn secrets into a runtime exposure problem

Coding agents such as assistants in IDEs or terminal workflows can request secrets as part of tests, debugging, or deployment work. The technical risk is not only that a secret is visible once, but that the access path itself can create durable traces in logs, files, history, or provider-side retention. That changes the control objective from simply storing a secret securely to ensuring the secret is never rendered in plaintext where it can be copied, indexed, or replayed. In identity terms, the secret becomes a runtime dependency with a much wider blast radius than a human-only workflow.

Practical implication: treat any agent workflow that can see plaintext secrets as a privileged data path, not a developer convenience.

How MCP changes secret retrieval without changing ownership

Model Context Protocol can act as a controlled bridge between the coding agent and the secret source, but it does not remove the need for identity checks or authorization. In the pattern described here, the agent requests a secret, MCP authenticates the request through existing permissions, and an ephemeral session key is used to fetch the secret at runtime. The important distinction is that the secret remains governed by the underlying identity and vault policy rather than being copied into the agent itself. That keeps access transient, but it still requires strong session control, approval logic, and auditability.

Practical implication: govern the retrieval path, not just the vault, because the bridge becomes part of the trust boundary.

Why in-memory handling and cleanup matter more than paste-once controls

Paste-once widgets and .env files solve a narrow usability problem, but they do not solve persistence. If the secret is saved to disk, shell history, or a file the agent can later read, the exposure window remains open after the task is complete. In-memory retrieval and explicit cleanup narrow that window, especially when the secret is needed for a single command or test run. This is a lifecycle issue as much as a storage issue, because the credential should exist only long enough to complete the task and then be withdrawn from the session.

Practical implication: require ephemeral secret use and deterministic cleanup for every agent-assisted workflow that touches credentials.

Threat narrative

Attacker objective: The attacker aims to obtain durable access to services and data by converting a developer workflow into a reusable secret source.

1. Entry occurs when a developer pastes an API key, token, or database credential into a coding assistant or stores it in a file the agent can read.
2. Escalation happens when the secret is retained in chat logs, shell history, local files, or provider-side traces beyond the original task.
3. Impact follows when the exposed credential is reused to access production systems, move laterally into connected services, or leak into training and audit artefacts.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret exposure debt is the right concept for coding-agent workflows: once a credential is pasted, cached, or written to disk, the organisation inherits an exposure liability that outlives the developer session. That liability is broader than a simple secrets-management miss because the agent can propagate the secret into multiple traces at once. The implication is that governance has to measure where secrets can surface, not just where they are stored.

Paste-once controls are structurally too narrow for agent-assisted development: they assume a single human interaction with a single UI, while coding agents operate across CLI, IDE, test, and CI contexts. That mismatch means the control may look safe in one channel while remaining unsafe in the workflow that actually matters. Practitioners need to understand that channel-specific controls do not equal workflow-safe controls.

Runtime secret brokering belongs in NHI governance, not just developer tooling: the article's pattern is really about making short-lived credential access governable across machine-assisted tasks. That fits OWASP-NHI and NIST CSF thinking because the issue is identity, authorization, and auditability under temporary use. The practitioner conclusion is that secrets handling for coding agents should be treated as a governed NHI lifecycle problem.

MCP can reduce exposure, but it also concentrates policy responsibility at the bridge: the control point shifts from the developer's clipboard to the authentication and retrieval path. That does not eliminate risk, because the bridge now decides when access is allowed, for how long, and with what trace. The implication is that teams must review whether the new trust boundary is actually tighter than the old one.

AI-assisted development exposes a shared governance gap across human and machine identity: humans still decide whether to disclose a secret, but machines now execute the retrieval and consumption path. That creates a mixed governance problem where human intent and machine execution are no longer cleanly separated. Practitioners should treat this as a lifecycle and privilege-control issue that spans both IAM and NHI.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For a broader lens on secret exposure and lifecycle control, see Guide to the Secret Sprawl Challenge and the operational patterns it maps to.

What this signals

Secret-safe development is becoming an identity governance problem, not just a developer ergonomics problem: teams that rely on chat-based assistance, terminal copilots, or IDE agents need a policy for ephemeral secret retrieval, traceability, and immediate cleanup. When those controls are missing, the workflow itself becomes part of the attack surface.

The better programme signal is not whether developers can move faster, but whether secret access can be bounded to a session and withdrawn without leaving recoverable artefacts. That is where IAM, PAM, and workload identity controls need to converge.

With 44% of developers following secrets best practices in our cited research, the real gap is behavioural as much as technical, which means enforcement, guardrails, and training all need to align.

For practitioners

• Define secret-safe coding-agent workflows Classify every agent-assisted task that touches credentials, then require runtime retrieval instead of pasting secrets into chat, files, or shell commands.
• Broker secrets through an approved identity path Use an authenticated bridge such as MCP only when the request can be tied to an existing identity, a short-lived session, and a recorded approval decision.
• Eliminate durable secret traces Block workflows that write secrets to disk, shell history, or shared logs, and verify that cleanup happens immediately after the task completes.
• Separate developer convenience from credential authority Limit what the coding agent can request, enforce least privilege on each secret namespace, and review whether the same access should exist in CI, IDE, and terminal contexts.

Key takeaways

• Coding agents turn secrets into a runtime governance problem because the access path can leave durable traces even when the secret itself is never intended to persist.
• The evidence points to a stubborn gap between secrets confidence and secrets control, with remediation and behaviour data showing that leakage risk remains operational, not theoretical.
• Teams should move to short-lived retrieval, in-memory use, and immediate cleanup if they want agent-assisted development to stay inside acceptable identity and audit boundaries.

Key terms

• Secret-safe coding agent: A coding assistant that can request or use credentials without exposing them in plaintext to chat, files, or logs. The security goal is not just convenience but containment, so the secret is retrieved only for the task and then removed from the session.
• Ephemeral session key: A short-lived credential used to authorize a single retrieval or action without creating a standing secret. In governed workflows, the key is tied to identity, scope, and time, which reduces the chance that an agent-assisted task creates lasting access.
• Secret sprawl: The uncontrolled spread of credentials across tools, files, logs, and workflow steps. It is a governance problem because every extra copy expands the exposure window, weakens auditability, and makes revocation harder across both human and machine-assisted processes.
• Runtime secret brokering: A control pattern where credentials are fetched only when needed and delivered directly into a controlled execution context. The broker becomes part of the trust boundary, so authorization, logging, and cleanup must all be enforced at request time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Delinea: Keep your API keys out of the chat: A practical guide to secret-safe coding agents. Read the original.