Amazon Threat Intelligence published an unusual report on November 13, 2026. Its MadPot decoy network, built to look like popular large language model (LLM) APIs, received requests from AI hacking agents. Those requests carried the agents' own operating memory. Between October 3 and November 5, the decoys recorded what Amazon's security blog describes as campaigns run on ARTEX, an open-source agentic AI penetration-testing framework.
The main finding is a stolen-key loop. Agents stole credentials for AI models, then used those keys to pay for the inference that powered further credential hunting. A second campaign tried to beat identity checks at two cryptocurrency exchanges using deepfakes. Amazon stresses that it could not verify the outcomes the agents reported.
This post covers what Amazon observed, what it only read in agent records, and what to fix this week. It builds on our earlier coverage of ARTEX misuse, including Microsoft's Storm-3358 report on a Cambodia-linked group and Cloudflare's write-up of ARTEX pentest orchestrators.
TL;DR: what is confirmed and what is not #
| Question | Answer |
|---|---|
| What was the source? | Requests sent to Amazon MadPot decoys that imitated LLM chat-completions APIs |
| When? | October 3 to November 5, 2026 |
| Which tool? | ARTEX, assessed with moderate confidence |
| Who? | Disparate Chinese-nexus groups, assessed with moderate confidence |
| Did the attacks work? | Unknown. Amazon could not verify the agents' reported outcomes |
| Did the deepfakes pass KYC? | Not in any recorded attempt, per Amazon |
| Anything new technically? | No. Amazon says none of the techniques were new |
Agents that act on your behalf need rules. See how explainx helps secure your agents →
How did a decoy end up with the attackers' memory? #
MadPot is a globally distributed network of decoy sensors. It presents controlled services to attackers and records how they find, test and abuse them. In this case the sensors exposed LLM-compatible chat-completions interfaces on various ports.
The ARTEX agents treated these interfaces as ordinary model backends. An agent framework sends its working context to the model on every step, so each request is a snapshot of the operation.
Amazon lists what the telemetry contained: persistent task context, system prompts, tool histories, knowledge-graph state and reported findings. Because agent frameworks retain past conversation, a single request often held the full operational history of a campaign. That history covered activity on systems MadPot does not monitor.
This is the key limit. Amazon read what the agents said they did. It did not watch the intrusions. It says it assessed activity that referenced potentially affected AWS customers and notified them as appropriate. For other organizations it could not confirm activity, so it published indicators of compromise (IOCs) instead.
What is ARTEX and how were the agents organized? #
Amazon describes ARTEX as an open-source agentic framework for penetration testing. Most of the observed activity split work among planner, worker, verification and compression agents. They shared a persistent knowledge graph that served as the operation's shared memory. Every agent read from it and wrote results back, so each could pick up where another stopped.
Operators steered the agents with standing instruction prompts. The prompts set mission goals, targeting rules and constraints. In one credential-theft campaign, operators told the agents to:
- work through a fixed sequence of countries;
- prioritize enterprise production sites over personal projects;
- grade every credential by whether it worked and what it could reach;
- treat credentials exposed publicly for more than 30 days as low-value inventory.
Amazon says the instructions also set red lines, such as excluding mainland China targets and government domains, and required outbound traffic to go through proxies. Those details, plus simplified Chinese prompts and China time-zone configuration, drive the moderate-confidence Chinese-nexus attribution.
Microsoft has published related work on ARTEX. Our post on Storm-0940 and the ConnectWise cloud backup attack shows the same pattern: a public framework in the hands of several different operators.
Campaign 1: a self-funding loop of stolen AI keys #
Leaked API key concept for the ARTEX stolen LLM API keys campaign
The most prominent campaign targeted keys that grant access to AI models. Amazon says the likely goal was to use models that someone else pays for. The agents' records show stolen keys fed into the framework's own model gateway. Those keys then powered the agents that searched for more keys.
The agents focused on software that aggregates provider keys, because one weak management interface can expose many downstream accounts. Amazon names these targets:
| Type | Named products |
|---|---|
| LLM gateways and proxies | One API, New API, Veloera, Sub2API, LiteLLM |
| AI app builders | Dify, FastGPT, Langflow, RAGFlow, Open WebUI, LobeChat, Ollama |
A codified playbook mapped each fingerprinted product to a known attack chain. Amazon lists these weaknesses:
- uninitialized installs that an attacker could claim;
- anonymous management and provider-configuration endpoints;
- default administrator credentials, including the LiteLLM default master key;
- CVE-2025-3248 in Langflow and CVE-2026-28797 in RAGFlow;
- an authentication bypass through the isCliRequest header in One API family systems;
- server-side request forgery (SSRF) through URL-fetch features to reach cloud metadata services;
- secrets left in client-side JavaScript, source maps, debug routes and environment files.
For discovery, the agents used internet scanning services, certificate transparency, GitHub repositories and event archives, npm and PyPI tarballs, container image layers, notebooks, model-hosting spaces, paste sites and Telegram channels. One operation graded each credential as L1 for a lead, L2 for a confirmed working API call, and L3 for quantified impact such as readable data or spendable balance. Cloud credentials were treated as a doorway. Agents validated identities through each provider's token services, enumerated storage, assessed permission scope, and went after managed AI model services, secrets stores and application identities. They prioritized access to premium frontier models over general cloud permissions.
Why the loop matters: the operators do not need to buy inference. Victims fund the attacker's own tooling. That makes unexpected model spend a real detection signal, as Amazon notes. Our earlier look at Cursor's Fireworks security incident shows how exposed agent traces and keys turn into a wider problem.
Campaign 2: deepfakes against crypto exchange KYC #
Deepfake mask reveal showing a deepfake KYC bypass attempt
The second campaign tried to defeat know-your-customer (KYC) identity checks at two cryptocurrency exchanges. The records describe real-time deepfake video for live selfie checks and forged ID photos for document checks. This post reports the technique only as Amazon describes it, at a high level.
On the liveness check, the agents reverse-engineered one vendor's protocol. They documented the face-detection event stream and the coordinate system that tells users where to move. Their best recorded attempt completed the movement sequence with the face within 7 pixels of the target. Even so, the vendor's server-side verdict rejected the deepfake in every recorded attempt.
In parallel, one session built a real-time deepfake pipeline on a single consumer-grade GPU using an open-source face animation model. By splitting the model and avoiding unnecessary memory copies, it reached 11.5 frames per second, close to what a live check expects.
On documents, the agents recorded building synthetic camera metadata and keeping original compression tables, so an edited image looks like an untouched camera photo at the file level.
At least four agent sessions ran at once on this goal. One searched for cash-out routes, one worked on clearing account balances, one built the deepfake pipeline, and one ran the bypass. They shared findings through cross-session tools. For the wider fraud picture, see our report on the FBI's FaceStealer case.
What is claimed versus verified #
| Claim | Source | Status |
|---|---|---|
| Decoys received ARTEX agent requests with campaign memory | Amazon | Directly observed by Amazon |
| Agents stole and pooled AI keys | Agent records | Not verified by Amazon |
| Agents reached cloud storage or secrets | Agent records | Not verified by Amazon |
| Deepfakes passed KYC | None | Contradicted: every recorded attempt failed server-side |
| Operators are Chinese-nexus | Amazon | Moderate confidence |
| ARTEX was the framework | Amazon | Moderate confidence |
The agents also grade their own work. An L3 label is the agent's judgment, not an audited impact. Treat the scale numbers in the records as intent and claims. Amazon's own conclusion is more careful: agentic frameworks have moved from experimental use to sustained, multi-objective operations that run with minimal human intervention, based on the agents' own descriptions.
A secondary write-up from GBHackers repeats the same dates, targets and caveats, and calls the key loop "self-sustaining". Use Amazon's wording as the reference for what was observed.
Why this matters beyond one report #
Amazon says none of the techniques were new. The agents succeeded where basic hygiene was missing: default or hardcoded credentials, keys left in code and public artifacts, unauthenticated interfaces and inference endpoints, and unpatched software.
What changes is speed and persistence. An agent does not tire, and a knowledge graph means findings are not lost between sessions. Amazon advises defenders to assume exposed secrets and misconfigurations will be found quickly.
There is also a lesson for anyone building agents. The agents leaked their own history to any endpoint that spoke the chat-completions protocol. A decoy got the full playbook, including system prompts and tool logs. Any agent you run sends the same kind of data to its model provider, so treat the model endpoint as part of your trust boundary. For a wider look at how fast the offense side is moving, read Black October and the internet under attack.
Earlier this year, DeepSeek-linked state hackers were also reported using AI models in attacks. Together these reports show a steady move from AI as a helper to AI as the operator. We track agents that act against real third parties in our felony-bench tracker.
How to protect yourself #
Amazon's own advice is plain: get the fundamentals right. A practical checklist for teams that run AI gateways or app builders:
- Remove defaults. Change the LiteLLM master key and any default admin account. Initialize every install before it faces the internet.
- Patch. Update Langflow past CVE-2025-3248 and RAGFlow past CVE-2026-28797, and apply fixes for One API family bypasses.
- Lock down management endpoints. Put admin and provider-configuration routes behind authentication and a private network.
- Rotate keys. Treat any provider key that appeared in a repository, package, image layer, notebook or paste site as burned.
- Block metadata SSRF. Enforce IMDSv2 on cloud hosts and filter URL-fetch features.
- Watch spend. Alert on unexpected model usage, new models, or new regions on your provider accounts.
- Check the IOCs. Search authentication, application and cloud audit logs for Amazon's published IP addresses, such as 104.28.225[.]223 for Campaign 1 and 212.107.28[.]51 for Campaign 2.
To detect or block agent-driven abuse of your own agents, see the AgentBeam write-up on the same MadPot findings. It covers how an agent security layer can stop dangerous actions before they run.
Our guide to Tailscale's Tailworm SSH flaws and AI agents has more builder-side advice on locking down agent access.
What to watch next #
Amazon says it notified affected AWS customers where it could. It has not named victims, and it has not said how many keys or accounts were truly compromised. Those numbers would turn the agents' claims into facts. Watch for follow-up reports from LLM gateway maintainers and from the exchanges involved. Also watch whether ARTEX maintainers change the framework after the disclosure.
Facts in this post are accurate as of November 14, 2026. Amazon's findings come from its own report and may be revised.