How can organisations reduce the risk of secrets in ChatGPT and other AI tools?

Why This Matters for Security Teams

AI tools turn secret exposure from a code-only problem into a broader identity and data-handling issue. A pasted API key in ChatGPT, a token surfaced in a shared prompt log, or a credential copied into a collaboration app can all create an active path to production systems. That means the boundary for secrets governance is no longer limited to repositories and scanners. It now includes chat platforms, browser extensions, and any workflow where users can move sensitive context into an AI service.

The operational risk is amplified by how often secrets escape outside source control. NHIMG research on The State of Secrets Sprawl 2026 found that 28% of secrets incidents now originate outside code repositories, including Slack, Jira, and Confluence, and those incidents are 13% more likely to be critical than code-based leaks. That pattern matters because AI assistants increasingly sit inside the same collaboration layer. Current guidance from NIST Cybersecurity Framework 2.0 still applies, but it has to be translated into discovery, protection, detection, response, and recovery controls for AI-facing workflows. In practice, many security teams encounter the problem only after a token has already been indexed, logged, or reused, rather than through intentional governance design.

How It Works in Practice

Reducing this risk starts with treating AI tools as part of the secrets attack surface. Discovery should cover prompt histories, chat exports, file uploads, browser memory, ticket text, and integration logs. Once a secret is found, the response should not stop at alerting. It should trigger ownership mapping, revocation, and review of every identity that could still use that credential. That includes humans, service accounts, and workloads tied to the affected repository or system.

One useful operating pattern is to combine scanning with a short control loop:

• Detect secrets in AI conversations and adjacent collaboration systems.
• Classify the secret by type, scope, and blast radius.
• Map it to the owning team and the downstream systems it can reach.
• Revoke or rotate it automatically when possible.
• Review access for users who can reach sensitive repositories or prompt sources.

NHIMG’s Guide to the Secret Sprawl Challenge is a practical reference for understanding why fragmented secret handling creates blind spots, while Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why long-lived secrets increase exposure when they are copied into tools that retain context. This is also where automation matters: GitGuardian and CyberArk report that the average time to remediate a leaked secret is 27 days, and 64% of valid secrets leaked in 2022 are still valid and exploitable today. Those figures show why detection without revocation is incomplete. These controls tend to break down when AI tools are allowed to retain conversation history indefinitely because old prompts become a persistent secret store.

Common Variations and Edge Cases

Tighter secret controls often increase friction for developers and analysts, so organisations need to balance speed against containment. The tradeoff is especially visible in teams that rely on shared prompts, sandbox credentials, or copy-paste workflows to move quickly. There is no universal standard for this yet, but current guidance suggests using short-lived credentials, scoped access, and explicit approval for any secret that must enter an AI workflow.

Two edge cases deserve special attention. First, internal repositories are not inherently safe: NHIMG research shows they are 6x more likely to contain secrets than public ones. Second, some AI-related leaks are now showing up in protocol and integration files, not just code. That makes platform engineering, DevOps, and security operations jointly responsible for the control plane. The OWASP Non-Human Identity Top 10 and OWASP NHI Top 10 both reinforce the need to govern non-human access with the same seriousness as human access. AI systems that can forward, summarise, or transform secrets across tools make retention policy just as important as detection. Where chat data is mirrored into third-party plugins, ephemeral handling is often preferable, because persistent logs create a second copy of the secret that may outlive the original incident.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• How should security teams reduce risk from AI agents and developer tools that use secrets locally?
• How can organisations reduce risk from AI tools without banning them?
• Why do leaked secrets remain such a persistent NHI risk?