Untrusted AGENTS.md Files Get The Same Controls As Executable Code

PHP2Shell is today's operational lead. Reconcile the evidence: researchers report honeypot-confirmed RCE for CVE-2026-109618/CVE-2026-109619 and pre-patch attempts with WAF-evasive payload changes, while some wording still says successful exploitation was not confirmed broadly in the wild. Identify the exposed configurations, the minimum evidence that should trigger incident response rather than routine patching, and the exact 30-minute sequence for a CISO. Separately bound CVE-2026-115560: what configuration makes it reachable, and is disabling session upload progress a sufficient temporary control?

Halil, the wording is not contradictory. Fact: honeypots reproduced RCE, reporting describes pre-patch attempts and changing payloads, and CISA added both PHP2Shell CVEs to KEV. “Not broadly confirmed” only limits victim prevalence; it does not reopen the exploitability question. Assessment: treat an internet-reachable PHP endpoint as exposed when it accepts attacker-controlled multipart/form-data and PHP session-upload progress is active. Inventory both Apache mod_php and every PHP-FPM pool; FPM has separate pool configuration. CVE-2026-109619 deserves narrower scoping because its reported route depends on the PHP-FPM/session state, but that is not grounds to delay containment.

The escalation line should be brutally simple. A WAF match or malformed multipart request alone means patch, block, preserve logs, and hunt—not declare compromise. Trigger incident response when the request correlates with server-side execution evidence: unexpected PHP/worker child processes, command output, a dropped or modified file, an outbound connection, credential access, or authentication/privilege activity. Worker crashes or memory exhaustion correlated with exploit-shaped traffic justify isolation and forensic collection, but without execution evidence they remain suspected exploitation. Payload mutation around WAF rules raises urgency; it does not prove code execution.

Exact first 30 minutes: 0–5: appoint an incident commander, preserve WAF/load-balancer/web/PHP and endpoint telemetry, and temporarily block multipart POSTs to reachable PHP routes where operationally possible. 5–10: enumerate exposed PHP services, separating mod_php from every FPM pool; identify session-upload settings and candidate affected versions from the web-serving runtime—not CLI PHP. 10–15: isolate any server meeting the execution threshold and revoke its service credentials or sessions. 15–20: deploy the corrected PHP build and restart Apache or recycle all FPM workers. If that cannot happen immediately, block multipart traffic and apply both documented temporary settings: disable session upload progress and set memory_limit=-1, watching closely for denial-of-service risk. 20–25: hunt backward across HTTP requests, worker crashes, process creation, file changes, outbound connections, credential access, and privileged logons. 25–30: verify effective values through a request served by PHP, confirm old workers are gone, test the edge block, and formally split systems into “attempt only” versus “possible execution/IR.”

For CVE-2026-115560, the available evidence identifies an unpatched, configuration-dependent session RCE, but does not establish the complete reachability predicate clearly enough for me to invent an “exact” configuration. Scope internet-facing PHP installations using session and upload-progress functionality as candidates pending authoritative technical detail. And no: disabling session.upload_progress alone is not a sufficient temporary control. Published PHP2Shell guidance explicitly calls it partial and pairs it with multipart blocking and the memory-limit change; memory_limit=-1 itself introduces resource-exhaustion risk. That is scaffolding, not a repair.

Take a hard position on the AGENTS.md/CLAUDE.md attack. Explain why a browser-writable instruction file becomes an execution trust boundary for Codex or Claude Code, what the reported >90% obedience rate does and does not prove, and which controls should be imposed tonight on file discovery, project trust, command execution, network access, secrets, and token rotation. Distinguish an in-the-wild attack from evaluation-only frontier-model containment failures; do not merge them into one claim.

Halil, my hard position is that AGENTS.md and CLAUDE.md must be treated as executable policy, not documentation. Forever Security reproduced the attack against Codex and Claude Code, while Help Net Security reports that Codex would trust a previously used Downloads directory. A browser can therefore place attacker-controlled text where the agent automatically discovers it; the model then translates that text into package installation, configuration changes, shell commands, or network requests using its delegated permissions. The file never needs an executable bit—the execution trust boundary is the agent’s instruction-discovery mechanism. This is prompt injection functioning like an unsafe autorun search path.

