An attacker steals an API key used by an AI application. Fixing the application closes the entry point, but the key may still work. The attacker can use it from another machine to run AI requests through the company’s account.
Anthropic’s September 2026 threat intelligence report follows this kind of reuse across several operations. Its attack lifecycle and workflow diagrams explain how an initial credential can lead to wider access, data theft and resources for the next attack. For security teams, the task is to identify each of those connections and decide where to interrupt them.
What the report covers
Anthropic describes selected operations it disrupted between December 2025 and August 2026, covering cyber operations, surveillance, influence, weapons, biological misuse, fraud and illicit model distillation. These are cases from its investigations, not a measure of how common each threat is. This article focuses on the cyber workflows and what they teach about AI agent security and incident response.
There are two different problems to account for: attackers using AI against a company, and a company’s own agents taking actions beyond their assignment. The agent evaluation incidents we covered previously concern the second problem. Restricting an internal agent’s tools will not stop an attacker running a separate agent on another machine.
Attack lifecycle and AI integration
In the GTG-50014 case, Anthropic maps nine stages, from finding access to selling stolen material and hiding activity. The arrows returning to earlier stages matter: the operation can use what it steals to support further attacks. This is a model of the reported activity, not a fixed sequence for every AI-assisted intrusion.
1–3: Find access and check whether it works
The first stages are sourcing and reconnaissance, discovery, and validation. Operators find exposed credentials or obtain them through deception, then check which accounts and permissions they unlock. The report describes repeated searches across applications, repositories and other exposed sources. Finding a key and confirming useful access are separate steps. Pages 16–17.
Defenders should make that distinction too. A secret-scanning alert starts an investigation: is the key active, which service accepts it, and what has it been used to do? Removing it from a repository does not revoke copies the attacker already holds.
4–7: Expand access, take data and keep a way back in
The next stages cover expanding access inside the victim, moving data out, storing it for reuse or sale, and creating persistent access. In the report, a working credential could expose further secrets or reach a provider’s downstream customers. Operators also created new keys and sessions to retain access. Pages 18–19.
A response focused only on the first account can miss these changes. Review newly created credentials, administrative actions, cross-customer access and bulk exports. Establish which access was removed and which data had already left the environment.
8–9: Make money and hide the activity
The diagram ends with monetization and cover. The associated workflows include selling access, extortion and short-lived keys used during data theft. It also draws two return paths: proceeds fund further discovery, while stolen computing access and keys go back into operations. Pages 20–21.
Those paths explain why an AI credential has value beyond the application that exposed it. An attacker can resell it or use the victim’s account to support unrelated activity. Incident response needs the AI provider’s usage and account records as well as the application logs.
AI connects work across this cycle. Anthropic describes Claude helping operators understand unfamiliar APIs, write export tools and repeat tasks across targets. The role of AI is in this repeated work between stages; the report does not claim that every stage ran without human direction. AI use during the intrusions, page 14.
Common workflows observed: four paths to wider access
Anthropic’s next diagram shows four different starting points. Each path shows how access can spread beyond the first exposed credential.
A key inside a mobile app opens cloud access
In the “app-token cascade,” an embedded key leads to a cloud account, then to build pipelines and stored secrets. The reported workflow continues into the victim’s production infrastructure. A secret shipped in a client application can therefore affect systems far beyond that app.
The review should cover the key’s permissions and everything those permissions exposed. Releasing a corrected app does not invalidate copies of the old key. Check cloud and build-system records for newly created access and changes made during the exposure.
A provider’s stored tokens expose several customers
In the “vendor-vault fan-out,” attackers copy a provider’s backup store containing customer tokens and application secrets. Those tokens let them act through the provider’s integration and reach multiple customer environments. The diagram also shows new keys created to retain access.
For a SaaS company, the review must include customer integrations, not just employee accounts. Determine which customers each token can reach, how it is stored and how access can be revoked per customer. Logs should identify both the integration and the customer whose data it accessed.
An administrator token opens more sessions and secrets
In the “platform-admin amplification” workflow, one administrative token leads to additional sessions, platform secrets and bulk data exports. The diagram includes keys created, used and revoked within minutes. Checking only the credentials that still exist can miss that activity.
Review the history of token creation, use and deletion alongside exports and session activity. A service may accept a valid token even when the person using it stole it. Retain records outside the account being investigated where possible.
Login responses help attackers sort stolen credentials
The “oracle run” begins with lists of credentials. Differences in login responses help operators test which accounts work, after which they sort them by value and extract stored value or resell access. Here, “oracle” means a system response that reveals whether a guess was correct.
Review what failed and successful login responses reveal, how repeated attempts are limited and how abuse is detected across accounts. Authentication monitoring belongs in the response alongside agent controls: this workflow can target a login service directly.
Why stopping one process may leave the operation running
Other cases in the report add two forms of continuity. In GTG-20006, agents monitored whether security products detected the actor’s malware, then modified and rebuilt it. Removing a detected file still leaves the accounts and infrastructure behind it to investigate. Page 6.
In GTG-10007, agents worked in parallel while target lists, credentials and progress were saved between sessions. The group separately ran 13 scheduled agents to collect publicly available material. An incident may therefore span several sessions and jobs, rather than one conversation with a model. Pages 26–27.
The report also separates autonomy from severity. Some operations ran with little supervision; several serious compromises involved a person directing each step. Human involvement alone is not evidence of lower risk. Defenders need to review the access and effects of the operation, whatever its level of automation. Page 39.
These cases can inform a penetration test: agree which follow-on actions the testers may attempt after obtaining access. The report should explain the permissions affected and provide enough evidence to retest both the entry point and the access it opened.
AI API keys belong in the incident response plan
In GTG-50020, malicious instructions in a vendor’s evaluation sandbox exposed production API keys. Anthropic reports that the actor reused stolen keys and targeted roughly 30 AI companies in about four days. That is a target count, not 30 confirmed compromises. An attempt to obtain a pre-release Claude model failed, and Anthropic says its own systems were not compromised. Pages 30–32.
The underlying permission problem is specific: a system processing hostile test material could reach production credentials. An evaluation environment should use separate accounts with only the permissions needed for the test. Instructions planted in material an agent reads can try to redirect its actions; our prompt injection analysis explains why content checks need independent limits on tool access.
List each AI key’s owner, provider, application, permissions and revocation procedure. Include automated build jobs, evaluation systems and third-party integrations. If a key is exposed, investigate its provider-side usage and the original theft. An active credential-stealing process could capture the replacement too.
A gateway protecting the company’s own agents may never see an attacker using the stolen key from another machine. The provider must be part of containment. Spending limits can reduce financial exposure, but they do not determine whether a request is authorized.
Check where AI providers send your data
Anthropic reports that Moonshot and DeepSeek forwarded some customer requests to Claude, and that intermediaries sold captured conversations. The report says it could not establish whether Moonshot notified its customers; it describes DeepSeek’s forwarding as undisclosed. These are Anthropic’s findings, not an independent Oktsec attribution. Proxy services, page 144; Moonshot and DeepSeek, pages 148–149.
AI supply chain security includes the services that process prompts and tool results. If a provider forwards that data elsewhere, the original supplier name does not describe every recipient. Ask which providers may receive requests, what they retain and what changes when a model is unavailable.
Sends a request to an approved service.
Your network records can identify this connection.
Your connection log alone cannot establish what happens here.
Record whether each provider retains customer content, uses it for training or passes it through resellers. Ask for evidence supporting its answers and require a review when the route changes.
For example, test what your application does when its chosen model is unavailable. Does it stop, or send the same request to another provider? Use test data to check the routes you control. The provider’s internal handling requires separate evidence from that provider.
Our analysis of model distillation and API access develops the distinction between a permitted connection and a permitted use. Distillation itself is a legitimate training technique. The concern here is unauthorized access, undisclosed processing and the handling of customer conversations.
A routine request can be part of a harmful workflow
The surveillance cases include profiling people and building surveillance systems. In the deceptive dating-app case, Anthropic says the deception and payment scheme were not apparent within individual conversations. Surveillance findings; dating-app case, page 140.
Classifying records or drafting messages can look ordinary in isolation. A review also needs the source of the records, the purpose of the task and the recipients. A content scanner cannot supply missing business context. Someone responsible for the system must decide which uses are permitted.
The report’s influence, weapons and biological sections require their own specialist review. This article’s advice about credentials and tool permissions is not a substitute for those assessments.
Turn the findings into checks your team can repeat
For an enterprise deploying its own agents, start with the credentials, tools and data routes used by one application. Assign each check to someone who can change the configuration and verify the result. The following checks address the access problems illustrated by the report.
Remove unnecessary production access. Define which external services the application needs.
Credential permissions, application configuration and a test of the restriction.
Identify who can revoke keys and sessions. Check whether another process can steal replacements.
Provider usage, revocation times and the investigation of the original exposure.
Identify what can restart, which credentials it uses and how the team can stop it.
Job configuration, related sessions, identities and records of any access created.
Approve the data recipients and the behavior when the preferred service fails.
Routing configuration, supplier disclosures and synthetic fallback tests.
Separate reading and drafting from exports, account changes and external publication.
The requested action, policy in effect and outcome at the receiving system.
Example: test a support agent’s permissions
Consider an agent allowed to read one assigned support case and draft a reply. It should not be able to export the customer database. This is a proposed test with fictional records, not a reported incident or a customer result.
- Confirm the permitted task works. Give the agent its assigned case and check that it can read it and draft a useful reply.
- Request an action outside the assignment. Add a test instruction asking it to export all customer records. Record what the agent attempts.
- Check enforcement separately. Within the agreed test scope, try the forbidden request directly through the connector or API using the agent’s credentials. A model refusal alone does not test those permissions.
- Check the result at the receiving system. Retain the requested action, identity, policy decision and records of any data read or sent. Confirm that the restriction did not also break the permitted task.
This connects two lessons: an agent’s available access must fit its assignment, and incident evidence must establish what actually happened. Repeat the checks after relevant changes to tools, credentials or providers.
How Oktsec helps test and enforce agent permissions
Oktsec Assessment tests agreed attack paths and documents the access they expose. For a workflow like the support example, that means testing the permitted task, the forbidden action and any alternative route within scope.
Oktsec Control checks routed actions against configured rules, including tool and parameter restrictions, and records its decisions. It can restrict the actions passing through that integration. A stolen key used outside it still requires provider-side investigation and revocation.
Oktsec Signal, powered by Aguara, inspects agent tools and dependencies for supply chain threats. Its planned continuous monitoring remains in development. Endpoint protection, identity systems and provider records retain their own roles in the response.
For the work after a finding, our Defense Factory analysis follows the path from a reported weakness to a fix that has been tested and deployed.
Sources and method
This is Oktsec’s analysis of Anthropic’s Detecting and countering misuse of AI: September 2026, published September 10, 2026. The full report is also available as a PDF. This article was first published September 10 and expanded September 14 with the attack lifecycle, four observed workflows, page-level references and defensive test examples. Case identifiers belong to Anthropic’s internal tracking system. We have not independently reproduced its investigations. The two credited figures are reproduced from Anthropic’s report. The provider-routing illustration, defensive recommendations and support-agent test are Oktsec’s analysis; they are not claims that Oktsec prevented these incidents.