An attacker steals an AI API key from a company’s application. That key can pay for the next intrusion, give the activity a legitimate account to hide behind and remain useful long after the original application is repaired. For the company, the incident now reaches beyond the data that first went missing.
This is one of the most consequential patterns in Anthropic’s September 2026 threat intelligence report. The report describes malicious operators using AI to sustain operations across targets, tools and providers. Our reading at Oktsec focuses on the access that makes those operations possible and the evidence defenders need to interrupt them.
Read the scope before the headlines
The report covers selected operations disrupted between December 2025 and August 2026 across seven areas: cyber operations, surveillance, influence operations, conventional weapons, biological misuse, scams and fraud, and illicit distillation. Anthropic describes these as notable cases, not a representative sample of misuse. The findings and actor attributions come from its own investigations.
That distinction matters. The cases support a review of concrete attack paths. They do not establish how often every enterprise will face those paths, how much of all cybercrime uses AI, or whether a particular product would have stopped an operation.
This is also a different story from the cybersecurity evaluation incidents we examined previously. Here, malicious operators deliberately pursued harmful objectives. An enterprise must account for both threats: its own agent exceeding its assignment and an attacker using agents against it. Restricting the first does not automatically contain the second.
The operation can keep running
Anthropic describes GTG-20006 using agents to revise malware when security tools detected it. Other cases involve parallel intrusion workflows and scheduled collection. Human involvement varies across operations; the report does not describe a single uniform level of autonomy. See the report’s autonomy analysis.
For defenders, the practical question is what remains available after the first alert. A detected file might be only one part of an operation that still holds a valid token, an active session or a scheduled job. Removing the file leaves those other paths to be investigated. A containment plan should identify which access to revoke, which execution to stop and which destinations to check.
This changes how we would scope a penetration test. A finding should explain what an attacker can do next with the access obtained, within the agreed testing boundaries. Retesting should check the original weakness and any affected permissions or sessions. Closing the first entry point is useful; whether it also ends the attacker’s access is a separate result.
AI credentials belong in the incident plan
In GTG-50020, Anthropic reports that malicious instructions in a vendor’s evaluation sandbox exposed production API keys. The actor reused stolen keys and subsequently targeted roughly 30 AI companies in about four days. Those are targets, not 30 confirmed compromises. Its attempt to obtain a pre-release Claude model failed, and Anthropic says its own systems were not compromised. Read the case.
The deployment question is why a workload processing adversarial material could expose production access. Evaluation environments need credentials for legitimate reasons, but a process that handles untrusted input should receive only the access required for that test. Separate evaluation accounts, restricted permissions and an independent way to revoke access make a failed boundary easier to contain.
- Entry pointUntrusted input
A workload processes material from outside its trust boundary.
- Access at riskProduction credential
The runtime can reach a key it should not be able to disclose.
- Follow-on useAttacker workload
The stolen key gives a separate process access to the provider.
Restrict the original runtime, then revoke the exposed access and investigate its use at the provider.
Build a credential inventory that an incident responder can use: owner, provider, application, permissions, storage location and revocation procedure. Include keys held by CI jobs, evaluation runners and third-party integrations. Separate credentials by workload so that disabling one does not require taking every AI application offline.
Once a key is suspected of exposure, investigate the account’s usage and preserve the available records while containing access. Replacing the key without removing a credential harvester could expose the replacement too. Usage budgets and anomaly alerts can help surface abuse, but they do not establish that a particular request was authorized.
A gateway protecting the company’s own agent does not necessarily see an attacker using that stolen key from another machine. Provider-side revocation and account investigation remain essential. This is a concrete limit to include in any claim about runtime protection.
The provider name does not describe the whole route
Anthropic also alleges that Moonshot and DeepSeek relayed some customer requests to Claude without notifying those customers, and describes intermediaries selling captured conversations. These are Anthropic’s reported findings, not an independent Oktsec attribution. See the distillation section.
The immediate enterprise concern is the path taken by sensitive data. A procurement record naming one supplier is incomplete if that supplier sends prompts, attachments or tool results to another processor. A routing service may be legitimate and useful; its fallback behavior, retention practices and downstream providers still need to be understood.
Sends a request to an approved service.
Your egress records can identify this connection.
Your connection log alone cannot establish what happens here.
Ask suppliers which services receive each category of data and what happens during an outage or model substitution. Record whether customer content is retained, reused for training or passed through resellers. Request evidence supporting the answers and make changes to that route part of the approval process.
Test the client-side fallback paths you control with synthetic content. If the approved endpoint is unavailable, an application should follow an explicitly approved alternative or stop with a useful error. A local test cannot establish what an external provider does internally. That requires supplier evidence and, where available, provider records.
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.
Harm can be hidden in ordinary work
The surveillance cases include AI-assisted profiling and the construction of surveillance systems. In the deceptive dating-app case, Anthropic says the fraud was not visible within an individual conversational exchange. Surveillance findings; fraud case.
A request to classify records, translate a message or write a data-processing script may look routine in isolation. Understanding its consequences can require knowing where the data came from, who the subjects are, what the output will be used for and which other systems receive it. A content scan has a useful role, but it cannot supply all of that context.
For teams building customer support, investigation or outreach agents, permission design should include the dataset and the permitted operation. Access to a support case should not imply authority to combine every customer record into a new profile. Permission to draft a reply should not automatically include bulk publication or messaging from multiple identities.
The report’s influence, weapons and biological sections also warrant review by the relevant specialists. They should not be reduced to generic prompt-injection examples. Infrastructure controls can restrict access and preserve records; determining whether a research or operational purpose is acceptable requires domain expertise and accountable human ownership.
What to review in a live deployment
Start with an agent that can read sensitive material or change a system. Trace the credentials it can reach, the tools it can call and the destinations that can receive its output. Then give the findings to the people who can change those permissions. An inventory without an owner and a decision is difficult to act on.
Remove unnecessary production access. Define which outbound requests the workload needs.
Credential scope, runtime configuration and a controlled test of the restricted path.
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.
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.
Use isolated environments and synthetic data for these tests. Establish a permitted baseline first, then vary the account, dataset or destination. Otherwise a broken integration can look like a successful security control. Include direct API access and delegated agents where they are within scope; a restricted connector is only one possible route.
Preserve evidence of the result, not just the agent’s explanation. A refusal, a denied tool request and a destination that received no data are different observations. Our incident investigation article explains how to connect them without overstating what a single log proves.
Where Oktsec fits
Oktsec’s assessment work can test these boundaries in an agreed environment. Control applies deterministic policy to actions routed through its enforcement point, including configured tool and parameter restrictions. That makes the permitted action explicit and creates a decision record for review.
Signal uses Aguara to inspect agent tooling and dependencies. The continuous ecosystem monitoring described on the Signal page is in development. A relevant advisory or report should lead to a review of the software and access the organization actually uses.
These controls complement the systems that protect endpoints, manage identities and observe network traffic. They cannot revoke a third party’s key, inspect a supplier’s hidden processing or stop an attacker’s separate infrastructure by themselves. An effective response assigns each of those responsibilities to a control and an owner.
The useful outcome from this report is a shorter path from evidence to containment. Pick one consequential workflow. Establish what it can access, test how that access can be abused and make sure the team can interrupt it. The result should be specific enough to verify again after the next tool, credential or provider change.
For the defensive workflow, read Defense Factory: from security findings to verified fixes, our analysis of OpenAI’s approach to continuous validation and remediation.
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. Case identifiers belong to Anthropic’s internal tracking system. We have not independently reproduced its investigations. Deployment recommendations and diagrams are our interpretation, not findings attributed to Anthropic or claims that Oktsec prevented these incidents.