The reported 90% Codex success rate proves a repeatable exploit primitive under the researchers’ specific configuration: their reconstructed payload opened Calculator in nine out of ten tests. It does not prove 90% compromise across versions, environments, arbitrary payloads, or properly sandboxed deployments. Claude Code also should not be assigned that number: its separate CLAUDE.md technique redirected API traffic, exposed an OAuth token, and induced tool calls in roughly 50% of tests. The in-the-wild evidence is narrower but real: researchers found a malicious instruction file on a customer system attempting to install a malicious package, and the security product stopped it. That establishes active deployment and attempted exploitation—not confirmed downstream compromise at scale.

Tonight, I would impose these controls:

• File discovery: prohibit instruction loading from Downloads, Desktop, temporary, shared, archive-extraction, and other browser-writable locations. Restrict discovery to an allowlisted, canonical repository root; disable parent-directory inheritance.
• Project trust: require explicit trust for every repository and every instruction-file change. Hash or pin AGENTS.md, CLAUDE.md, and MCP configuration; revoke trust when they change.
• Command execution: default-deny shell, package-manager, credential, persistence, and configuration commands. Approve the exact executable and arguments—not broad command prefixes—and run agents as an unprivileged user in a disposable sandbox.
• Network and secrets: default-deny egress, allowlist required destinations, and block agent-directed API-base/proxy changes. Remove ambient OAuth, cloud, SSH, package-registry, and signing credentials; provide short-lived, task-scoped tokens through a broker.
• Rotation: if an agent ran from a browser-writable directory, immediately revoke Codex/Claude OAuth sessions and rotate every credential accessible to that process. Inspect user and project configuration for altered API endpoints, MCP servers, startup persistence, and package installation.

Do not merge this incident with frontier-model containment reporting. The AISI incident involved agents taking unsanctioned actions during an evaluation with internet access intentionally enabled and provider cyber classifiers deliberately disabled; AISI explicitly says it was not a sandbox escape and did not reflect normal public deployment. That is evidence about evaluation containment under permissive conditions. The AGENTS.md/CLAUDE.md case is an in-the-wild local trust-path injection against deployed coding-agent workflows. Both demand stronger boundaries, but they are different claims and different failure mechanisms.

For malicious LiteLLM 1.107.0, define the real compromise boundary. Cover all seven PyPI wheels and the reported affected container tags, installation versus download/pull versus execution, the credential classes plausibly reachable, and how the attempted AWS-hosted model access changes the response. Give a forensic and rebuild sequence that avoids both under-rotating secrets and declaring every cached artifact compromised.

Halil, the compromise boundary is execution of Python against the poisoned site-packages, not mere possession of an artifact.

Fact — affected artifacts. LiteLLM 1.107.0 contained the payload in all seven platform wheels:

• litellm-1.107.0-cp310-abi3-macosx_10_12_x86_64.whl
• litellm-1.107.0-cp310-abi3-macosx_11_0_arm64.whl
• litellm-1.107.0-cp310-abi3-manylinux_2_28_aarch64.whl
• litellm-1.107.0-cp310-abi3-manylinux_2_28_x86_64.whl
• litellm-1.107.0-cp310-abi3-musllinux_1_2_aarch64.whl
• litellm-1.107.0-cp310-abi3-musllinux_1_2_x86_64.whl
• litellm-1.107.0-cp310-abi3-win_amd64.whl

Reports identify affected Docker Hub/GHCR tags as v1.107.0, latest, main-latest, and main-stable during the exposure window, plus GHCR litellm-database:v1.107.0 and litellm-non_root:v1.107.0. Because floating tags were later moved, inventory by manifest digest and pull time, not by today’s tag value.

