Topic starter
25/06/2026 12:46 am
TL;DR: Coding agents such as Copilot, Codex, and Cursor can expose API keys, database credentials, and tokens when secrets are pasted into chat, stored in files, or left in shell history, according to Delinea. It proposes MCP plus Secret Server to keep secrets in memory and auditable, as the deeper issue is that developer workflows are now secret-bearing runtime environments, so traditional paste-once or .env handling no longer matches the risk.
Editorial analysis by NHI Mgmt Group, based on content published by Delinea: “Keep your API keys out of the chat: A practical guide to secret-safe coding agents”.
Key questions
Q: What breaks when developers paste API keys into AI-built apps?
A: The application loses clean attribution, revocation, and scope control.
Q: Why do coding agents make secret exposure harder to govern?
A: Because the agent sits inside the same workflow where secrets are requested, displayed and reused, the organisation loses the clean separation between credential issuance and credential use.
Q: How should security teams stop secrets from ending up in shell history and files?
A: They should redesign agent-assisted tasks so the secret is fetched into memory at runtime, used for the specific task and then cleared, rather than entered manually or stored in a file.
Practitioner guidance
- Remove plaintext secrets from chat workflows Block developers from pasting API keys, tokens and credentials into coding-agent prompts, logs or transcripts, and enforce this in engineering policy and tooling.
- Broker secret access through ephemeral fetches Use a short-lived retrieval path so the agent gets permission to fetch a secret at runtime rather than a reusable credential stored in the prompt or file.
- Keep secrets out of shell history and disk Refactor agent-assisted workflows so sensitive values are injected only in memory and cleared immediately after use, with no .env or command-history persistence.
Bottom line: Coding agents create a new credential-handling problem because the secret can leak through the same interfaces used to help developers work faster.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 9:46 am
Secret-bearing developer workflows are now part of the identity surface: When coding agents can read, echo and persist secrets, the boundary for NHI governance extends into the developer workstation and chat layer. That means the real control question is not whether the secret is stored centrally, but whether the workflow can prevent plaintext exposure during task execution. Practitioners should treat the coding-agent session as a governed credential-handling environment, not a harmless productivity layer.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations rotate credentials that were used with coding agents?
A: Yes, because once a credential has passed through a coding-agent workflow the organisation has to assume it may have reached logs, files or other persistent surfaces. Rotating and revoking those secrets reduces the chance that an old value remains usable after the original task is over.
👉 Read our full editorial: Keep API keys out of chat: secret-safe coding agents