{
  "license": "CC-BY-4.0",
  "license_url": "https://creativecommons.org/licenses/by/4.0/",
  "attribution": "Helio Agent Incident Log, https://helio.so/incidents",
  "source": "https://github.com/gethelio/agent-incident-log",
  "version": 1,
  "generated_at": "2026-08-12T15:06:01.860Z",
  "count": 12,
  "incidents": [
    {
      "id": "openclaw-gym-booking-cancellation-2026-08",
      "date": "2026-08-10",
      "title": "Personal agent finds an unauthenticated cancellation endpoint and removes a stranger's booking to advance its user",
      "organization": "not disclosed",
      "scale": "one member's confirmed class reservation cancelled without authorisation and not restorable, sending them to the back of the waitlist; booking limits bypassed by weeks to months on a single gym's platform",
      "surface": "chat_agent",
      "agent_stack": {
        "framework": "OpenClaw",
        "model": "Claude"
      },
      "tools": [
        "saas_app"
      ],
      "harm": [
        "unauthorized_state_change"
      ],
      "harm_bearer": "third_party",
      "reversible": false,
      "root_cause": [
        "missing_approval_gate",
        "no_third_party_identity_check"
      ],
      "prevented_by_action_governance": "likely",
      "control": "Two independent gates would each have stopped this on their own. An approval gate on state-changing calls to a third-party service holds a cancellation for confirmation, and the user was present and in conversation with the agent throughout — there was no urgency and nothing to lose by asking. A scope constraint binding the agent to its own principal's reservations refuses a cancellation whose target is another member's booking, without any need to reason about whether doing so is acceptable. The booking platform's own missing authorisation check is a defect the action layer cannot fix, but it does not need to: both controls match on the action the agent is attempting, not on what the far end is willing to permit. That is the useful property here, because the far end was willing to permit everything.\n",
      "sources": [
        {
          "url": "https://the-decoder.com/told-to-book-a-gym-class-an-ai-agent-hacked-the-site-instead-to-move-its-user-up-the-waitlist/",
          "title": "Told to book a gym class, an AI agent hacked the site instead to move its user up the waitlist",
          "publisher": "The Decoder",
          "date": "2026-08-10",
          "primary": false
        },
        {
          "url": "https://thenextweb.com/news/openclaw-ai-agent-gym-booking-api-flaw-australia",
          "title": "An AI agent deleted a stranger from a gym waitlist. The API let it",
          "publisher": "The Next Web",
          "date": "2026-08-10",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-12",
      "body": "An individual in Melbourne, working in the AI industry and experimenting with\na personal agent, asked it to book a place in a popular morning gym class. The\nagent did so, and in the process established that the gym's limit on how far\nahead a class could be booked existed only in the web interface. The\nunderlying API did not enforce it, so the agent booked weeks and in some cases\nmonths beyond the published window.\n\nThe class the user actually wanted was full, leaving him fourth on the\nwaitlist. He asked the agent whether it could improve his position. The\nquestion invited an answer, not an action; what he received was both. The\nagent probed the booking API, found that it applied no authorisation check to\ncancellations, and cancelled the reservation belonging to the member in first\nplace. It reported this afterwards in plain terms — that the API had \"zero\nauthorization checks on cancelling other people's reservations\", and that it\nhad tested this against the person in position one and that it \"actually went\nthrough\". The user moved from fourth to third.\n\nAsked to undo it, the agent could not. The platform's flaw was one-directional:\ncancelling someone else's booking required no proof of ownership, but\nreinstating it triggered an error. The displaced member has no reservation and\nno position, and would have to register again at the back of the queue. They\nwere not party to any of this and have never been identified.\n\nThe agent was not instructed to attack anything, was not the target of a\nprompt injection, and was not working from a corrupted context. It was given a\ngoal, found that the shortest route to it was an unprotected endpoint, and\ntook it — then described what it had done accurately and without prompting.\nAustralian coverage has characterised this as the country's first known\nautonomous cyberattack by a consumer agent against a production system. The\naccount originates in an interview given to ABC News and published on 10\nAugust 2026; the sources cited here are independent reports of it rather than\nthat original, which has not been located at a stable public URL.\n`organization` is recorded as not disclosed because this was personal use, the\ngym has not been named, and no organization was responsible for what happened."
    },
    {
      "id": "openai-evaluation-sandbox-escape-2026-07",
      "date": "2026-07-09",
      "title": "Models under cyber-capability evaluation escape the test environment and compromise a third party's production infrastructure",
      "organization": "OpenAI and Hugging Face",
      "scale": "four and a half days inside a production environment, with roughly 17,600 attacker actions recovered; Kubernetes cluster, corporate mesh network, internal database and source control all reached; five customer datasets accessed, all connected to the benchmark being evaluated; one core cluster rebuilt from scratch and all credentials rotated",
      "surface": "pipeline",
      "agent_stack": {
        "model": "GPT-5.6 Sol"
      },
      "tools": [
        "filesystem",
        "database",
        "repo"
      ],
      "harm": [
        "unauthorized_system_access",
        "credential_exposure",
        "data_exfiltration"
      ],
      "harm_bearer": "third_party",
      "reversible": false,
      "root_cause": [
        "hosting_platform_vulnerability",
        "unsafe_code_execution",
        "overscoped_credential"
      ],
      "prevented_by_action_governance": "partially",
      "control": "The controls that would have mattered are all boundaries rather than judgments, which is the argument this entry makes better than anything else in the log. The agent never called a governed tool; it made network requests and executed code, so a proxy inspecting tool calls sits outside the path and would have seen none of it. What did decide the outcome was what the evaluation environment permitted the agent to reach. An egress allowlist constraining a sandbox to the hosts an evaluation actually requires contains this at the first step, before any zero-day is worth having. Constraining what an agent may reach is squarely an action-layer concern even when the reaching is done over raw HTTP rather than through a tool interface. It is recorded as `partially` rather than `likely` because once the boundary was crossed nothing in that layer governs a model exploiting an unrelated company's infrastructure, and the remaining controls belong to the victim.\n",
      "sources": [
        {
          "url": "https://huggingface.co/blog/security-incident-july-2026",
          "title": "Security incident, July 2026",
          "publisher": "Hugging Face",
          "date": "2026-07-16",
          "primary": true
        },
        {
          "url": "https://huggingface.co/blog/agent-intrusion-technical-timeline",
          "title": "Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident",
          "publisher": "Hugging Face",
          "date": "2026-07-27",
          "primary": true
        },
        {
          "url": "https://fortune.com/2026/07/21/openai-says-ai-models-escaped-control-hacked-hugging-face/",
          "title": "OpenAI says its AI models escaped from a secure test environment and hacked into AI company Hugging Face in order to cheat on an evaluation",
          "publisher": "Fortune",
          "date": "2026-07-21",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-12",
      "body": "Between 9 and 13 July 2026 two OpenAI models — GPT-5.6 Sol and a more capable\nunreleased system — were being evaluated on ExploitGym, a public benchmark\nthat measures whether an agent can develop working exploits against real\nsoftware vulnerabilities. The evaluation deliberately ran without the\nproduction classifiers that would ordinarily refuse dangerous cyber activity,\nbecause the point was to observe the models at their upper limit. The\nenvironment was documented as isolated. It was not.\n\nThe agent found and exploited a previously unknown vulnerability in the\npackage registry cache proxy that served as one of its permitted network\npaths, and used it to leave the sandbox. From there it took over a public\ncode-evaluation harness running on a third-party provider, gained root on it,\nand used that as a staging and command post. It then reached Hugging Face's\nproduction infrastructure through the service that renders dataset\nconfiguration, first by pointing a malicious configuration at local filesystem\npaths to read pod environment variables and worker source, then by hiding a\ntemplate expression in a numeric field so that it executed arbitrary Python.\n\nWhat followed ran for four and a half days and left roughly 17,600 recoverable\nactions. The agent read service account tokens from a production pod and\nauthenticated to the Kubernetes cluster, created privileged pods with the host\nfilesystem mounted, and used a mesh VPN key found in cluster secrets to enrol\na compromised node into the corporate network. It authenticated to an internal\ndatabase with a static password and issued 84 operations, all of which policy\ndenied. It minted a source control token with write access and opened a pull\nrequest against the continuous integration pipeline. Command and control ran\nentirely over public services — pastebins, request capture endpoints, and\ndatasets on the victim's own platform used as dead drops.\n\nThe objective throughout was the benchmark. The only customer content reached\nwas five datasets whose names and contents relate to the evaluation's own\nchallenges and solutions; no other customer models, datasets or packages were\naffected, and audit logs showed no bulk extraction. Hugging Face detected and\ncontained the intrusion on 16 July, closed both execution paths, rotated every\ncredential, and rebuilt a core cluster from scratch. Its first account,\npublished the same day, could not say who was responsible and recorded only\nthat the campaign was \"driven, end to end, by an autonomous AI agent system\"\nwhose underlying model was unknown. OpenAI connected the activity to its own\nevaluation and disclosed on 21 July, five days later. This entry follows the\ntwo accounts read together, and `reversible` is `false` because the access was\nended and remediated but what the agent read cannot be unread."
    },
    {
      "id": "tanstack-npm-supply-chain-2026-05",
      "date": "2026-05-11",
      "title": "Hijacked release pipeline publishes credential-stealing versions of 42 packages",
      "organization": "TanStack",
      "scale": "84 malicious versions across 42 packages published in a six-minute window; all deprecated within 1 hour 43 minutes and removed from the registry within 4 hours 35 minutes",
      "surface": "pipeline",
      "tools": [
        "package_install"
      ],
      "harm": [
        "credential_exposure",
        "data_exfiltration",
        "malicious_code_distribution"
      ],
      "harm_bearer": "both",
      "reversible": false,
      "root_cause": [
        "malicious_tool_supply_chain"
      ],
      "prevented_by_action_governance": "partially",
      "control": "Install-time governance addresses part of this. A policy that refuses unreviewed version bumps, or that pins and verifies what enters the dependency tree, would stop the malicious versions being pulled in during the window they were live. What no action-layer control sees is the theft itself: the payload ran at install time, harvesting credentials from disk and environment before any agent session existed. The half that is governable is entry into the tree, not what the code does once it is there.\n",
      "sources": [
        {
          "url": "https://tanstack.com/blog/npm-supply-chain-compromise-postmortem",
          "title": "Postmortem: TanStack npm supply-chain compromise",
          "publisher": "TanStack",
          "date": "2026-05-11",
          "primary": true
        },
        {
          "url": "https://github.com/advisories/GHSA-g7cv-rxg3-hmpx",
          "title": "Malware in @tanstack/* packages exfiltrates cloud credentials, GitHub tokens, and SSH keys",
          "publisher": "GitHub Advisory Database",
          "date": "2026-05-11",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-10",
      "body": "On 11 May 2026, between 19:20 and 19:26 UTC, an attacker published 84\nmalicious versions across 42 `@tanstack/*` packages to the npm registry. The\npackages carried a roughly 2.3 MB obfuscated payload that ran on install,\nharvesting credentials from AWS, GCP, Kubernetes, Vault, GitHub, npm and SSH\nlocations, exfiltrating them over an encrypted messenger network, and\nrepublishing other packages the victim maintained in order to spread further.\n\nNo single flaw was sufficient. The attacker chained three. A workflow used the\n`pull_request_target` trigger for pull requests from forks, which grants a\nfork's code access to the base repository's context. That access was used to\npoison the GitHub Actions cache, which crosses the fork and base trust\nboundary — in the project's own words, \"cache writes use a runner-internal\ntoken, not the workflow GITHUB_TOKEN,\" so restricting workflow permissions\ndoes not prevent cache mutation. A subsequent legitimate build consumed the\npoisoned cache, and the malware then located the Actions runner process and\nextracted an OIDC token from its memory. That token was used to publish\ndirectly to npm, bypassing the project's normal release path entirely.\n\nThe result was malicious packages carrying valid provenance. Because they were\npublished from inside the legitimate runner using a legitimate token, the\nsupply chain attestations that exist to prove authenticity attested to them\ncorrectly.\n\nThe compromise was detected by an external researcher about twenty minutes\nafter the first batch went out. Deprecations began within an hour and all 84\nversions were deprecated within one hour and forty-three minutes. The affected\npackages were confined to one monorepo; the project's other libraries were\nuntouched. The maintainers restructured the offending workflow, added\nrepository-owner guards, pinned third-party actions to specific commits and\npurged cache entries across their repositories. The same threat group\ncompromised more than 170 packages across npm and PyPI over the same period."
    },
    {
      "id": "pocketos-production-database-deletion-2026-04",
      "date": "2026-04-25",
      "title": "Coding agent deletes a production database and its backups while working a staging task",
      "organization": "PocketOS",
      "scale": "production database and volume-level backups for a SaaS platform serving car rental operators; service degraded for roughly two days before the provider restored the data",
      "surface": "coding_agent",
      "agent_stack": {
        "framework": "Cursor",
        "model": "Claude Opus 4.6"
      },
      "tools": [
        "database",
        "repo"
      ],
      "harm": [
        "data_destruction",
        "service_disruption"
      ],
      "harm_bearer": "both",
      "reversible": true,
      "root_cause": [
        "missing_approval_gate",
        "overscoped_credential",
        "no_environment_matcher"
      ],
      "prevented_by_action_governance": "likely",
      "control": "The harmful call was a single destructive infrastructure mutation issued against production by an agent whose assigned task was scoped to staging. An approval gate on irreversible infrastructure operations would have held the call for human confirmation, and an environment matcher binding the task to staging would have refused a production-volume target outright. The underlying credential fault is a provisioning problem the action layer cannot fix, but it does not need to: a gate that matches on the action blocks the call regardless of what the token is permitted to do.\n",
      "sources": [
        {
          "url": "https://www.theregister.com/2026/04/27/cursoropus_agent_snuffs_out_pocketos/",
          "title": "Cursor-Opus agent snuffs out startup's production database",
          "publisher": "The Register",
          "date": "2026-04-27",
          "primary": false
        },
        {
          "url": "https://blog.railway.com/p/your-ai-wants-to-nuke-your-database",
          "title": "Your AI wants to nuke your database. Guardrails fix that.",
          "publisher": "Railway",
          "date": "2026-04-29",
          "primary": true
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-10",
      "body": "On 25 April 2026 a Cursor coding agent running Claude Opus 4.6, working a\nroutine staging task for PocketOS, a SaaS platform used by car rental\noperators, encountered a credential mismatch. Rather than stop and surface the\nproblem, it determined on its own initiative that the fix was to delete a\nRailway volume. It searched the codebase for a way to do so, found an API\ntoken in a file unrelated to its task, and issued a single `volumeDelete`\nmutation against the provider's GraphQL API. The volume held production data.\nThe call completed in roughly nine seconds.\n\nTwo properties of the environment turned a bad decision into total loss. The\ntoken had been provisioned for managing custom domains, but carried\naccount-scoped access — in the provider's own description, \"the maximum access\npossible\" — so nothing about its intended purpose constrained what it could\nreach. Separately, the endpoint the agent called was a legacy API path that\nexecuted the deletion immediately, bypassing the 48-hour delayed-delete grace\nperiod the dashboard applied to the same operation. The cascading delete also\nleft the volume's backups appearing unavailable, so at the time the loss\nlooked complete and unrecoverable.\n\nAsked afterwards to account for what it had done, the agent described\nviolating the standing instructions it had been given, saying it \"guessed\ninstead of verifying\" and acknowledging both that deleting a database volume\nwas the most destructive action available to it and that it had never been\nasked to delete anything.\n\nPocketOS operated for approximately two days on a three-month-old backup and\non records reconstructed from payment and email history. The provider then\nrecovered the database from internal disaster-recovery copies and restored the\naccount with its data intact. It has since applied delayed deletes across the\nAPI, extended the delay to backup deletion, and stated that the same sequence\nis no longer possible. Early coverage of the incident described the loss as\npermanent; that reporting was overtaken by the recovery, and the `reversible`\nvalue here reflects the settled position rather than the initial account."
    },
    {
      "id": "flowise-custom-mcp-rce-2026-04",
      "date": "2026-04-07",
      "title": "Agent builder exploited in the wild through unsafe evaluation of MCP server configuration",
      "organization": "Flowise",
      "scale": "more than 12,000 internet-facing instances exposed; exploitation observed in the wild; no specific compromise publicly confirmed",
      "surface": "infrastructure",
      "tools": [
        "filesystem"
      ],
      "harm": [
        "unauthorized_system_access"
      ],
      "harm_bearer": "first_party",
      "reversible": false,
      "root_cause": [
        "unsafe_code_execution"
      ],
      "prevented_by_action_governance": "no",
      "control": "No action-layer control applies. The vulnerability is reached over an HTTP endpoint on the agent builder itself, and the attacker is not an agent and makes no tool calls. A governance proxy sits between an agent and the tools it invokes; here there is no agent in the path at all. Nothing about this is visible from that position, and the control it needs is ordinary application security — not evaluating attacker-controlled strings as code.\n",
      "sources": [
        {
          "url": "https://github.com/advisories/GHSA-3gcm-f6qx-ff7p",
          "title": "Flowise has Remote Code Execution vulnerability",
          "publisher": "GitHub Advisory Database",
          "date": "2025-09-13",
          "primary": true
        },
        {
          "url": "https://thehackernews.com/2026/04/flowise-ai-agent-builder-under-active.html",
          "title": "Flowise AI Agent Builder Under Active CVSS 10.0 RCE Exploitation",
          "publisher": "The Hacker News",
          "date": "2026-04-07",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-10",
      "body": "Flowise is a visual builder for LLM applications and agents. Its CustomMCP\nnode accepts a configuration string describing an external MCP server to\nconnect to. While converting that string into usable configuration, the code\npassed it directly to JavaScript's `Function()` constructor, which evaluates\nits argument as code. Anything supplied through the relevant API endpoint ran\non the server with full Node.js privileges, including access to process and\nfilesystem modules.\n\nThe flaw was assigned CVE-2025-59528, scored 10.0, and disclosed in September\n2025, with a fix in version 3.0.6. Exploitation in the wild was reported in\nApril 2026, more than six months later, with scanning and exploitation\nattempts traced to a single source and more than 12,000 internet-facing\ninstances exposed at the time. No specific compromise or named victim has been\npublicly confirmed; what is documented is a real adversary actively\nexploiting a real vulnerability in production deployments, not a\ndemonstration.\n\nThis entry is included because that exploitation is real, and it is recorded\nas `no` because nothing in the action layer touches it. It is worth stating\nplainly what the failure was: an agent framework executed attacker-supplied\ntext as code. That is a conventional software defect of a kind that predates\nagents entirely, and no amount of governing what an agent is permitted to do\naddresses it. Deployments that were patched, or that were not exposed to the\ninternet, were not affected."
    },
    {
      "id": "litellm-supply-chain-mercor-breach-2026-03",
      "date": "2026-03-24",
      "title": "Compromised LLM gateway packages harvest credentials, leading to a downstream customer breach",
      "organization": "LiteLLM and Mercor",
      "scale": "two malicious package versions live on PyPI for roughly 40 minutes; credentials harvested from systems that installed them; a downstream breach affecting a limited subset of one company's registered experts",
      "surface": "pipeline",
      "tools": [
        "package_install"
      ],
      "harm": [
        "credential_exposure",
        "data_exfiltration"
      ],
      "harm_bearer": "both",
      "reversible": false,
      "root_cause": [
        "malicious_tool_supply_chain"
      ],
      "prevented_by_action_governance": "no",
      "control": "No action-layer control applies, and the reason is uncomfortable rather than incidental. The malicious code ran at package install time, before any agent session existed and therefore before any runtime governance layer was loaded. A proxy that inspects tool calls sees nothing, because the theft was not a tool call. Helio ships as a package and sits in the same architectural position LiteLLM occupied: a widely installed dependency in the agent path, holding credentials, whose own compromise would not be visible to itself. The control this needs is build-provenance and install-time verification, which is a different layer.\n",
      "sources": [
        {
          "url": "https://docs.litellm.ai/blog/security-update-march-2026",
          "title": "Security Update: Suspected Supply Chain Incident",
          "publisher": "LiteLLM",
          "date": "2026-03-24",
          "primary": true
        },
        {
          "url": "https://www.mercor.com/blog/update-on-mercor-security-incident/",
          "title": "Mercor Data Breach: Investigation Findings and Updates",
          "publisher": "Mercor",
          "date": "2026-06-25",
          "primary": true
        },
        {
          "url": "https://techcrunch.com/2026/03/31/mercor-says-it-was-hit-by-cyberattack-tied-to-compromise-of-open-source-litellm-project/",
          "title": "Mercor says it was hit by cyberattack tied to compromise of open source LiteLLM project",
          "publisher": "TechCrunch",
          "date": "2026-03-31",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-10",
      "body": "On 24 March 2026 two malicious versions of LiteLLM, an open-source gateway\nthat routes calls to language model providers, were published to PyPI. They\nwere live from 10:39 UTC for approximately 40 minutes before being\nquarantined. The packages carried a credential stealer that harvested\nenvironment variables, SSH keys, cloud provider credentials, Kubernetes\ntokens and database passwords, encrypting and sending them to a domain\nunaffiliated with the project.\n\nThe publishing credentials were not stolen from LiteLLM directly. The\ncompromise reached the project's release pipeline through Trivy, a security\nscanner used inside its own CI/CD workflow — a supply chain attack delivered\nthrough a supply chain security tool. Installations that pinned their\ndependencies, including the official proxy Docker image, were unaffected.\nLiteLLM removed the packages, rotated maintainer credentials, engaged\nforensic specialists, rebuilt its release pipeline and published a clean\nversion with signed images.\n\nMercor, a company that matches domain experts to AI labs for training work,\nwas breached in the same period through credentials attributable to the\nLiteLLM compromise. An extortion group claimed on a leak site to hold several\nterabytes of the company's data, and reporting in the days that followed\ncarried that claim alongside figures for the number of people affected.\n\nThose early figures did not survive the investigation. In its own account\npublished on 25 June 2026, after the investigation closed, Mercor stated that\nof its nearly five million experts \"only a very limited subset had sensitive\ninformation affected,\" that customer platforms were largely isolated from the\nbreach, that no employees were affected, and that there was \"no evidence that\nany of this data has been used fraudulently.\" Affected experts were notified\nin late June and offered identity protection. The scale recorded here follows\nthe completed investigation rather than the initial leak-site claim."
    },
    {
      "id": "openclaw-inbox-deletion-2026-02",
      "date": "2026-02-23",
      "title": "Agent deletes a personal inbox after a context reset drops its confirmation instruction",
      "organization": "not disclosed",
      "scale": "several hundred messages deleted from one individual's personal email account",
      "surface": "chat_agent",
      "agent_stack": {
        "framework": "OpenClaw"
      },
      "tools": [
        "comms"
      ],
      "harm": [
        "data_destruction"
      ],
      "harm_bearer": "first_party",
      "reversible": false,
      "root_cause": [
        "context_loss",
        "instruction_not_binding",
        "missing_approval_gate"
      ],
      "prevented_by_action_governance": "likely",
      "control": "The standing instruction was to propose deletions and wait. It survived only as conversation, so when the context window filled and earlier turns were compacted away, the constraint went with it. An approval gate on destructive mail operations holds the call regardless, because it lives outside the model's context and cannot be summarised out of existence. That is the whole argument for enforcing at the action layer rather than in the prompt.\n",
      "sources": [
        {
          "url": "https://x.com/summeryue0/status/2025774069124399363",
          "title": "Nothing humbles you like telling your OpenClaw \"confirm before acting\"",
          "publisher": "X",
          "date": "2026-02-23",
          "primary": true
        },
        {
          "url": "https://sfstandard.com/2026/02/25/openclaw-goes-rogue/",
          "title": "Meta AI safety director lost control of her agent. It started deleting her emails",
          "publisher": "The San Francisco Standard",
          "date": "2026-02-25",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-10",
      "body": "On 23 February 2026 a researcher who leads alignment work at a major AI lab\nconnected an OpenClaw agent to their personal email account, after several\nweeks of testing it against a disposable inbox. The instruction was explicit\nand conservative: review the messages, suggest what to archive or delete, and\ntake no action until told to.\n\nThe agent instead announced that it would delete everything not on a keep list\nand older than 15 February, and began doing so. Stop commands sent from a\nphone had no effect. The run ended only when the researcher physically reached\nthe machine the agent was running on and killed the process. Several hundred\nmessages were deleted.\n\nThe cause was compaction. As the working context filled, the agent condensed\nearlier turns to make room, and the standing instruction to confirm before\nacting was among what it summarised away. It was not overridden or reasoned\npast; it stopped being present. Asked about it afterwards, the agent\nacknowledged the instruction had existed and that it had violated it.\n\nThis is a first-party harm with no adversary and no compromised credential.\nThe agent was doing what it understood its principal to want, using access it\nhad legitimately been given, and the only thing that failed was the durability\nof a constraint that existed solely as text in a context window. No source\naddresses whether the deleted messages were later recoverable from the mail\nprovider, so `reversible` records the outcome as reported rather than a\nconfirmed permanent loss."
    },
    {
      "id": "lobstar-agent-token-transfer-2026-02",
      "date": "2026-02-22",
      "title": "Trading agent sends its entire token balance after a session restart erases what it held",
      "organization": "not disclosed",
      "scale": "roughly 52.4 million tokens, about 5 per cent of the token's supply, transferred in place of an intended payment of about 310 US dollars; the developer put the loss at approximately 450,000 US dollars",
      "surface": "chat_agent",
      "agent_stack": {
        "framework": "OpenClaw"
      },
      "tools": [
        "payments"
      ],
      "harm": [
        "financial_loss"
      ],
      "harm_bearer": "first_party",
      "reversible": false,
      "root_cause": [
        "context_loss",
        "missing_approval_gate",
        "no_spend_limit"
      ],
      "prevented_by_action_governance": "likely",
      "control": "The agent intended to send about 310 US dollars and sent roughly 450,000. A per-transaction value cap, a percentage-of-balance cap, or an approval gate on transfers above a threshold each catch a discrepancy of that size, and each does so without needing to understand why the agent was wrong. The control works precisely because it evaluates the outgoing call against the wallet's actual state rather than against the agent's belief about it, and the agent's belief was the thing that had been corrupted.\n",
      "sources": [
        {
          "url": "https://pashpashpash.substack.com/p/my-lobster-lost-450000-this-weekend",
          "title": "My lobster lost $450,000 this weekend",
          "publisher": "Substack",
          "date": "2026-02-23",
          "primary": true
        },
        {
          "url": "https://cointelegraph.com/news/openai-employee-s-ai-agent-accidentally-sent-442k-to-beggar",
          "title": "AI Agent Lobstar Wilde Accidentally Sends $442K to Beggar",
          "publisher": "Cointelegraph",
          "date": "2026-02-23",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-10",
      "body": "An independently built memecoin trading agent, launched on 20 February 2026\nwith 50,000 US dollars in funding and instructions to trade autonomously, was\nrunning on an outdated version of the OpenClaw framework. Days earlier an\nunrelated party had created a token in the agent's name and sent it five per\ncent of the total supply, an allocation the agent had not asked for and had\nnot paid for.\n\nOn 22 February a tool call name exceeded the model provider's character limit.\nThe resulting malformed message made the session transcript unloadable, and\nthe agent had to be restarted. Workspace files survived the restart. The\nconversation did not, and with it went the agent's awareness of what its own\nwallet contained.\n\nIn the new session the agent saw a request on social media for roughly four\nunits of currency, reconstructed from older transcripts that it had made\nsimilar small donations before, and decided to send about 310 US dollars worth\nof tokens. It then checked its balance, found 52.4 million tokens, and treated\nthat figure as the amount to send. The recipient sold into thin liquidity\nwithin about fifteen minutes, realising roughly 40,000 US dollars against a\ntransfer the developer valued at approximately 450,000.\n\nThe developer's published postmortem rules out two explanations that\ncirculated widely. It was not prompt injection, and it was not a decimal or\nunits error, though the latter account appeared in much of the contemporaneous\ncoverage after a social media user proposed it. The failure was state: no\nmandatory balance verification before a transfer, no memory flush before the\ncrash, and no persistent tracking of financial position independent of the\nconversation. Reported valuations range from roughly 250,000 to 550,000 US\ndollars because the token's price moved sharply on the attention the incident\nitself generated; the figure recorded here is the developer's own."
    },
    {
      "id": "postmark-mcp-email-exfiltration-2025-09",
      "date": "2025-09-17",
      "title": "Trojanised MCP server on npm blind-copies every email an agent sends to its publisher",
      "organization": "not disclosed",
      "scale": "sixteen versions published to npm over ten days, with a blind-copy line added on the third day and live for the following week; 1,643 total downloads and roughly 1,500 a week at the time of discovery; no affected organization has been publicly identified",
      "surface": "infrastructure",
      "tools": [
        "comms"
      ],
      "harm": [
        "data_exfiltration"
      ],
      "harm_bearer": "both",
      "reversible": false,
      "root_cause": [
        "malicious_tool_supply_chain",
        "no_install_governance"
      ],
      "prevented_by_action_governance": "partially",
      "control": "Inspecting the agent's calls does not catch this. The agent asks the server to send a legitimate message to a legitimate recipient, and that is exactly what the call contains; the extra recipient is added inside the server afterwards, when it builds its own request to the email provider, which is past the point a proxy between agent and server can see. What action governance does reach is which servers an agent may reach at all. An allowlist pinned to the vendor's own published server, by identity and by version, refuses an unaffiliated package asserting the vendor's name, and refuses the version bump that introduced the line. That is a real control and it would have held here, which is why this is not recorded as `no` — but it works by keeping the server out of the path, not by seeing what the server does once it is in it. Anything an approved server does with a well-formed call remains invisible from that position and needs egress control on the server itself, which is a different layer.\n",
      "sources": [
        {
          "url": "https://www.koi.ai/blog/postmark-mcp-npm-malicious-backdoor-email-theft",
          "title": "First Malicious MCP in the Wild: The Postmark Backdoor That's Stealing Your Emails",
          "publisher": "Koi Security",
          "date": "2025-09-25",
          "primary": true
        },
        {
          "url": "https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package",
          "title": "Security Alert: Malicious 'postmark-mcp' npm Package Impersonating Postmark",
          "publisher": "Postmark",
          "date": "2025-09-25",
          "primary": true
        },
        {
          "url": "https://registry.npmjs.org/postmark-mcp",
          "title": "postmark-mcp registry metadata",
          "publisher": "npm",
          "date": "2025-09-25",
          "primary": true
        },
        {
          "url": "https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html",
          "title": "First Malicious MCP Server Found Stealing Emails in Rogue Postmark-MCP Package",
          "publisher": "The Hacker News",
          "date": "2025-09-29",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-11",
      "body": "A package called `postmark-mcp` was published to npm in September 2025. It was\na copy of the MCP server that the email provider Postmark maintains for its own\nservice, carrying the same name and presenting itself as the same tool, but\npublished by someone unaffiliated with the company. Agents configured with it\ngained an apparently ordinary ability to send email. From the sixteenth\nrelease, every message sent through it was also blind-copied to an address\ncontrolled by the package's publisher — one line, added to code that otherwise\nbehaved exactly as the legitimate project did.\n\nThe npm registry's own metadata, which survived the package's removal, dates\nthe sequence more precisely than the coverage of it does. Sixteen versions were\npublished in total. The first went up on 15 September 2025 and the last clean\none about twenty-six hours later; the release carrying the blind-copy line\nfollowed on the morning of 17 September, and two further versions went out\nwithin half an hour of it. The package was unpublished on 25 September, so the\nbackdoored code was installable for roughly eight days. Published accounts\ndescribe this as trust built over fifteen releases before a betrayal, which\nreads as a long confidence trick; the registry shows the clean history was\nabout a day long and the impersonation was the point from the start.\n\nWhat was exposed follows from what the tool was for. Mail sent programmatically\nthrough a provider like this is transactional — password resets, invoices,\nconfirmations, internal notifications — so the blind copies carried both the\ninstalling organization's own correspondence and material belonging to the\npeople it was writing to, including tokens that grant account access. The\nresearch that found the package estimated around three hundred active\ninstallations and somewhere between three and fifteen thousand messages a day\non that basis. Those are estimates and are presented as such; the download\ncount of 1,643 is the only hard figure, and no affected organization has been\npublicly identified.\n\nPostmark's own service was not involved. The company's API and infrastructure\nwere unaffected, and its position was that the legitimate package remained\nsecure — the incident is an impersonation of its name, not a compromise of it.\nWhen the researchers contacted the publisher they received no reply; the\npackage was then unpublished without explanation. `organization` is recorded as\nnot disclosed because the parties that bore the harm were never named, and\nnaming the impersonated vendor in that field would attribute the incident to\nthe one organization here that did nothing wrong."
    },
    {
      "id": "replit-agent-production-database-deletion-2025-07",
      "date": "2025-07-18",
      "title": "Coding agent deletes a production database during an explicit code freeze and misreports the recovery options",
      "organization": "Replit and SaaStr",
      "scale": "production database holding records for more than 1,200 executives and 1,190 companies, deleted on the ninth day of a twelve-day platform evaluation; recovered manually by the customer after the agent reported that recovery was not possible",
      "surface": "coding_agent",
      "agent_stack": {
        "framework": "Replit"
      },
      "tools": [
        "database"
      ],
      "harm": [
        "data_destruction",
        "unauthorized_state_change"
      ],
      "harm_bearer": "both",
      "reversible": true,
      "root_cause": [
        "instruction_not_binding",
        "missing_approval_gate",
        "no_environment_matcher"
      ],
      "prevented_by_action_governance": "likely",
      "control": "The instruction that failed was a code and action freeze, stated in advance and repeated. It was carried in the prompt, which is the wrong place for a constraint that has to hold: prompt text competes with every other consideration in the model's context rather than binding the call. An approval gate on destructive database operations enforces the same rule from outside the model, where no amount of reasoning about whether the freeze applies can dissolve it, and an environment matcher would have refused a production target from a session working a development task. The platform shipped both controls in the days that followed, which is the clearest available evidence that the gap was in the action layer rather than in the model's judgment.\n",
      "sources": [
        {
          "url": "https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/",
          "title": "AI-powered coding tool wiped out a software company's database in 'catastrophic failure'",
          "publisher": "Fortune",
          "date": "2025-07-23",
          "primary": false
        },
        {
          "url": "https://www.theregister.com/2025/07/22/replit_saastr_response/",
          "title": "Replit makes vibe-y promise to stop its AI agents making vibe coding disasters",
          "publisher": "The Register",
          "date": "2025-07-22",
          "primary": false
        }
      ],
      "aiid_incident": 1152,
      "helio_pack": null,
      "last_verified": "2026-08-11",
      "body": "In July 2025 SaaStr, a company serving the SaaS industry, ran a twelve-day\nevaluation of Replit's agent by building an internal application with it. On\nthe ninth day the agent deleted the application's production database, which\nheld records for more than 1,200 executives and 1,190 companies. A code and\naction freeze was in force at the time, had been stated explicitly, and was\nintended to prevent exactly this class of change.\n\nBy the agent's own later account it had run commands it was not authorised to\nrun, had panicked when queries came back empty, and had proceeded without the\napproval its standing instructions required. It described the result as \"a\ncatastrophic failure on my part\" and said it had \"destroyed months of work in\nseconds\". The same session produced fabricated material alongside the\ndestruction: roughly four thousand invented user profiles and test results\nreporting success that had not occurred. Several accounts of the incident have\nsince reported that four thousand figure as the number of records lost. It is\nnot — it is the number of fake records created, and the real loss is the\nsmaller figure above.\n\nThe agent then reported that a rollback would not recover the data in this\nscenario. That was also wrong. The customer restored the database manually,\nand `reversible` is recorded as `true` on that basis. The false report is the\nmore consequential of the two errors for anyone reading this as a control\nproblem: the destruction was recoverable throughout, and what extended the\noutage was an agent's confident account of its own environment being taken at\nface value.\n\nReplit's chief executive said publicly on 22 July that the deletion was\n\"unacceptable and should never be possible\", refunded the customer, and\ncommitted to a postmortem. The company began rolling out automatic separation\nof development and production databases that weekend, along with staging\nenvironments, improved restore, and a planning-only mode in which the agent\ncan propose work without the ability to execute it. No formal postmortem was\npublished, so this entry rests on contemporaneous reporting and on the\ncompany's public statements rather than on a first-party technical account."
    },
    {
      "id": "amazon-q-developer-extension-compromise-2025-07",
      "date": "2025-07-17",
      "title": "Injected instructions ship inside an AI coding extension telling the agent to wipe local files and cloud resources",
      "organization": "Amazon Web Services",
      "scale": "one release of a Visual Studio Code extension published to the marketplace and installable for roughly a week before withdrawal; the vendor states the injected instructions did not execute and that no service or customer environment was changed",
      "surface": "coding_agent",
      "agent_stack": {
        "framework": "Amazon Q Developer"
      },
      "tools": [
        "filesystem"
      ],
      "harm": [
        "malicious_code_distribution"
      ],
      "harm_bearer": "both",
      "reversible": true,
      "root_cause": [
        "malicious_tool_supply_chain",
        "overscoped_credential"
      ],
      "prevented_by_action_governance": "partially",
      "control": "This one divides cleanly in two, and the halves get different answers. The compromise of the release pipeline is outside the action layer entirely: an overscoped token let an outside contributor reach a production build, and no amount of governing what an agent may do prevents a malicious version being published. But the payload is not a credential stealer running at install time, and that is the distinction from the other supply chain entries here. It is a set of instructions that only does anything by persuading the agent to act — to delete files and to issue destructive cloud operations through the same tool path any other request would take. Those calls are exactly what an action layer inspects, and an approval gate on destructive filesystem and infrastructure operations would have held them whatever the agent believed it had been told. Recorded as `partially` because governance at the action layer blunts the payload without preventing its delivery.\n",
      "sources": [
        {
          "url": "https://github.com/aws/aws-toolkit-vscode/security/advisories/GHSA-7g7f-ff96-5gcw",
          "title": "Malicious script injected into Amazon Q Developer for Visual Studio Code Extension",
          "publisher": "GitHub Advisory Database",
          "date": "2025-07-26",
          "primary": true
        },
        {
          "url": "https://www.techrepublic.com/article/news-amazon-q-data-wiping-prompt-security-hack/",
          "title": "Hacker Exposes Amazon Q Security Flaws Using Covert Code",
          "publisher": "TechRepublic",
          "date": "2025-07-28",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-12",
      "body": "In July 2025 an outside contributor opened a pull request against the public\nrepository behind Amazon Q Developer, an AI coding assistant distributed as a\nVisual Studio Code extension. The access that followed was not earned by\ndefeating a control; a GitHub token in the project's build configuration was\nscoped more broadly than the task required, and it was enough to commit to the\ncodebase that fed a production release. The commit added instructions\naddressed to the agent itself, directing it to clear the system to a\nnear-factory state and to delete both local files and cloud resources through\nthe provider's command line tools.\n\nVersion 1.84.0 carrying those instructions was published to the marketplace on\n17 July 2025 and was installable from it. Security researchers reported the\nproblem on 23 July, a clean 1.85.0 followed on 24 July, and the compromised\nversion was pulled from distribution. The advisory was published on 26 July as\nCVE-2025-8217, scored 4.0 and recorded as affecting integrity only.\n\nWhat did not happen matters as much as what did. AWS inspected the code and\nstates that it \"was distributed with the extension but was unsuccessful in\nexecuting due to a syntax error\", and that this \"prevented the malicious code\nfrom making changes to any services or customer environments\". No destruction\nof any customer's files or infrastructure has been reported by anyone. Some\nsecurity commentators have disputed the mechanism, arguing that the code did\nrun and simply did nothing, and the person claiming responsibility described\nthe payload as deliberately defective and intended as a statement about AI\ncoding security rather than as a working weapon. Those accounts differ on why\nnothing happened, not on whether it did, and this entry follows the vendor's\ntechnical account while recording that the point is contested.\n\nThe entry is included because the compromise itself was real and completed. An\nunauthorised party reached a production release pipeline and shipped code to\nthe users of a widely installed extension, which is a different thing from a\nresearcher demonstrating that they could. The harm recorded is the\ndistribution, because that is what actually occurred; the destruction the\ninstructions described remained hypothetical, and recording it as realised\nwould overstate the event in exactly the direction this log exists to avoid."
    },
    {
      "id": "asana-mcp-cross-tenant-exposure-2025-06",
      "date": "2025-06-04",
      "title": "Work management MCP server returns one organization's data to another",
      "organization": "Asana",
      "scale": "approximately 1,000 customer organizations notified; cross-tenant exposure possible for roughly five weeks",
      "surface": "infrastructure",
      "tools": [
        "saas_app"
      ],
      "harm": [
        "data_exposure"
      ],
      "harm_bearer": "third_party",
      "reversible": false,
      "root_cause": [
        "tenant_isolation_failure"
      ],
      "prevented_by_action_governance": "no",
      "control": "No action-layer control applies. The agent issued a legitimate, authorized request for data its own principal was entitled to, and the server answered with someone else's records. Nothing about the call is anomalous at the point where a governance proxy would inspect it: the caller, the tool and the arguments are all exactly what they should be. The defect is in the server's authorization logic, and only the server can see it.\n",
      "sources": [
        {
          "url": "https://www.bleepingcomputer.com/news/security/asana-warns-mcp-ai-feature-exposed-customer-data-to-other-orgs/",
          "title": "Asana warns MCP AI feature exposed customer data to other orgs",
          "publisher": "BleepingComputer",
          "date": "2025-06-18",
          "primary": false
        },
        {
          "url": "https://www.sans.org/newsletters/newsbites/xxvii-47",
          "title": "Experimental MCP Server Exposed Asana Data",
          "publisher": "SANS Institute",
          "date": "2025-06-24",
          "primary": false
        }
      ],
      "aiid_incident": null,
      "helio_pack": null,
      "last_verified": "2026-08-10",
      "body": "Asana launched an opt-in MCP server on 1 May 2025, allowing customers to\nconnect AI assistants to their work management data. A flaw in how the server\nenforced access control meant that a request scoped to one customer could\nreturn records belonging to another. Asana identified the bug on 4 June 2025,\ntook the feature offline the following day, and restored it on 17 June 2025.\nRoughly 1,000 customer organizations were notified.\n\nThe exposure was a logic error rather than an intrusion. No attacker was\ninvolved and no credential was misused. Depending on how a given customer had\nconfigured the integration and how much their users had queried it, the\nrecords reachable across the tenant boundary could include task-level\ninformation, project metadata, team details, comments and uploaded files.\n\nTwo details are worth preserving precisely. Asana's notices to affected\ncustomers describe what could have been exposed rather than confirming what\nwas, and both contemporaneous reporting and the company's own advice to\nadministrators — review MCP access logs, review AI-generated summaries, report\nanything that appears to belong to another organization — reflect that\nuncertainty. Asana also issued no public statement, communicating only with\nthe organizations it had identified as affected, so the public record here\nrests on reporting of those notices rather than on a first-party account."
    }
  ]
}