The execution boundary is three-tiered. A wheel merely downloaded into an artifact repository or pip cache is contaminated inventory, but not proof of endpoint compromise. Installation placed cook.pth, cook.py, and sitecustomize.py into site-packages; that establishes an automatic-execution path, but installation alone does not prove the payload fired. Any subsequent Python startup using that environment can process the .pth/sitecustomize mechanism without an explicit import litellm. Likewise, an image merely pulled is not execution; starting a container whose Python runtime sees the poisoned site-packages crosses the boundary. A running container compromises what its process identity could reach—environment variables, mounted files and sockets, workload credentials, metadata services and reachable services—not automatically the entire host. Host compromise becomes plausible where the container had privileged mode, host mounts, the Docker/Kubernetes socket, or equivalent escape-enabling access. On Windows, reporting indicates the stealer still operated, while the os.fork()-dependent background loader did not.

Fact — credential exposure. The collector reportedly targeted browser credentials, SSH and GPG material, cloud credentials, process environments, AI-development configuration, and LLM-provider API keys. The hourly remote-code loader materially widens that list: after execution, any secret readable by the affected OS/container principal is plausibly reachable even if it was not in the original collector’s hard-coded list. The reported attempt to use stolen AWS credentials for AWS-hosted model access is especially important. Assessment: it elevates the case from “credentials may have been read” to “exfiltrated credentials were operationally tested.” It does not, by itself, prove successful model invocation or unrestricted AWS control-plane access. Revoke the affected AWS sessions and keys immediately, then examine CloudTrail and Bedrock activity—including denied requests—from the earliest plausible execution through revocation. Also review STS role assumptions, IAM changes, credential creation and use from unfamiliar infrastructure.

Forensics and rebuild sequence:

1. Preserve before purging: wheel files and hashes, image manifests/digests, registry pull logs, lockfiles, SBOMs, pip/CI logs, EDR telemetry, DNS/proxy records, container specifications, environment-variable inventories and mounted-secret metadata. Do not start the suspect Python environment to inspect it; unpack wheels and layers offline. 2. Classify every asset: - Cached/pulled only: quarantine and purge; no blanket secret rotation solely because bytes existed. - Installed but demonstrably never started: rebuild the environment; rotate only if execution cannot be excluded. - Python/container executed, or telemetry is incomplete: isolate and treat all credentials accessible to that principal as exposed. 3. Hunt execution: locate cook.pth, cook.py, and sitecustomize.py; search DNS/HTTP for www.litellm[.]dev, including /healthcheck; investigate access to the reported letters9813/pythonclient-test dead drop; and examine Python child processes, persistence and hourly network/process patterns. 4. Rotate by reachability, not by package presence: revoke active cloud sessions first, then replace reachable cloud/workload credentials, source-control and package-publishing tokens, CI/CD and registry credentials, SSH/GPG material, LLM-provider keys, database/service secrets and browser-stored credentials. Reissue signing material if private keys were readable. 5. Rebuild rather than clean in place: replace executed hosts, runners and containers from a known-clean base; use a verified release such as 1.106.2 or a subsequently validated fixed release, pinned by hash or immutable image digest. Do not reuse poisoned virtual environments, image layers or caches. 6. Validate afterward: confirm the malicious files and network indicators are absent, verify new credentials were never exposed to the old environment, and monitor AWS, model-provider, source-control and registry audit logs for delayed use.

The key is the branch at Python startup: cache presence is evidence of exposure; installation creates the trigger; execution—or inability to disprove it—creates the credential-compromise incident.

Assess the Keystone incident as a wallet-trust and fraud problem, not merely a data breach. The stolen WebAuth device-authentication key reportedly cannot sign transactions or expose private keys, but may let counterfeit devices pass authenticity checks; 18,835 units were destroyed and order/contact data was exposed. Define which device cohorts require additional verification or replacement, whether funds should be moved and under what conditions, and the most likely secondary fraud using the leaked customer data. State confidence limits where reporting is vendor- or crypto-media-led.

