AWS MadPot caught ARTEX agents sending their own campaign memory

An AI agent needs context to decide what to do next. If it sends that context to the wrong service, it can expose the history of its operation.

That is what makes Amazon's November 13 ARTEX report worth reading. Between October 3 and November 5, 2026, its MadPot decoy network received model requests containing agents' operational memory.

The requests reached Amazon's sensors. The earlier attacks described inside them often did not. A captured request proves what the sender submitted, not that every claimed action happened.

How a fake model service received real campaign context

MadPot presents controlled services to potential attackers and records their behavior without exposing customer workloads. Here, sensors offered interfaces that looked like popular LLM chat-completions APIs. Offensive agent systems treated them as model backends.

Their requests included system prompts, task context, tool histories, reported findings and knowledge-graph state. A knowledge graph stores linked facts, such as a target, a credential and the access that credential reportedly provides.

AWS says most of the activity used ARTEX, an open-source penetration-testing framework, with planner, worker, verification and compression agents sharing that memory. This let one agent continue another's work. It also meant a single model request could carry a campaign's history.

AWS describes receiving context through ordinary inference requests. It does not describe breaking into an agent's memory store. The report does not establish how every agent chose these endpoints.

An explanatory diagram based on AWS's report. MadPot captured the submitted context. Earlier activity described in that context needs separate evidence.

What AWS saw, and what the records claimed

The public report gives us several kinds of evidence.

AWS says it assessed references to potentially affected AWS customers and notified them as appropriate. It could not confirm activity against other organizations.

That leaves room for useful intelligence without a verified victim count. Investigators can extract targets, timestamps and techniques, then check their own records. The agent's account remains a lead until other evidence supports it.

The credential loop described in memory

The first campaign's records described stealing access to AI models, then feeding stolen keys into the framework's model gateway. Those keys reportedly paid for the inference used to hunt for more credentials.

That is a plausible self-funding loop. AWS did not independently verify every theft, working key or resulting charge described in the memory.

The records named AI gateways and application platforms, including One API, LiteLLM, Dify, Langflow and RAGFlow. They described default credentials, exposed management interfaces, unpatched flaws and secrets in public artifacts. A product appearing in the report does not mean every installation is vulnerable.

The agents also recorded grading credentials. L1 meant a lead. L2 meant a reported working API call. L3 meant reported measurable impact, such as readable data or usable balance. These were the operation's labels, not AWS verification levels.

For defenders, that grading suggests useful events to correlate. A newly exposed key followed by identity checks, model calls and unfamiliar usage deserves investigation. A scan alone says much less.

A convincing client did not mean a successful KYC bypass

The second campaign targeted identity checks at two cryptocurrency exchanges. Its records described forged document images and real-time deepfake video.

One recorded attempt completed a liveness movement sequence with the face within seven pixels of the target. Yet the vendor's server rejected every attempt recorded by the agents.

A separate session reported a deepfake pipeline running at 11.5 frames per second. That is a reported processing speed, not proof that an exchange accepted the video.

Keep the evidence boundary here too. AWS is describing the agents' records of rejection, not an independent audit of the exchange. Those records do not support a headline claiming a successful KYC bypass.

Protect credentials where agents can reach them

Start with gateways that hold several providers' keys. One exposed admin interface can put multiple accounts at risk.

Remove default credentials, restrict management access and patch internet-facing AI applications. Find secrets in repositories, container layers, build outputs and debug pages. Revoke exposed keys at the provider. Deleting a file does not disable a copied key.

For AWS workloads, IAM guidance recommends temporary credentials through roles and least-privilege permissions. For providers that require long-lived API keys, use separate keys per application, narrow their access and enforce usage limits where supported.

Watch provider usage as well as gateway logs. An attacker using a copied key elsewhere may never pass through your gateway. Check whether a spending control actually blocks requests or only sends an alert.

Keep agent logs without creating another secret store

The same context leak can affect a legitimate coding or support agent. Approve model destinations and check endpoint changes. API compatibility does not establish who operates a service.

Keep correlation IDs across model requests, tool execution and application events. Record the requested action, policy decision, tool result and independently observed outcome as separate facts.

This illustrative event is a suggested format, not captured AWS telemetry:

{
  "run_id": "example-run-42",
  "tool_call_id": "example-call-7",
  "action": "read_object",
  "policy_decision": "deny",
  "tool_executed": false,
  "credential_ref": "workload-role",
  "outcome_source": "tool-broker"
}

Keep raw tokens out of these events. OWASP's logging guidance recommends interaction identifiers, access controls and excluding or masking secrets. Protect any retained transcripts, limit retention and treat their contents as untrusted input.

Let the server decide the outcome

The KYC example gives a concrete engineering lesson. Completing a client-side sequence is not an approval.

Enforce identity and access decisions on the server. Tie verification to the current session, reject replayed results and release privileges only after a trusted verdict. For agent tools, check authorization at execution time rather than accepting the model's claim that an action is allowed.

During an investigation, match "key works" to provider records, "data read" to access logs and "identity approved" to the verification service's decision. MadPot exposed what the agents remembered and intended. Independent records are still needed to establish what they achieved.

Sources

• Amazon Threat Intelligence's ARTEX report, November 13, 2026
• AWS IAM security best practices
• OWASP Logging Cheat Sheet

Hero photo: CERN Server, by Florian Hirzinger, February 25, 2009. CC BY-SA 3.0. Resized from 3984 x 2656 to 1920 x 1280 pixels and JPEG-compressed. The adapted photograph is shared under the same license. This archival server-room photograph is illustrative. It does not show AWS, MadPot, ARTEX or an affected organization. No endorsement is implied.