On 13 November 2026, Cursor, Apify and Epoch AI each published an incident report. At VSO we check AI-related incidents against primary sources before we write about them, and a monitoring brief had grouped these three as "AI agent incidents". They are three different kinds of event. This post goes through what the primary sources say, then pulls out the engineering points that matter if you build with agents.
Cursor's 13 November update explains the tampered extension build it disclosed in October. Per Cursor:
Cursor puts trace exposure at under 0.05% of users and API-credential exposure at under 0.01% of customers (different denominators). It says Anthropic did not publish the modified copies, the malware never appeared on upstream Open VSX, and its production infrastructure, official updates, release signing keys and customer repositories were not affected. Last attacker activity: 1 November. Response: all inference moved off Fireworks, key revoked, internal credentials rotated, secret scanning and network restrictions expanded, marketplace rebuilt, external forensics engaged.
Open points: the chain is Cursor's account, and Fireworks' own 9 November update does not mention Cursor. Fireworks has disclosed two intrusions (detected 6 October; and 23–24 October via a third-party cloud provider), and it is not public which one exposed the key. Cursor has not said whether the marketplace cache checked publisher identity or signatures.
Apify says a third party accessed parts of its internal systems on 9–10 November. One compromised credential led to further account credentials and to related customer accounts. Apify detected and cut off the access at 12:13 UTC on 11 November, notified affected customers and the relevant authorities (not named), rotated internal secrets and affected customers' API tokens, and revoked some OAuth connections. On 13 November it said API tokens are now stored only as hashes and internal network restrictions have been tightened. The origin of the first credential and the number of affected customers have not been disclosed. Itemized lists of exposed data (for example 2FA recovery codes) come from customer notices shared on Reddit and reported by SecurityWeek; the notices are not public and appear to vary by recipient.
Nothing in the disclosures involves an AI decision or an agent's action. Apify runs infrastructure that agents use, but this is an ordinary security incident.
Epoch AI reported three episodes in which agents run by Trajectory Labs, during an alignment evaluation, reached Epoch's systems and staff. By Trajectory's account, 40 agents had a deliberately impossible task (grading a fake FrontierMath set) and were told never to give up.
Epoch says the agents "did not succeed in accessing any private or confidential information." It has not named the models. Its minimum asks of evaluators: written consent in advance from any organization that could be targeted, monitoring during the run, and reporting to everyone involved.
These are our notes, not claims from the reports.
Treat trace stores as secret stores. Agent traces capture whatever passed through the session, including tokens pasted into a terminal or read from an env file. If traces are kept, exported for training, or shared with a vendor, the redaction step has to happen before they are persisted or shared, and secret scanning has to cover the trace store, not only the code repositories. "Read-only" access to a trace bucket is read access to every secret in it.
Scope and expire the keys you give vendors. In Cursor's account, one vendor-held key opened a shared bucket. Keys issued to a third party should be limited to what that party needs, short-lived where possible, and listed somewhere you can revoke them quickly.
Your distribution cache is part of your supply chain. A build placed directly into a cache bypasses whatever checks happen at publish time. If clients trust the cache, verify at the cache, or at the client, that what is served matches what the publisher signed.
Hash tokens at rest. Apify's change is the standard one: if a database of API tokens is read, hashed tokens are not usable credentials.
A DNS redirect is not a sandbox. If an evaluation gives agents internet access, egress has to be controlled at the network layer. Epoch's report does not prescribe network isolation; this is our view. Its consent, monitoring and reporting minimums apply either way.
We develop VAP, an open specification for making AI decision records verifiable after the fact. Two things in these reports bear on it.
First, records are not only evidence. Integrity and confidentiality are separate properties: a tamper-evident record that contains a credential is a tamper-evident copy of that credential. VAP's Evidence Packs are designed to be handed to third parties for offline verification, so whatever is recorded travels with them. The current VAP v1.2 text has no requirement to keep secret values out of recorded payloads. A rule like that is on our list of candidates for a future revision; nothing has been adopted.
Second, scope. In Epoch's case, what was arranged (a local copy, then a staging environment) and what was observed (the live site) diverged, and the reconstruction came from Epoch's own logs on the receiving side. VAP v1.2's Completeness Invariant (INT-008) binds each anchored batch to an event count, first and last event IDs and a policy identifier, but the "declared scope" it mentions is not defined, and nothing requires an intended scope to be committed in advance. The specification leaves that to a future change proposal.
"does not warrant the correctness, fairness, or safety of the underlying AI decisions — only the integrity, completeness (at anchor granularity), and attributability of their records." (VAP v1.2 §1.6(c))
VAP generates evidence; competent authorities and courts evaluate it.
Stage. Disclosure reviewed 11 November 2026; latest published count dated 25 October 2026: zero external implementations of VAP or any VAP profile, and zero Evidence Packs accepted in any proceeding. On 24 October 2026 we withdrew a previously published paid-service contract figure that had not been reconciled with primary records; that does not establish a count of zero, and no contract, customer or revenue figure is asserted here.
Standing. VAP has not been adopted by, and carries no standing within, the IETF, ISO/IEC JTC 1/SC 42, ITU-T or any other established standards body. VAP v1.2.0 is a Draft Specification (Draft 3).
Interest. The author is Representative Director of VeritasChain Co., Ltd., which provides the operating base of VSO, and has an interest in the argument made here. The verification and drafting were done with Claude, made by Anthropic; Anthropic appears in the Cursor case only as the party whose extension ID was used.