What makes GenAI usage part of the same secrets problem?

Why This Matters for Security Teams

GenAI becomes part of the same secrets problem because the leak path is the same: a person or workload gains access to sensitive material, then moves it into a place the security team cannot reliably see, govern, or revoke. In practice, unmanaged chat accounts, browser extensions, external plugins, and shadow workflows can expose API keys, tokens, prompts, source snippets, and customer data in one motion. That is why this is not just an AI policy issue. It is a secrets handling issue that now includes identity, data handling, and access control.

The control failure is especially visible when secrets are copied into AI tools to speed up troubleshooting or code generation. Once that happens, the organisation loses the guarantees it expects from PAM, RBAC, and conventional audit trails. The governance boundary has shifted from the repository alone to the full interaction surface of the model, the agent, and the plugin ecosystem. NHIMG research on Guide to the Secret Sprawl Challenge shows how fragmentation weakens centralised control, and the OWASP Non-Human Identity Top 10 frames the wider risk around machine identities and exposed credentials. In practice, many security teams encounter GenAI leakage only after a secret has already been pasted into an unmanaged workflow, rather than through intentional governance.

How It Works in Practice

GenAI usage turns the secrets problem into a broader lifecycle issue. A user, developer, analyst, or agent may retrieve a credential from a vault, inject it into a prompt, pass it through an external connector, or let a tool preserve it in chat history or telemetry. That means the organisation must control not only where secrets are stored, but where they are disclosed, copied, transformed, and logged. The same applies when an AI agent acts on behalf of a human: the agent may chain tools, call APIs, and persist intermediate context in ways that create new exposure points.

Current guidance suggests treating AI tool access as a privileged pathway, not a convenience layer. That means aligning with ZTA and workload identity principles, using short-lived credentials, and applying policy at request time rather than relying on static role assignments. NIST AI RMF and the OWASP NHI guidance both point toward governance that is contextual, monitored, and revocable. For implementation detail, the Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful for distinguishing long-lived credentials from ephemeral access patterns, while the OWASP Non-Human Identity Top 10 helps teams map the control gaps.

• Issue JIT credentials for the task, not standing access for the user or agent.
• Bind the credential to workload identity so the system knows what is acting, not just who requested it.
• Block external plugins and unsanctioned connectors unless they are reviewed and logged.
• Prevent prompts, transcripts, and tool outputs from entering unclassified storage or unapproved SaaS systems.
• Require automated revocation when the task ends or the session expires.

NHIMG’s Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack show the same pattern in software pipelines: once secrets move into uncontrolled execution paths, visibility and revocation collapse. These controls tend to break down in unmanaged BYO-AI environments because the organisation cannot reliably inspect tool permissions, session state, or downstream logging.

Common Variations and Edge Cases

Tighter AI and secrets control often increases friction for developers and analysts, so organisations must balance faster workflows against reduced leakage risk. That tradeoff is real, especially where teams depend on rapid experimentation or third-party model services.

One common edge case is internal-only GenAI use. Private deployment does not eliminate the problem if employees paste production secrets, customer records, or deployment tokens into local tools that still retain chat history, browser cache, or vendor-side telemetry. Another edge case is agentic automation. Autonomous agents may need to call multiple systems in sequence, which makes static RBAC too blunt and often too persistent. Best practice is evolving toward intent-based authorisation, where access is granted for the specific action being requested and revoked immediately after completion. There is no universal standard for this yet, but the direction of travel is clear: short-lived access, explicit context, and continuous review.

Teams should also watch for non-code leakage. NHIMG research shows that secrets incidents increasingly originate outside repositories, including chat and collaboration tools, which makes GenAI a natural extension of the same risk surface. The DeepSeek breach is a reminder that new AI services can create credential exposure before guardrails catch up. For standards-based governance, the OWASP Non-Human Identity Top 10 remains relevant, while NIST AI RMF and CSA MAESTRO are useful where the organisation needs policy, accountability, and runtime control across autonomous workflows. In practice, the hard cases are usually not malicious insiders but convenience-driven workflows that quietly bypass review until a token is already live in the wrong place.

Related resources from NHI Mgmt Group

• What makes idle secrets such a serious NHI risk?
• What makes agentic AI an NHI governance issue?
• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?