Who is accountable when cryptojacking starts from exposed secrets?

Accountability usually spans the team that owns secret storage, the platform owner that granted the permissions, and the security function that failed to detect exposure. The practical lesson is that cryptojacking is a governance issue as much as a technical one. Teams need clear ownership for secret hygiene, access scope, and anomaly response.

Why This Matters for Security Teams

When cryptojacking begins with exposed secrets, the real failure is not just theft of a token. It is a breakdown in ownership across secret storage, access scope, and detection. A leaked API key, cloud credential, or CI token can let an attacker spin up compute, pivot into a workload, and hide mining activity inside legitimate automation. OWASP’s OWASP Non-Human Identity Top 10 treats this as an identity governance problem, not merely a hygiene issue.

NHI Management Group research shows why the exposure problem keeps recurring: in The State of Secrets Sprawl 2026, 64% of valid secrets leaked in 2022 were still valid and exploitable today. That means accountability cannot stop at detection. The team that owns the secret store, the platform owner that granted broad permissions, and the security function that missed the anomaly all have a role in the failure chain. In practice, many security teams discover cryptojacking only after cloud spend spikes or quota alerts, rather than through intentional exposure monitoring.

How It Works in Practice

Accountability becomes clearer when the incident is broken into control points. First, the team that issued or stored the secret owns its lifecycle: creation, scoping, rotation, and revocation. Second, the platform or application owner owns the blast radius created by that secret, including whether it was tied to a permissive role or a production workload. Third, the security team owns detection, alert triage, and escalation paths.

This is where current guidance suggests using least privilege, short-lived credentials, and workload-specific identities rather than reusable static secrets. The Ultimate Guide to NHIs — Static vs Dynamic Secrets explains the operational advantage of dynamic credentials: if a token is only valid for a narrow task window, cryptojacking has less time to take hold. In parallel, the CI/CD pipeline exploitation case study shows how runner credentials and automation accounts can become the entry point when they are over-scoped or left exposed.

• Assign a named owner for each secret, role, and workload identity.
• Use just-in-time issuance and revoke on task completion.
• Monitor for unusual compute, region changes, and mining-related API calls.
• Review whether the exposed secret could mint more secrets or assume higher privilege.

For implementation detail, the OWASP NHI guidance aligns with reducing standing access, while the Anthropic report on the first AI-orchestrated cyber espionage campaign report reinforces how fast automation can chain tools once a credential is available. These controls tend to break down when secrets are reused across many services because revocation becomes slow and the true blast radius is no longer traceable.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance faster delivery against more frequent rotation, inventory, and incident response work. That tradeoff matters because not every exposure starts in source code. NHI Management Group notes in The State of Secrets Sprawl 2026 that 28% of secrets incidents now originate outside repositories, including Slack, Jira, and Confluence, which means ownership must extend beyond engineering into collaboration systems.

There is no universal standard for this yet, but current guidance suggests treating any secret that can create infrastructure or access billing-sensitive services as a high-accountability asset. The hardest edge case is shared automation: if one token supports multiple pipelines or environments, no single team can confidently claim full control over the blast radius. Another common exception is “valid but forgotten” secrets, where detection occurs long after initial exposure and the mining activity is intermittent.

In those cases, accountability should be assigned by control failure, not just by team charter: who approved the scope, who failed to rotate, and who missed the anomaly. The practical lesson is that cryptojacking often reveals weak governance over secrets long before it reveals weak malware detection.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?
• What should security teams do about secrets hidden in SharePoint?