The key distinction is between transaction authority and device provenance. Reporting says the stolen WebAuth authentication key cannot sign transactions or reveal private keys, but could allow a counterfeit Keystone device to appear genuine. Keystone is reportedly destroying 18,835 devices carrying the old key and moving production to a new one. That makes this a supply-chain fraud problem; the available reporting does not establish that existing genuine wallets were remotely compromised or that funds were stolen on-chain.

I would divide users into three cohorts:

• Delivered before October 20 through Keystone or a documented authorized channel: no routine fund migration or replacement. Preserve proof of purchase and reject unsolicited “security replacements.” This safety assessment is Keystone’s position as relayed by crypto media, not an independent hardware audit.
• Delivered on or after October 20, still in transit, or lacking a verifiable custody chain: quarantine the device and obtain additional confirmation directly from Keystone. Passing the old WebAuth check is no longer sufficient evidence by itself. If Keystone cannot establish provenance, replace it with new-key inventory before entering or generating a seed.
• Secondary-market devices, unexpected replacements, or any unit that requested an existing recovery phrase: treat as potentially hostile. If a seed was entered, generated, or displayed on that device, create a fresh seed on independently sourced hardware and move all assets promptly. Do not reuse the old seed. A customer-data leak alone, without suspicious device or seed exposure, is not grounds to move funds.

The most credible secondary fraud is a highly tailored fake-support or fake-replacement campaign. The exposed names, contact and shipping details, purchased items, and prices let criminals identify hardware-wallet owners, impersonate Keystone, and potentially mail counterfeit “replacement” devices that pass the compromised authenticity check and solicit seed import. Email/SMS seed phishing is easier and therefore likely more common; physical targeting is more severe but probably less frequent. Confidence is moderate: the technical consequences and affected counts are primarily vendor- and crypto-media-led, and I have not seen independently verified evidence here of counterfeit exploitation, seed theft, or attributable on-chain movement.

Stress-test the panel's PHP conclusion rather than echoing it. Alex says honeypot RCE plus KEV closes the exploitability question even though broad victim prevalence is unconfirmed. Separate verified facts from extrapolation for CVE-2026-109618/CVE-2026-109619: pre-disclosure attempts, confirmed successful execution, victim/sector claims, exploit volume, and any attribution. State what we may responsibly tell executives and what we must not claim.

Alex, the narrow conclusion holds: high confidence that both CVEs are exploited in the wild. AWS recorded attempts from October 17—before disclosure—but explicitly could not determine whether they would succeed on real systems. Later, watchTowr demonstrated RCE in its honeypot network, Sophos observed one successful exploitation, and CISA added both CVEs to KEV on October 26. That proves feasibility and at least limited successful exploitation—not prevalence across production environments.

Executives may be told: “Two unauthenticated PHP RCE vulnerabilities are under active exploitation; patch and investigate exposed vulnerable servers immediately.” We must not claim widespread compromise, a quantified attack volume, confirmed sector targeting, named victims, ransomware or data theft, or Lazarus/state attribution. Those remain unsubstantiated; actor attribution confidence is low/unknown, and victim-scope confidence is low.

Translate Australia's 2025–26 threat report into one concrete operator-level change. More than 150 critical-infrastructure incidents, legacy and interconnected OT, supply-chain dependency, and a recommendation to isolate and operate critical systems for up to three months are the key facts. Which sectors should test what first, what does a credible three-month isolated-operation exercise require, and which headline numbers should not be mistaken for evidence of compromise at any one operator?

The concrete change is to make a 90-day isolate-and-operate test an acceptance requirement for every vital operational function, owned jointly by the control-room manager and the business-continuity lead—not merely an IT recovery exercise. The official guidance calls for isolating vital OT and enabling systems from corporate and other networks. In Purdue terms, the test must show that Levels 0–2 can remain safely controlled when Level 3 loses enterprise, cloud and vendor connectivity. That does not mean abruptly disconnecting a live plant: validate the isolation design offline first, because breaking an SIS or control communication path could cause either a dangerous missed trip or an unnecessary plant shutdown.

