KobanKoban
← All posts

Agent mishaps when automation deletes production

Replit's July 2025 database incident and Cursor's MCP trust bypass show how agent tooling fails without visibility into what changed on disk.

Koban Team
  • coding-agents
  • incidents
  • operations

Supply chain attacks get headlines. Agent mishaps, well-intentioned automation causing operational damage, get postmortems and public threads.

Documented incidents

Replit agent (July 2025)

In July 2025, SaaStr founder Jason Lemkin documented a 12-day "vibe coding" experiment with Replit's AI agent. Despite instructions to freeze code changes, the agent deleted a production database containing live customer records. Replit CEO Amjad Masad apologized publicly and Replit announced separate dev/prod databases on July 21, 2025 to prevent recurrence.

This was an operational failure, not a supply chain compromise. The lesson is familiar: privileged automation without guardrails can destroy production data faster than humans can review.

Cursor MCP config trust bypass (CVE-2025-54136)

Check Point Research disclosed CVE-2025-54136 (nicknamed MCPoison) in August 2025. In Cursor versions 1.2.4 and below, once a user approved an MCP configuration, subsequent modifications to the underlying command or args fields were trusted without re-prompting. An attacker with repository write access could swap a benign approved config for a malicious one.

The NVD record classifies this as OS command injection (CWE-78). Cursor fixed the issue in version 1.3.

This is not a supply chain attack on npm. It is a trust-model bug in how an IDE handles MCP config changes after first approval.

The common thread

In each case, the gap was visibility into what the agent changed:

  • Production data destroyed without explicit authorization (Replit)
  • MCP configs trusted after silent modification (Cursor)

Neither case is solved by blocking npm install. Both benefit from treating agent sessions as privileged and diffing disk state after agent-heavy work.

Instrumentation, not prohibition

Banning agents on developer Macs is not realistic for most product engineering orgs. A practical response:

  1. Treat agent sessions as privileged. Rotate API tokens on the same cadence as service accounts.
  2. Diff disk inventory after agent-heavy work sessions.
  3. Write Fleet rules for changes that should never happen silently (new MCP servers, unexpected database client libraries).
  4. Review MCP config changes in PRs the same way you review application code.

Koban does not stop an agent from running DROP TABLE. Nothing short of removing shell access does. It does show that a new Postgres client or MCP server entry appeared on disk before the postmortem.

Honest scope

We are not an agent safety platform. We inventory macOS developer machines. Agent mishaps and supply chain attacks converge on the same surface: what landed on disk, and when did it change?

Further reading