Amazon MadPot Decoy LLM APIs Capture ARTEX Agent Memory: Key Theft and Deepfake KYC Bypass

On November 13, 2026, Amazon Threat Intelligence published a rare view from inside an agentic attack: its MadPot decoy network, configured to look like popular LLM inference APIs, received requests from ARTEX agents that carried the agents' own operating memory. Between October 3 and November 5, the agents treated the decoys as model backends and sent along their task context, system prompts, tool histories, knowledge-graph state and findings. Amazon's report describes two campaigns: a self-funding theft of AI provider keys, and attempts to defeat identity checks at two cryptocurrency exchanges with real-time deepfakes. If you self-host an LLM gateway, an AI app builder or Ollama, or you keep provider keys near coding agents, this is a concrete list of what the attackers went after. Amazon is explicit that none of the techniques were new.

TL;DR

What Amazon's decoys actually saw

MadPot is, in Amazon's words, a globally distributed network of decoy threat sensors. It presents controlled services and records how attackers discover, test and abuse them. In this case the sensors exposed LLM-compatible chat-completions interfaces on various ports. ARTEX, an open-source agentic penetration-testing framework, treated them as inference backends and sent its prompts there.

That matters because agent frameworks keep history. Each request to an LLM usually contains the persistent task context and what happened so far, so a single captured request can hold the operational history of an entire campaign. Amazon writes that this history described activity on systems MadPot does not monitor. The company did not observe those actions as they happened and says it cannot verify the outcomes the agents reported. What the records reliably show is what the operators were pursuing and how the framework was organized.

The records show planner, worker, verification and compression agents sharing a persistent knowledge graph, which acts as the operation's shared memory: every agent reads from it and writes results back, so each picks up where another left off. Operators steered this with standing instruction prompts that set mission objectives, targeting rules and constraints. One set of instructions told agents to work through a fixed sequence of countries, prioritize enterprise production sites over personal projects, and grade every stolen credential. Others set red lines (no mainland China targets, no government domains) and required all outbound traffic to go through proxies.

For background on the framework itself, see Beam's coverage of the FBI FLASH on ARTEX and Unit 42's behavioral hallmarks of ARTEX-class agents.

Campaign 1: stealing AI credentials, paid for by stolen credentials

The most prominent campaign targeted keys that grant access to AI models, most likely so the operators could use models someone else pays for. Amazon's reading of the records is that stolen keys were fed into the framework's own model gateway, where they powered the agents that searched for more keys. Hence "self-sustaining".

The shared method

Agents used different gateways, keys and models, but followed one method: find internet-exposed AI applications, extract the upstream provider keys they hold, validate those keys, and store them in a managed pool. They favored applications that aggregate provider keys, because one weak management interface can expose many downstream accounts.

Amazon lists these targets:

• LLM gateways and proxies: One API, New API, Veloera, Sub2API and LiteLLM.
• AI application builders: Dify, FastGPT, Langflow, RAGFlow, Open WebUI, LobeChat and Ollama.

The vulnerability playbook

A codified playbook mapped each fingerprinted product to its known attack chain:

1. Uninitialized installs that could simply be claimed.
2. Anonymous management and provider-configuration endpoints.
3. Default administrator credentials, including the LiteLLM default master key.
4. Known CVEs: CVE-2025-3248 in Langflow and CVE-2026-28797 in RAGFlow.
5. An authentication bypass through the isCliRequest header in One API family systems.
6. SSRF through URL-fetch features to reach cloud metadata services.
7. Secrets left in client-side JavaScript, source maps, debug routes and environment files.

You can check Langflow's other advisories on its CVE tool page.

Where the keys were found

Discovery drew on internet scanning services, certificate transparency and public code and artifact sources: GitHub repositories and event archives (targeting secrets that fell outside automated revocation), npm and PyPI tarballs, container image layers, notebooks, model-hosting spaces, paste sites and Telegram channels. One operation graded each credential: L1 for a lead, L2 for a confirmed working API call, and L3 for quantified impact, such as readable data or a spendable balance. Keys exposed publicly for more than 30 days were treated as low-value inventory, which tells you how fast attackers expect defenders and scanners to revoke leaked keys.

Validated identities were then pushed further: the agents enumerated storage, assessed permission scope, and went after managed AI model services, secrets and parameter stores and application identities. They prioritized premium frontier-model access over general cloud permissions.

This lines up with earlier reporting on stolen-key economies: Google's GTIG work on LLM mixers and LiteLLM and Wiz's Black October look at stolen keys on developer platforms. What Amazon adds is the agent-side view of the same pipeline.

Campaign 2: deepfakes against crypto exchange KYC

A second set of records describes agents trying to pass know-your-customer checks at two cryptocurrency exchanges using real-time deepfake video for live selfie checks and forged ID photos for document checks. This is a fraud story, not a coding-agent story, and we cover it only because it shows how the same framework runs several workstreams at once.

What the records describe:

• Liveness reverse-engineering. The agents documented one vendor's face-detection event stream, how it tracks face position and the coordinate system used to guide the user. Their best attempt completed the movement sequence within 7 pixels of the target.
• Server-side rejection. Even so, the vendor's server-side verdict rejected the deepfake in every recorded attempt.
• A consumer-GPU pipeline. A separate session built a real-time deepfake pipeline on one consumer-grade GPU with an open-source face animation model, reaching 11.5 frames per second by splitting the model and avoiding unnecessary memory copies.
• Document forgery. Agents recorded building synthetic camera metadata whose dimensions matched the JPEG's real values and preserving original compression tables, so an edited image looks like an untouched camera photo at the file level.
• Parallel sessions. At least four sessions ran at once (cash-out routes, clearing balances, the deepfake pipeline, the bypass) and handed work to one another through cross-session tools.