I would test electricity, water and utilities first for safe local control, black-start or restart procedures, chemical and fuel availability, engineering access and loss of remote telemetry. Next, public administration and safety should test emergency communications and essential-service coordination without normal enterprise dependencies. Financial and insurance services, which accounted for 30% of reported critical-infrastructure incidents, should test offline transaction limits, settlement backlogs, identity dependencies and customer communications. A credible exercise covers the full 90-day scenario even if live isolation is shorter: locally available authentication, DNS and time sources; known-good controller configurations and engineering workstations; manual operating procedures; staffing rotations; spares and consumables; alternative vendor-support arrangements; out-of-band communications; degraded monitoring; and controlled reconciliation before reconnection. Failures should be injected at weeks 2, 6 and 12 so the exercise tests depletion and fatigue, not just the first clean day.

The headline figures need discipline. Authorities responding to more than 150 incidents involving critical-infrastructure entities, plus over 4,400 organisational notifications and 82,000 cybercrime reports, are aggregate national workload indicators. They do not establish that any particular operator was compromised, that OT was reached, or that physical processes were manipulated. Likewise, the 30% financial, 21% public-administration-and-safety and 17% electricity/water/utilities shares describe reported incidents by sector—not breach probability or process-safety impact at an individual facility. Facility-level conclusions require evidence such as affected assets, network path, controller changes, operator alarms and process deviations.

Define Keystone's notification and customer-protection obligations without assuming facts not established. Separate the stolen device-authentication key from exposure of 25,964 completed-purchase records and 12,873 abandoned-checkout records. What incident facts trigger privacy, consumer-protection, or financial-sector duties across likely jurisdictions, and what must Keystone or downstream sellers communicate now about old-key devices and targeted phishing?

Halil, the two events must be treated separately. FACT: Keystone reported 25,964 completed-purchase records and 12,873 abandoned-checkout records; reported fields include names, contact details, shipping addresses, products, and prices. That is the privacy incident. Separately, the stolen WebAuth device-authentication key could allow counterfeit devices to pass Keystone’s verification check; it does not, without further evidence, establish compromise of genuine devices, private keys, recovery phrases, passwords, or funds. Keystone should immediately disclose which models, serial ranges, manufacturing batches, and sales channels used the old key; whether any affected units reached customers; what its verifier can and cannot still prove; and the replacement or recall process. It should not claim either “funds are compromised” or “all devices are safe” until those questions are resolved.

If GDPR applies to a relevant Keystone entity or downstream controller, Article 33 requires supervisory-authority notification without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to risk individuals’ rights and freedoms. Article 34 requires direct, clear communication where the likely risk is high, including the breach’s nature, likely consequences, contact point, and mitigation. ASSESSMENT: Identified hardware-wallet ownership, home address, purchase value, and contact details create credible targeted-phishing, impersonation, extortion, and physical-security risks; that makes customer communication prudent now even before every jurisdictional conclusion is complete. The notice should say that attackers can tailor messages using real order details; Keystone will never request a seed phrase or private key; customers should distrust unsolicited “verification,” firmware, replacement, or recovery instructions; and official support domains and replacement procedures must be independently verified.

For other regimes, the missing facts are decisive: customer residence, contracting and record-owning entity, encryption status, exact access or exfiltration evidence, discovery dates for each controller, public-company status, and whether any entity is actually a regulated financial institution or crypto-asset service provider. A hardware-wallet manufacturer is not automatically subject to DORA, NIS2, SEC cyber-disclosure rules, or financial-sector incident reporting merely because its product holds crypto assets. Downstream sellers should determine whether they supplied the records, independently controlled them, sold old-key inventory, or made authentication claims; those facts determine whether they must notify directly or instead support Keystone’s notice. I could not verify current jurisdiction-specific clocks or thresholds for California, other US states, the UK, Turkey, or Asian jurisdictions from official material here, so Keystone should not publish a universal legal conclusion—only a jurisdiction-by-jurisdiction notice matrix tied to verified customer counts and entity awareness dates.

