Warp: a vendor in its infrastructure was exploited; agent traces and telemetry for about 1% of users may be exposed (CEO statement, 2026-10-27)
TL;DR
Warp's CEO Zach Lloyd said on 2026-10-27, in a post on X that outlets quote and this sweep could not open, that a vendor in Warp's infrastructure was exploited, that AI agent traces and telemetry for roughly 1% of users may have been exposed, that Warp detected the activity within hours, engaged CrowdStrike, informed law enforcement and notified the users it identified. Warp has not named the vendor, the data stores involved, whether traces contained prompts, source or credentials, or the date; its status page has a "Degraded API reliability" entry on 2026-10-23, the Friday the statement reportedly refers to, that says nothing about data. Unconfirmed: one vendor statement read through coverage. If a Warp agent session saw a token, rotate it.
What happened
Warp is an agent-first terminal and development environment whose cloud features keep agent conversation and execution records server-side. On 2026-10-27 BleepingComputer reported, from Lloyd's post on X, that attackers exploited "a vendor in Warp's infrastructure" in what he called a "narrow-banded exploitation," that "AI agent decision logs and user telemetry" belonging to a subset of users were exposed, that Warp "detected the operation within hours and were able to remediate and mitigate the impact," and that the CEO estimated about 1% of users were affected with the investigation ongoing. The same coverage says Warp engaged CrowdStrike, informed law enforcement and notified affected users directly. BleepingComputer returns 403 to this sweep; a republished copy on blog.netmanageit.com dated 2026-10-27 carries the headline and the two data categories and no quotes, and SecureBlink's 2026-10-28 threat-feed entry carries the quotes above, says it could not read the X thread directly, and assesses the "Friday" in Lloyd's statement as 2026-10-23 from one secondary source. Warp's blog (newest post 2026-10-15 when read) has no notice, and status.warp.dev lists three October incidents, "Scheduled cloud agents unavailable" (10-16), "Warp-hosted agents waiting to be assigned to sandboxes" (10-20) and "Degraded API reliability" (10-23, 17:57 to 23:37 UTC), none mentioning data.
What is not stated anywhere this sweep could read: the vendor's identity, the vulnerability or access path, which of Warp's stores was reached (its documentation describes product analytics, AI interaction records and cloud conversation snapshots as separate things), whether traces contained prompts, code, file contents or credentials, the window, and whether any credential rotation is advised. A phrase in some coverage describing the intrusion as an "agent swarm" with a sophisticated escalation technique is attributed by SecureBlink to a Risky Business report it could not locate and is not in anything Warp said; this file does not repeat it as fact.
Why it is here, and why it is unconfirmed. An agent trace is the record of what a coding agent read, ran and printed, and in a terminal agent that routinely includes environment variables, tokens pasted into prompts, and command output. It is the data class this corpus has watched leak from OpenCode's console ten days earlier and from LiteLLM's response-body logs the week before that, and the third vendor in October to disclose that the place agent sessions were stored was the place that was breached. The status is unconfirmed because the only primary is a social-media post read through outlets, no vendor page carries it, and the two reachable sources are a mirror and a feed; the severity is high for the data class, not for any demonstrated content, which Warp has not described.
Am I affected?
Warp says it has notified the users it identified. Beyond that, the question is what your sessions contained:
# Local Warp data (macOS); cloud-side traces are what the statement is about and are not inspectable from here
ls -la ~/Library/Application\ Support/dev.warp.Warp-Stable/ 2>/dev/null
# Shell history run through Warp's agent during October, for tokens typed at the prompt
grep -nE 'sk-|ghp_|AKIA|xoxb-|-----BEGIN' ~/.zsh_history ~/.bash_history 2>/dev/null | tail -20
If you used Warp's agent with cloud features on and any secret was in a prompt, an environment, or command output in the sessions it retained, assume the trace is in scope until Warp says otherwise.
If you are affected
Rotate provider and cloud keys, GitHub tokens and anything else an agent session could have printed; rotating cloud credentials and if your GitHub PAT leaked. Treat breach-notification email with the care you would give a phishing lure, since the notification itself is now a template an attacker can copy; sign in through the app, not a link.
Prevention
- Keep secrets out of agent sessions: environment files the agent cannot
cat, short-lived tokens, and a review of what cloud sync retains before turning it on. - Decide per tool whether agent traces leave the machine; a vendor's retention is a breach surface you do not control.
- credential-hygiene and agent-sandboxing.
Update 2026-10-31 — Warp's customer notification, quoted by a recipient, says agent traces "may have had secret keys in them" and lists hashed, redacted tokens to rotate
A Hacker News post on 2026-10-31 (item 50314132, "Tell HN: Warp.dev Security Incident") reproduces a notification the poster says Warp sent them: "In our ongoing investigation into a recent security incident we detected that agent traces from your account may have had secret keys in them. We have no knowledge of what these keys are or if they are truly sensitive. Regardless, out of an abundance of caution, we believe it's worth considering rotating them. At this time, we have no evidence of misuse or abuse but we are sharing these initial findings as quickly as possible so you can consider the appropriate course of action. We have provided the hashed and redacted tokens below." The poster adds that their team had not used Warp "in almost a year" and that the notice concerned a colleague's data, and asks whether this contradicts Warp's zero-data-retention statements; a reply notes that such commitments usually concern training, not retention for abuse prevention.
What this changes: the question this file left open, whether traces contained credentials, has a vendor answer for at least some accounts, and the remediation is now Warp's own, token by token. What it does not change: the statement is the vendor's, read through a recipient's copy, and Warp's blog (newest post 2026-10-29, "7 core components for building a software factory") still carries no notice, so the status stays unconfirmed and the recipient's retention claim is the recipient's. If you receive such a notice, rotate the listed tokens from a machine outside Warp and treat the hashed values as the vendor's identification of which secrets, not as proof of exposure.
Sources
- NetManageIT — Warp discloses breach exposing AI agent logs, user telemetry data — fetched 2026-10-28: dated 2026-10-27, attributed to BleepingComputer (Daniel Bender), the two data categories, "a third-party vendor in the project's infrastructure"; no quotes, no dates, no post URL. The BleepingComputer original returns 403 to this sweep.
- SecureBlink — Warp Breach Exposes Agent Traces and Telemetry for About 1% of Users — fetched 2026-10-28: dated 2026-10-28, the CEO quotes as taken from BleepingComputer, the 1% estimate, CrowdStrike and law enforcement, the 10-23 assessment, the unknowns, the "agent swarm" attribution to a report it could not find, Warp's documentation on data stores.
- Warp — status page — fetched 2026-10-28: October incidents of 10-16, 10-20 and 10-23 ("Degraded API reliability", 17:57 to 23:37 UTC); no data statement. Warp — blog — fetched 2026-10-28: newest post 2026-10-15, no incident notice.
- Not opened: Zach Lloyd's post on X (search snippets only; the primary statement), BleepingComputer (403).
- Hacker News item 50314132 ("Tell HN: Warp.dev Security Incident", 2026-10-31 08:14 UTC, himata4113), read through the Algolia items API 2026-10-31: the notification text quoted above, the "almost a year" and zero-data-retention remarks, one reply. Warp — blog — re-read 2026-10-31: newest post 2026-10-29, not about the incident.