CSA’s finding is that LLMjacking has moved past resale.
Sysdig’s Threat Research Team documented VAPT, a framework that runs a hijacked Ollama server as its own reasoning engine to fingerprint, exploit, and extract without an operator between stages [1]. The same team disclosed what it calls the first confirmed in-the-wild intrusion driven by an autonomous LLM agent — a Marimo notebook RCE chained through AWS Secrets Manager to an internal database in four automated pivots, the exfiltration itself finishing in under two minutes [1]. Operation Bizarre Bazaar documented a functioning commercial marketplace for stolen access across thirty-plus providers, 35,000 cataloged sessions in six weeks [1].
All of this is written, correctly, at the level of the market. CSA’s charter covers AWS Bedrock, Azure OpenAI, Google Vertex, self-hosted Ollama and vLLM stacks, and Anthropic in the same paragraph [1] — that is the job of a cross-provider threat research note. It is not the job of that note to adjudicate any single vendor’s architecture, and it doesn’t try to.
Where the recommendations stop
Read CSA’s Immediate Actions section closely and one pattern holds: rotate keys on a schedule [1], scan repositories for leaked secrets [1], set billing alerts as what the report itself calls “a detection backstop rather than an early warning mechanism” [1]. This dispatch reads that pattern through this practice’s deterministic/probabilistic enforcement-tier distinction — synthesized across the corpus this practice has reviewed, not any one source’s own framing: controls that structurally prevent a failure sit apart from controls that make the failure easier to notice or clean up once it has already happened.
Nearly everything in CSA’s recommendation set sits in the second tier. That isn’t a criticism of the report — it’s an accurate description of what’s achievable when the artifact being protected is a static, long-lived string that persists as a target for as long as it exists, regardless of how disciplined the rotation schedule is.
Where the Claude provider actually sits
On the credential itself, Anthropic’s answer isn’t a faster rotation cadence. Workload Identity Federation exchanges a workload’s existing IdP-issued token for a Claude API access token that expires by default in 3,600 seconds — minimum 60 — with no sk-ant-... string ever minted, distributed, or stored in the workload’s environment [2]. CSA’s call for “short credential lifetimes” [1] describes a policy outcome; WIF makes that outcome the default architecture rather than a target to audit against. There is no key to catalogue in a marketplace like Bizarre Bazaar’s [1] if the credential never persists long enough to be scraped, cached, or resold in the first place.
Two more of CSA’s asks resolve the same way, one level down from the credential itself. “Use different API keys for development, testing, and production” [1] is a Workspace boundary in Claude’s architecture — each Workspace holds its own keys, rate limits, and spend caps, and keys cannot move between them [3]. “Configure billing alerts and hard spending limits” [1] is a Workspace Spend Limit set in Console, readable and comparable against live consumption through the Rate Limits API and the Usage and Cost API [3][4] — the same granularity CSA’s behavioral-monitoring recommendation asks security teams to stand up against their own SIEM from scratch [1].
Secret scanning closes the same way at the provider layer, not only the repository layer: Anthropic’s partnership with GitHub means a sk-ant- key exposed in a public repo is detected, reported to Anthropic, and deactivated automatically — before a security team’s own scanning program would necessarily catch it [7].
The one gap that doesn’t transfer
CSA treats the unauthenticated self-hosted endpoint as the acute case — Ollama on port 11434, no authentication by default, repeatedly exploited in the campaigns it documents [1]. That failure mode has no equivalent on api.anthropic.com. Every inference request already requires an x-api-key header or a WIF-minted token, by construction, not by the customer’s configuration discipline [2]. The exposure CSA describes reappears only where an enterprise routes Claude through its own IAM layer — Bedrock, Vertex — and misconfigures that layer, or runs a self-hosted open-weight model alongside its Claude deployment. That’s a scope boundary worth stating plainly in any client-facing read of this report: the acute risk in CSA’s own worked examples is a self-hosted-infrastructure problem, not a hosted-Claude-API problem.
CSA’s report is accurate and its recommendations are sound for the audience it’s writing to — a market spanning ten-plus providers and DIY inference stacks with no shared credential architecture. Scored against the Claude provider specifically, four of CSA’s five recommendation clusters already have a structural answer in Anthropic’s own published documentation, and the fifth — behavioral monitoring — has the telemetry surface already exposed, just not the alerting logic built on top of it.
An enterprise that reads this report and launches a rotation-and-scanning program over its Claude deployment, without first checking whether Workload Identity Federation already retires the underlying gap, is building probabilistic controls over a threat the provider has already answered structurally.
