Because support workflows encourage people to paste whatever unblocks the request, including tokens, config snippets and attachments with sensitive data. Once that information lands in a ticketing or knowledge base system, it can persist far beyond the original incident unless teams apply NHI lifecycle management and content controls.
Why Support Systems Leak Secrets So Easily
ServiceNow tickets and knowledge bases are built to accelerate resolution, not to enforce secret hygiene. That means users, agents, and even automation often paste the fastest fix available, including API keys, session tokens, certificates, config files, and screenshots. Once captured, that content is copied, indexed, exported, retained, and reused far beyond the original incident. NHIMG’s Guide to the Secret Sprawl Challenge shows how quickly secrets escape their intended boundary when operational convenience wins.
The problem is not limited to support desks. Ticket comments can be mirrored into chat, knowledge articles, CMDB records, and email threads, which multiplies the exposure surface. OWASP’s OWASP Non-Human Identity Top 10 treats secret handling as an identity problem because leaked credentials often become live pathways into production systems. In practice, many security teams only discover the issue after a knowledge article has already been shared internally or a ticket export has already left the original workflow.
That persistence is why leaks in support tooling are so damaging. A password reset request may be closed in minutes, but the secret can remain searchable for years unless it is detected, revoked, and removed from every downstream copy.
How Secrets Move Through Tickets, Articles, and Attachments
Support workflows create several predictable leak paths. A requester pastes a token into a ticket comment. An analyst adds logs with embedded credentials. A knowledge author copies the resolution into a reusable article and forgets that the example still contains live values. Attachments are even harder to govern because they often include screenshots, exports, and diagnostic bundles that bypass simple text filters. GitGuardian’s 2026 research found that 28% of secrets incidents now originate outside code repositories, in systems like Slack, Jira, and Confluence, and those incidents are 13% more likely to be critical than code-based leaks.
The operational response should combine content controls with NHI lifecycle management. At minimum, organisations should:
- classify ticket fields and article templates so secret-bearing content is restricted by default.
- scan comments, attachments, and exports for credentials before they are stored or published.
- issue short-lived credentials where possible, then revoke them automatically when the task closes.
- separate human-readable troubleshooting notes from any live secret material.
- log and review every rediscovery of a secret as both a process failure and an identity event.
For broader incident context, the 52 NHI Breaches Analysis shows how often leaked access material becomes the first step in larger compromise chains, while Anthropic’s first AI-orchestrated cyber espionage campaign report reinforces how quickly exposed credentials can be operationalised once discovered.
These controls tend to break down when support teams rely on free-text fields and unmanaged attachments because the system cannot reliably distinguish troubleshooting detail from a live secret.
Where Controls Break Down in Real Operations
Tighter secret controls often increase friction, so organisations must balance faster case handling against stronger content governance. That tradeoff matters most in environments with high-volume support, outsourced service desks, or engineering teams that use tickets as a collaboration layer. Best practice is evolving, but there is no universal standard for this yet: some teams redact on ingestion, others quarantine suspicious attachments, and others attempt after-the-fact cleanup. The right model depends on how much trust the workflow has to absorb.
Edge cases are common. Database dumps attached to incidents may contain embedded service credentials. Sandbox examples in a knowledge base may be safe to read but unsafe to copy. Temporary break-glass tokens may be appropriate during an outage but still unacceptable once the incident is closed. NHI guidance is clearest when secrets are long-lived and manually managed; it is less settled when the secret is generated by automation, embedded in agent-driven workflows, or propagated through multiple SaaS systems.
That is why current guidance suggests treating support tooling as part of the identity plane rather than as passive documentation. Pair secret scanning with retention limits, approval workflows for article publication, and revocation playbooks that assume exposure has already occurred. For deeper context, NHIMG’s Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs — Static vs Dynamic Secrets show why static credentials persist far longer than teams expect.
In practice, the hardest failures appear when support content is treated as harmless reference material even though it still contains credentials that can be replayed into production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret sprawl and exposure in support systems are direct NHI lifecycle risks. |
| NIST CSF 2.0 | PR.DS-6 | Data protection controls apply to secrets embedded in tickets, notes, and attachments. |
| NIST AI RMF | AI RMF governance helps manage automated workflows that may paste or propagate secrets. |
Assign ownership for secret handling in support workflows and add human review where automation can expose data.