Amazon's own conclusion is that agentic frameworks have moved from experimental use to sustained, multi-objective offensive operations with minimal human intervention.

What is verified and what is not

Amazon published IPv4 indicators for both campaigns, with first and last seen dates between October 14 and November 2. The report notes that agent-reported outcomes are not independently verified, so treat the IOCs as hunting leads rather than proof of compromise.

What this means if you run AI coding agents

Your local coding agent is not the target here. Your secrets and your self-hosted AI infrastructure are. Three groups of readers should act:

You self-host an LLM gateway or AI builder.

• Check litellm --version, pip show langflow or your container image tags, and update to a patched release. Confirm Langflow is past CVE-2025-3248.
• Replace any default master key or admin password, and complete initialization of any fresh install immediately. An unclaimed install is a free key store.
• Put management and provider-configuration endpoints behind authentication and a network boundary, and block URL-fetch features from reaching cloud metadata (use IMDSv2 on AWS).
• Look in your proxy and gateway logs for configuration reads from unfamiliar IPs, and compare Amazon's IOC list against them.

You hold provider keys.

• Rotate any key that ever appeared in a repository, published package, image layer, notebook, paste or chat. Amazon says attackers specifically target secrets that fell outside automated revocation, so do not rely on the provider's scanner alone.
• Set per-key budgets and alerts. Amazon recommends watching for unexpected spend or unusual usage of AI services.
• Check .env files, source maps and debug routes in anything you deploy. Coding agents routinely copy keys into example configs; see how API keys leak through logs and environment variables.

You run agents that call LLM endpoints.

• Pin your agent's model base URL. The ARTEX agents sent their full history to whatever endpoint spoke the chat-completions protocol. An agent pointed at an untrusted or typo'd endpoint would hand over the same material: prompts, tool output, file contents.

For related field data on the same lineage, read Censys on exposed ARTEX consoles, CrowdStrike on Vapor Panda, and Arctic Wolf on AntiFox, an ARTEX fork.

A defender's note on decoys

The report doubles as an argument for cheap deception. A fake model endpoint costs little, and attackers who rely on an LLM backend will send it their entire context. The same property makes any LLM endpoint you do not control a data leak: whoever runs the endpoint sees the agent's memory. That cuts in both directions, which is why Amazon's measured language ("moderate confidence", "cannot verify") is worth copying when you read agent-generated reports of your own incidents.

What Beam can and cannot do here

Beam runs on your developer machine and watches local coding agents. It does not monitor your LLM gateway, your cloud account or exchange KYC flows, and it cannot stop an attacker's agent running on someone else's server.

Where it helps is upstream: flagging when an agent reads or prints a credential, redacting known credential formats before events are stored locally, and scanning skills and MCP configs (heuristic patterns plus a version-pin check) before you run them. On Claude Code and Codex, a PreToolUse hook can deny a flagged action. That is hook-based, not a kernel sandbox, and it fails open if no cached policy is available. See what Beam watches and how it stays local.

Frequently asked questions

What did Amazon Threat Intelligence publish on November 13, 2026?

A report on ARTEX AI agents whose requests reached MadPot decoy sensors posing as LLM inference APIs between October 3 and November 5, 2026. The requests carried the agents' own records of their campaigns, including task context, system prompts, tool histories and knowledge-graph state.

Which products did the ARTEX agents target to steal AI keys?

Amazon lists LLM gateways and proxy platforms such as One API, New API, Veloera, Sub2API and LiteLLM, and AI application builders such as Dify, FastGPT, Langflow, RAGFlow, Open WebUI, LobeChat and Ollama. The playbook used default credentials, unauthenticated admin endpoints, known CVEs, SSRF to cloud metadata and secrets left in client-side files.

Did the deepfake attempts against crypto exchanges succeed?

According to the agents' own records, no. The vendor's server-side verdict rejected the deepfake in every recorded attempt. Amazon notes it cannot independently verify outcomes the agents reported.

How confident is Amazon in the attribution?

Moderate confidence on both points: that ARTEX was used (prompt references and artifacts) and that the actors are disparate Chinese-nexus groups (simplified Chinese prompts, China time-zone configuration, targeting and tooling).

Were any new vulnerabilities involved?

No. Amazon says none of the techniques were new. The agents succeeded where basics were missing: default or hardcoded credentials, keys in code and public artifacts, unauthenticated interfaces and unpatched software.

What should I check first if I self-host an LLM gateway?

Change default master keys, put the admin interface behind authentication and a network boundary, patch the gateway and its builders, rotate any provider key that was ever exposed, and alert on unexpected model spend or unusual usage.

Related reading

• FBI FLASH on the ARTEX framework
• Unit 42: ARTEX behavioral hallmarks
• Google and Mandiant: five defense layers against agentic offensive frameworks
• Anatomy of an AI-driven cloud attack (Wiz CIRT)
• November 2026 attacks timeline

Primary sources: Amazon Threat Intelligence, AWS Security Blog (2026-11-13) · BleepingComputer on AntiFox (2026-11-11)

Details reflect Amazon's November 13, 2026 report and may change if Amazon updates its indicators or attribution.