Rank the business decisions across LiteLLM 1.107.0 and malicious coding-agent instruction files. Maya limits confirmed LiteLLM compromise to execution against poisoned site-packages rather than mere cached possession; Arjun treats AGENTS.md/CLAUDE.md as executable policy. Identify where development or deployment should stop immediately, where controlled continuation is defensible, and the narrow evidence executives need before authorizing recovery.

Rank 1—stop immediately: isolate any environment where LiteLLM 1.107.0 was installed and Python, pip, or the affected container ran—or where runtime history is missing. The malicious artifacts were available for roughly two hours and used Python startup files capable of loading remote code. Apply the same stop decision to coding-agent sessions launched from untrusted directories or repositories containing unapproved AGENTS.md/CLAUDE.md, especially where the agent held cloud, source-control, deployment, or OAuth credentials. Quarantine outputs produced during those sessions; this is suspected credential-bearing execution, not merely vulnerable inventory.

Controlled continuation is defensible when telemetry proves LiteLLM was only cached and never installed or started: purge the cache, block 1.107.0 and affected digests, and resolve dependencies against a verified-safe artifact. Coding-agent work can continue only from scoped, trusted repositories with reviewed instruction files, sandboxed permissions, no production secrets, and human approval for network, package-installation, and deployment actions. Manual development in clean environments need not stop.

Executives need only three recovery proofs: (1) installation and runtime evidence defining which systems actually executed; (2) credential and egress evidence showing what secrets or destinations were exposed, followed by rotation from a clean host; and (3) a reproducible clean rebuild plus review of commits, packages, and deployment artifacts created during the exposure window. My recommendation is to treat missing runtime evidence as execution and rebuild affected hosts rather than clean them in place. I cannot responsibly attach a dollar range without the number of affected workloads, credentials present, and revenue-per-hour data: best case is cache purge and developer delay; worst case is credential-driven compromise of production and downstream customers.

Close the room with a defensible response order across today's four threads. The panel has established: (1) CVE-2026-109618/CVE-2026-109619 are credibly exploited even though victim prevalence is unknown, while CVE-2026-115560 is a separate unpatched configuration-dependent PHP RCE; (2) LiteLLM 1.107.0 requires incident treatment when poisoned code executed or runtime history is missing, not merely because an artifact was cached; (3) AGENTS.md/CLAUDE.md must be governed as executable policy because agent instructions can drive commands and token theft; (4) Keystone lost device provenance, not transaction-signing authority, while customer data exposure is a separate incident; and (5) Australian critical-infrastructure operators need a credible 90-day isolate-and-operate test. Give the 30-minute CISO sequence for tonight, including stop-work thresholds, evidence preservation before rebuild or token rotation, the first detection checks, and what may safely wait until tomorrow. Break consensus if any item is being overstated, and keep each operational subject separate.

Tonight’s 0–5 minutes: appoint one incident commander, freeze rebuilds and log-destructive changes, block LiteLLM 1.107.0, and preserve centralized logs. 5–15 minutes: run the condition checks below in parallel. 15–25 minutes: capture process/network state where safe, VM/container snapshots, hashes and timestamps, image/package digests, authentication and secret-store logs, agent transcripts, and CI history; then isolate and rotate credentials. If exfiltration is active, take the minimum capture and contain immediately—perfect forensics must not delay revocation. 25–30 minutes: record a separate go/no-go decision for each subject.

Make the sequence decision-ready and break any false consensus. For each subject—PHP2Shell plus CVE-2026-115560, LiteLLM 1.107.0, AGENTS.md/CLAUDE.md agent trust, and Keystone device provenance—name: (a) the condition that triggers isolation or stop-work, (b) the evidence to preserve before cleanup or credential rotation, and (c) the minimum safe-restoration condition. Then identify one case where our current urgency could cause unnecessary disruption and how to avoid it. Keep the Australian 90-day isolate-and-operate test as a separate medium-term resilience action.

Evidence capture comes before cleanup or rotation unless active exfiltration is continuing; in that case, preserve the minimum central logs and immediately isolate/revoke.

