{"slug": "amazon-madpot-decoys-caught-artex-ai-hacking-agents-handing-over-their-own", "title": "Amazon MadPot Decoys Caught ARTEX AI Hacking Agents Handing Over Their Own Memory", "summary": "Amazon Threat Intelligence reported on November 13, 2026 that its MadPot decoy network, which imitates popular LLM chat-completions APIs, captured requests from ARTEX-based AI hacking agents between October 3 and November 5, 2026, and that those requests carried the agents' own operational memory, including persistent task context, system prompts, tool histories and knowledge-graph state. Amazon assessed with moderate confidence that disparate Chinese-nexus groups ran the campaigns on ARTEX, an open-source agentic penetration-testing framework, and described a stolen-key loop in which agents stole AI model credentials and used those keys to pay for the inference powering further credential hunting; a second campaign attempted to beat identity checks at two cryptocurrency exchanges using deepfakes. Amazon said it could not verify the outcomes the agents reported, that no deepfake passed KYC in any recorded attempt, and that none of the techniques were new, publishing indicators of compromise for organizations it could not confirm were affected.", "body_md": "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](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-observes-threat-actors-running-cybercrime-campaigns-with-artex-ai-agents/?ref=explainx) describes as campaigns run on ARTEX, an open-source agentic AI penetration-testing framework.\n\nThe 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.\n\nThis 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](https://explainx.ai/blog/microsoft-storm-3358-cambodia-artex-financial-sector-november-2026) and [Cloudflare's write-up of ARTEX pentest orchestrators](https://explainx.ai/blog/cloudflare-modern-security-model-artex-pentest-orchestrators-2026).\n\n## TL;DR: what is confirmed and what is not\n\n| Question | Answer | \n|---|---|\n| What was the source? | Requests sent to Amazon MadPot decoys that imitated LLM chat-completions APIs | \n| When? | October 3 to November 5, 2026 | \n| Which tool? | ARTEX, assessed with moderate confidence | \n| Who? | Disparate Chinese-nexus groups, assessed with moderate confidence | \n| Did the attacks work? | Unknown. Amazon could not verify the agents' reported outcomes | \n| Did the deepfakes pass KYC? | Not in any recorded attempt, per Amazon | \n| Anything new technically? | No. Amazon says none of the techniques were new | \n\nAgents that act on your behalf need rules. [See how explainx helps secure your agents →](https://explainx.ai/agentbeam?src=blog_note)\n\n## How did a decoy end up with the attackers' memory?\n\nMadPot 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.\n\nThe 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.\n\nAmazon 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.\n\nThis 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.\n\n## What is ARTEX and how were the agents organized?\n\nAmazon 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.\n\nOperators 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:\n\n- work through a fixed sequence of countries;\n- prioritize enterprise production sites over personal projects;\n- grade every credential by whether it worked and what it could reach;\n- treat credentials exposed publicly for more than 30 days as low-value inventory.\n\nAmazon 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.\n\nMicrosoft has published related work on ARTEX. Our post on [Storm-0940 and the ConnectWise cloud backup attack](https://explainx.ai/blog/microsoft-storm-0940-artex-connectwise-cloud-backup-attack-claimed-vs-verified-what-to-do-2026) shows the same pattern: a public framework in the hands of several different operators.\n\n## Campaign 1: a self-funding loop of stolen AI keys\n\nLeaked API key concept for the ARTEX stolen LLM API keys campaign\n\nThe 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.\n\nThe agents focused on software that aggregates provider keys, because one weak management interface can expose many downstream accounts. Amazon names these targets:\n\n| Type | Named products | \n|---|---|\n| LLM gateways and proxies | One API, New API, Veloera, Sub2API, LiteLLM | \n| AI app builders | Dify, FastGPT, Langflow, RAGFlow, Open WebUI, LobeChat, Ollama | \n\nA codified playbook mapped each fingerprinted product to a known attack chain. Amazon lists these weaknesses:\n\n- uninitialized installs that an attacker could claim;\n- anonymous management and provider-configuration endpoints;\n- default administrator credentials, including the LiteLLM default master key;\n- CVE-2025-3248 in Langflow and CVE-2026-28797 in RAGFlow;\n- an authentication bypass through the isCliRequest header in One API family systems;\n- server-side request forgery (SSRF) through URL-fetch features to reach cloud metadata services;\n- secrets left in client-side JavaScript, source maps, debug routes and environment files.\n\nFor 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.\n\nCloud 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.\n\nWhy 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](https://explainx.ai/blog/cursor-fireworks-security-incident-agent-traces-november-2026) shows how exposed agent traces and keys turn into a wider problem.\n\n## Campaign 2: deepfakes against crypto exchange KYC\n\nDeepfake mask reveal showing a deepfake KYC bypass attempt\n\nThe 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.\n\nOn 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.\n\nIn 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.\n\nOn 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.\n\nAt 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](https://explainx.ai/blog/fbi-facestealer-north-korea-400m-deepfake-crypto-theft-doj-2026).\n\n## What is claimed versus verified\n\n| Claim | Source | Status | \n|---|---|---|\n| Decoys received ARTEX agent requests with campaign memory | Amazon | Directly observed by Amazon | \n| Agents stole and pooled AI keys | Agent records | Not verified by Amazon | \n| Agents reached cloud storage or secrets | Agent records | Not verified by Amazon | \n| Deepfakes passed KYC | None | Contradicted: every recorded attempt failed server-side | \n| Operators are Chinese-nexus | Amazon | Moderate confidence | \n| ARTEX was the framework | Amazon | Moderate confidence | \n\nThe 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.\n\nA secondary write-up from [GBHackers](https://gbhackers.com/hackers-llm-api-keys-artex-ai-agents/?ref=explainx) 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.\n\n## Why this matters beyond one report\n\nAmazon 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.\n\nWhat 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.\n\nThere 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](https://explainx.ai/blog/black-october-internet-under-attack-protect-yourself-family-saas-drying-up-2026).\n\nEarlier this year, [DeepSeek-linked state hackers](https://explainx.ai/blog/deepseek-chinese-state-hackers-cyber-attacks-august-2026) 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](https://explainx.ai/felony-bench).\n\n## How to protect yourself\n\nAmazon's own advice is plain: get the fundamentals right. A practical checklist for teams that run AI gateways or app builders:\n\n1. **Remove defaults.** Change the LiteLLM master key and any default admin account. Initialize every install before it faces the internet.\n2. **Patch.** Update Langflow past CVE-2025-3248 and RAGFlow past CVE-2026-28797, and apply fixes for One API family bypasses.\n3. **Lock down management endpoints.** Put admin and provider-configuration routes behind authentication and a private network.\n4. **Rotate keys.** Treat any provider key that appeared in a repository, package, image layer, notebook or paste site as burned.\n5. **Block metadata SSRF.** Enforce IMDSv2 on cloud hosts and filter URL-fetch features.\n6. **Watch spend.** Alert on unexpected model usage, new models, or new regions on your provider accounts.\n7. **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.\n\nTo detect or block agent-driven abuse of your own agents, see the [AgentBeam write-up on the same MadPot findings](https://agentbeam.com/blog/amazon-madpot-artex-agent-memory-decoy-llm-api?ref=explainx). It covers how an agent security layer can stop dangerous actions before they run.\n\nOur guide to [Tailscale's Tailworm SSH flaws and AI agents](https://explainx.ai/blog/tailscale-tailworm-ssh-flaws-ai-agents-builders-what-to-do-2026) has more builder-side advice on locking down agent access.\n\n## What to watch next\n\nAmazon 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.\n\n*Facts in this post are accurate as of November 14, 2026. Amazon's findings come from its own report and may be revised.*", "url": "https://wpnews.pro/news/amazon-madpot-decoys-caught-artex-ai-hacking-agents-handing-over-their-own", "canonical_source": "https://explainx.ai/blog/amazon-madpot-artex-agent-memory-decoy-llm-api-2026?utm_source=rss&utm_medium=feed&utm_campaign=blog", "published_at": "2026-11-14 00:00:00+00:00", "updated_at": "2026-11-14 23:52:01.208996+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "artificial-intelligence"], "entities": ["Amazon", "Amazon Threat Intelligence", "MadPot", "ARTEX", "Microsoft", "Storm-3358", "Cloudflare"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/amazon-madpot-decoys-caught-artex-ai-hacking-agents-handing-over-their-own", "markdown": "https://wpnews.pro/news/amazon-madpot-decoys-caught-artex-ai-hacking-agents-handing-over-their-own.md", "text": "https://wpnews.pro/news/amazon-madpot-decoys-caught-artex-ai-hacking-agents-handing-over-their-own.txt", "jsonld": "https://wpnews.pro/news/amazon-madpot-decoys-caught-artex-ai-hacking-agents-handing-over-their-own.jsonld"}}