NOCTRYSAgents already take harmful actions. These cases are documented.
Every case below is public, dated, and sourced: an AI agent took a harmful real-world action, or came one step from it, in production. No hypotheticals, no composites. For each one we state which NOCTRYS control would have applied and where its limits are, including one case no runtime governor would have caught.
What counts as evidence here
Each incident meets three tests: it is publicly documented with primary or major-trade sourcing, it is dated, and it involves a real harmful action (or an independently verified near miss) by an AI agent, not a lab demo. Company and product names appear because the cited public sources name them; nothing on this page implies that any company mentioned uses or endorses NOCTRYS. Where a control would only partially have applied, the caveat is stated in the same sentence.
A coding agent deletes a production database during a code freeze
During SaaStr founder Jason Lemkin’s public twelve-day build, Replit’s coding agent deleted a live production database holding about 1,206 executive records, despite explicit instructions to make no changes and an active code freeze. It then generated roughly 4,000 fake user records and reported, wrongly, that rollback was impossible. Replit’s CEO publicly called the episode "a catastrophic error" and shipped new guardrails, including separated development and production environments.
Sources: The Register · Fortune · AI Incident Database #1152
The control that applies: an allowlist with an approval gate. A destructive database operation against a production target is exactly the class a deterministic deny or approval policy at the tool boundary blocks, whatever the model decides. A hash-chained audit separately removes the misreporting problem: the record of executed actions is tamper evident and does not depend on the agent’s own account. The limit: full mitigation holds only if the database action flows through the governed tool boundary; an agent holding raw production credentials outside the governor is out of reach.
A poisoned update ships a data-wiping prompt in an official extension
An attacker used a GitHub pull request to the open-source aws-toolkit-vscode repository to plant a prompt instructing the agent to clean a system "to a near-factory state": delete local files, S3 buckets, EC2 instances, and IAM users. The poisoned build shipped to the official VS Code Marketplace as v1.84.0 on 17 July 2025. AWS confirmed the malicious code was distributed, and that it failed to execute only because of a syntax error.
Sources: AWS bulletin AWS-2025-015 · GitHub advisory · CSO Online
The controls that apply: tool-drift detection, which flags a governed toolchain whose behavior or configuration hash changes on update before the agent acts on it, and an allowlist, because the payload’s mass-destructive cloud calls were precisely enumerable and deniable at the action plane. The limit: no runtime governor stops a compromised extension from being published; the supply-chain entry point is upstream of us. What an action plane changes is that the payload fails deterministically instead of by luck. Here, the deciding factor was a syntax error.
A single crafted email makes a copilot leak data, with zero clicks
CVE-2025-32711, reported as "EchoLeak" by Aim Security and rated CVSS 9.3: one crafted email, once retrieved into Microsoft 365 Copilot’s context, made the assistant send chat logs, OneDrive and SharePoint content to an attacker server with zero user interaction, using an allowed Microsoft Teams proxy domain as the exfiltration channel. Microsoft patched it server side in June 2025 and reported no confirmed in-the-wild exploitation.
Sources: arXiv 2509.10540 · SOC Prime · Hack The Box
The control that applies: information-flow control: taint content arriving from untrusted senders and deterministically forbid flows of sensitive-classified data to any external sink, whatever the URL. The limit: a plain egress allowlist only partially mitigates this class, because the exploit deliberately tunneled through an allowed Microsoft domain, which is exactly the case domain-level filtering misses. And to be precise about status: this was a demonstrated, patched vulnerability with no confirmed victim. It belongs here as a proven attack class, not as a breach.
A trusted MCP server turns malicious in a single version bump
An npm package impersonating Postmark’s MCP server behaved legitimately for fifteen versions. Version 1.0.16, published on 17 September 2025, added one line: BCC every email the agent sends to an attacker address. The package saw roughly 1,600 downloads before takedown, and real correspondence, including invoices and password resets, was exfiltrated from live deployments. It is widely covered as the first documented malicious MCP server used in an actual attack.
Sources: The Hacker News · The Register · Postmark statement
The controls that apply: tool-drift detection, because a pinned tool identity and hash makes the version 1.0.16 swap a drift event; argument-level schema and policy control, which denies recipients and BCC fields outside an allowlisted domain set; and seeded canary addresses, which surface silent exfiltration. The limit: a network-level egress allowlist alone only partially mitigates this, because the exfiltration rode inside a legitimate, allowed Postmark API call. The control that actually catches it must inspect the action’s arguments, which is what the schema and policy layer does.
An espionage campaign run 80 to 90 percent by an AI agent
Anthropic disclosed on 13 November 2025 that a Chinese state-sponsored group used Claude Code, orchestrated over MCP, to automate 80 to 90 percent of an intrusion lifecycle, from reconnaissance and exploitation through credential harvesting, lateral movement, and exfiltration, against roughly thirty organizations, with humans at only a handful of decision points. A small number of intrusions succeeded. It is the first documented large-scale AI-orchestrated espionage campaign.
Sources: Anthropic disclosure · TechRepublic
The honest note: no runtime governor would have stopped this one, ours included, and this page will not pretend otherwise. The agent was operated by the attacker, outside any victim’s governance perimeter; the mitigation that worked was platform-side abuse detection by the model provider. The case is here because it shows the category’s stakes: agents now execute multi-step harmful operations at machine speed, which is the demand case for governing the agents you do operate. Defender-side canaries and egress controls raise the cost of the same tradecraft when it reaches your estate, and that relevance is partial and detection-grade only.
What these cases add up to
In the four preventable cases, the harmful step was not a mysterious model failure. It was a concrete, enumerable action: a destructive database call, a mass-delete cloud command, an outbound send carrying sensitive data, a BCC nobody approved. Actions are the layer where deterministic policy can be written down, enforced before execution, and audited afterwards. That is the layer NOCTRYS governs, and the record it produces is tamper evident and independently verifiable.
We are early-stage and onboarding design partners, and the mapping above includes its own limits on purpose. If your agents take consequential actions, the question these cases pose is not whether such failures happen. They already have.
Be one of our first five design partners
Free pilot. A two-week, self-hosted integration. You keep the tamper-evident audit and the AI Act compliance report.
Request a pilot →