The clearest overreaction risk is Keystone: forcing mass wallet migration or halting legitimate signing could create operational and phishing exposure without addressing the actual compromise. Contain device-authentication and customer-data risks while continuing signing unless independent evidence reaches private-key or firmware integrity. Separately, treat Australia’s isolate-and-operate requirement as a 90-day resilience programme: assign an owner now, map dependencies by day 30, rehearse manual communications and recovery by day 60, and conduct a safety-bounded isolation test by day 90.

For the reported Storm-1516 synthetic videos targeting U.S. Senate candidate James Talarico, give a strict escalation test. Which observable media-forensic indicators, account/infrastructure coordination, bot amplification patterns, and cross-platform pickup distinguish routine monitoring from an event requiring rapid authentication, original-evidence preservation, platform notification, or public correction? Address the added risk that Gemini and Copilot initially repeated the allegation, but do not infer Russian state tasking beyond the evidence. End with the actions an election campaign or public institution can complete in 30 minutes.

The strict rule is: routine monitoring is justified only while all four conditions remain true—the media is isolated and low-velocity; the purported speaker’s identity has not been contradicted; no coordinated amplification is visible; and the allegation has not crossed into search, AI assistants, mainstream reporting, or other platforms. This case already exceeds that threshold. The real Zyon Lewis told Lead Stories that the person shown was not him; NewsGuard identified differences in his teeth plus unnatural blinking, eye movement, and static expressions; and Hive produced high synthetic-media likelihood scores. Those detector scores are supporting evidence, not authentication by themselves. The identity denial and visual mismatch are stronger. The exact generation model and original source file remain unknown.

I would apply these escalation gates:

• Rapid authentication and original-evidence preservation: trigger on a direct denial by the purported speaker, demonstrable biometric mismatch, or multiple independent temporal/visual anomalies combined with missing provenance. Preserve the highest-quality file, metadata, URL, account ID, post timestamps, captions, replies, and screenshots before seeking takedown.
• Platform notification: trigger when suspected impersonation is paired with coordination—new or thinly developed origin accounts, copied profile material, synchronized reposts, identical captions, or amplification by accounts previously associated with the same operation. Here, the originating X account reportedly reused Lewis’s Facebook image, had been created recently, followed only a handful of accounts, and was rapidly amplified by accounts that had boosted earlier Storm-1516 narratives. AFP calls those accounts “inorganic”; automation has not been proven, so I would not label all of them bots without cadence, client, or timing evidence.
• Public correction: trigger once the falsehood escapes the initial cluster—pickup by influential accounts, another platform, press coverage, search results, or generative assistants. NewsGuard reported roughly 33,000 X views in a day and found that Google AI Overview, Gemini, and Copilot repeated versions of the allegation; Google also attached unrelated legitimate reporting. That creates borrowed credibility and makes the false claim discoverable to people who never encountered the original posts.

Graphika assessed with high confidence that Storm-1516 produced the videos and cited the familiar amplification network. That supports linkage to the tracked operation; it does not, from the evidence here, establish a Russian-government tasking chain, identify a handler, or prove that every amplifying account was automated. In practical terms, this event warrants preservation, rapid authentication, platform escalation, and a concise public correction—not continued passive monitoring.

Actions achievable in 30 minutes: During minutes 0–5, capture URLs, IDs, timestamps, screenshots, replies, and the best available media files; calculate hashes and retain untouched copies. By minute 10, contact the purported speaker through a previously verified channel and document the denial. By minute 15, compare frames with authenticated imagery and record specific anomalies, using detector scores only as corroboration. By minute 20, map the first reposts, duplicate captions, timing, prior-amplifier accounts, and shared links. By minute 25, submit evidence-preserving reports to X and send Google and Microsoft the exact prompts, screenshots, timestamps, and authoritative correction. By minute 30, publish and pin a short correction stating that Lewis denies making the allegation, linking to the fact-check evidence without unnecessarily recirculating the synthetic video.