Those artifacts let attackers bypass fresh authentication and reuse identity material elsewhere. Browser cookies, SSH keys, and cloud tokens are valuable because they can open source control, infrastructure, and developer services without forcing a new password or MFA challenge. That makes identity replay more profitable than simple device compromise.
Why attackers prize cookies, SSH keys, and cloud tokens
These artifacts are attractive because they are already trusted by systems that matter. A stolen browser cookie can preserve an authenticated session, an SSH key can open administrative access without a password prompt, and a cloud token can act as a ready-made delegation to developer or infrastructure services.
In practice, that makes them higher-value than many one-off device artifacts: the attacker is not trying to log in from scratch, but to inherit an identity path that already passed policy checks. Once replayed, the same material can often reach source control, build systems, cloud consoles, or internal APIs.
For teams trying to understand the pattern, the core issue is not just secret theft, but authority theft. The most profitable targets are the ones that bridge authentication, session continuity, and tool access in a way that survives across machines and networks.
Why AI coding tool campaigns focus on browser sessions, SSH, and cloud access
AI coding tools sit close to high-trust developer workflows, so campaigns often go after whatever grants immediate continuity inside that workflow. Browser cookies can preserve access to code review and cloud portals, SSH keys can jump into hosts or bastions, and cloud tokens can authorize API calls that move from the IDE into CI/CD or infrastructure.
This is why the campaign pattern is often broad rather than selective. An attacker can use one class of material for interactive access and another for backend automation, then pivot into the services developers already use to ship code. Ultimate Guide to NHIs — What are Non-Human Identities is useful background for understanding why these tokens and keys function as reusable identity material rather than ordinary data.
That matters because AI coding environments often concentrate many trust relationships in one place. If the campaign can reach the browser profile, the SSH agent, or the cloud credential cache, it may inherit enough trust to impersonate a developer across several systems without needing to defeat MFA again.
What makes identity replay more profitable than device compromise
Device compromise is valuable, but identity replay is usually more portable. A malicious actor who steals cookies, keys, or tokens can often move the access off the original machine, reuse it from elsewhere, and continue working until the artifact expires or is revoked. SSH Key and SSH Certificate Management Guide explains why unmanaged SSH material becomes a durable access path when key sprawl and orphaned keys are allowed to persist.
The same logic applies to cloud tokens and browser sessions. If the credential is bearer-style, unbound, long-lived, or over-scoped, the attacker gets a reusable capability rather than a single machine-bound foothold. Guide to the Secret Sprawl Challenge is relevant here because secret sprawl turns exposed material into a broad lateral-movement opportunity, especially when rotation and inventory are weak.
That is why campaigns often prefer identity material over ransomware-style disruption at first contact. The goal is to preserve access, blend into normal developer activity, and extract more value from source control, cloud spend, or internal tooling before defenders notice.
Risk and Threat Considerations
When browser cookies, SSH keys, and cloud tokens are exposed, the immediate risk is not just unauthorized login, but durable impersonation across the developer and cloud stack. These artifacts can bypass fresh authentication, survive across sessions, and let an attacker operate through trusted channels that defenders may not inspect closely.
Failure mechanism: The attacker steals bearer-style or replayable identity material, then uses it from a different device or network before expiry, revocation, or anomaly detection interrupts the session.
Impact: The same stolen material can be used to read source code, alter pipelines, access infrastructure, exfiltrate data, or extend compromise into adjacent services without triggering a new password or MFA challenge.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Cookies, SSH keys, and cloud tokens are identity-bearing secrets that attackers seek to steal and replay. |
| NHI-07 — Long-Lived Secrets | Replay value rises when cookies, keys, or tokens remain valid long enough to be reused elsewhere. | |
| NHI-05 — Overprivileged NHI | Stolen developer tokens often succeed because they carry more access than the task requires. | |
| Recommendation — Reduce secret exposure in browsers, shells, and tooling, and detect leaked identity material quickly. Shorten secret lifetimes and rotate anything that can authenticate beyond the original session. Limit scopes and entitlements so reused credentials cannot reach unrelated systems or admin paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The question centers on stolen authenticators and their reuse across systems. |
| AC-6 — Least Privilege | Replay is more damaging when stolen material can access many services or administrative functions. | |
| IA-9 — Identification and Authentication (Service and Other Non-Organizational Users) | Cloud tokens and SSH keys often authenticate services and developer tooling, not just humans. | |
| Recommendation — Manage issuance, lifetime, rotation, and revocation for credentials and tokens. Constrain each credential to the minimum permissions needed for the task. Use strong authentication controls for service and machine-to-machine access paths. | ||
Practitioner Guidance
What to verify: Treat cookies, SSH keys, and cloud tokens as distinct assets with different blast radii. Verify whether they are bounded to device, audience, or short TTL, and whether they can be replayed outside the original workflow.
What practitioners underestimate: The real problem is often not the theft event, but the retention of privilege after theft. If a token still works after a browser reset, a laptop rebuild, or an IDE reinstall, the compromise has probably crossed from endpoint hygiene into identity governance.
Practitioner takeaway: Prioritise controls that make stolen identity material hard to reuse, because replay resistance and rapid revocation matter more than perfect endpoint cleanliness once an attacker can harvest sessions and tokens.
Related resources from NHI Mgmt Group
- What breaks when AI coding requests bypass a shared gateway and rely on local keys or per-tool settings?
- How should organisations respond when an IDE extension attack targets cloud tokens, CI/CD secrets, and AI coding assistant credentials at the same time?
- Why do compromised service accounts, SSH keys, and tokens make cloud incidents spread so quickly?
- What happens when exposed API tokens or SSH keys are not rotated after a breach?