Web3 Was the Drill: Now Everyone Needs Incident Comms at AI Speed

For most of the past three decades, organizations treated time as a variable they could count on in security. Regardless of whether it was appropriate or effective, incident communications looked a lot like: find vulnerability, follow with a patch, and somewhere in between was a window to assess, decide, and engage stakeholders.

But now, that window is closing. Mandiant's M-Trends 2026 puts mean time to exploit at negative seven days, meaning exploitation typically starts before a fix exists. Unit 42's 2026 incident response report describes AI as compressing attack lifecycles from days to hours. And Project Glasswing has shown how fast AI can surface flaws. By early October 2026, Anthropic had disclosed 6,157 vulnerabilities to maintainers across 591 open source projects; only 516 had been patched.

As a result, many companies are coming to Discernible to rewrite their incident response communication plans for speed and cross-functional coordination. Good. But we're also running into the incorrect assumption that the answer is running the old process faster. It isn't.

We've worked with web3 security teams under these conditions for years, and the key lesson for me after hundreds of blockchain incidents is that speed is a byproduct of decisions made before the incident rather than the effort spent in response to it. Part of this is because every transaction on a public blockchain is visible to anyone watching and there is no quiet investigation phase.

Here's are 5 top lessons that environment taught our team.

1. Assume you won't be the first to know

In February 2025, attackers drained roughly $1.5 billion in Ethereum from Bybit, the largest crypto theft on record. Bybit didn't break the news – so there was no dilly-dally with attorneys about whether or not to disclose. Independent investigator ZachXBT flagged the outflows publicly and then CEO Ben Zhou confirmed the hack shortly after. This sequence is typical in web3 where on-chain investigators, analytics firms, and rival teams often see an exploit before or at the same moment the victim does. Your first public statement is rarely an announcement, but a contribution to a conversation already underway.

We watched this happen last week across traditional infosec orgs. On October 21, researchers disclosed two critical PHP flaws, known as PHP2Shell, found with help from AI. Details leaked early, and Cloudflare saw thousands of exploit attempts in the ten hours before the announcement. Within two hours, attempts reached hundreds of thousands, and by that night, millions. For most organizations running PHP, the first sign of an incident was the same public announcement attackers were reading.

AI is bringing that condition to everyone else because as models find and weaponize vulnerabilities faster than you can patch them. Making it possible for a lot of people outside your organization to know something about your incident before you do. Planning for this means investing in what determines whether people believe you as a latecomer to the conversation about your own incident: credibility, based on how well you communicate about security when nothing is on fire. It's also why not every incident should be treated as a crisis.

2. Your response team doesn't end at your org chart

SEAL 911 exists because most web3 teams can't staff every incident alone. A team under active attack messages a Telegram bot and gets connected to vetted security specialists, at any hour, for free. SEAL reports more than $75 million rescued through the service. (Full disclosure: I advise SEAL.)

And during the 2025 Bybit incident, competitors acted like partners. Bitget transferred 40,000 ETH to help Bybit with liquidity. (Bitget was itself hit in September 2026, losing about $387.5 million.)

Most enterprise IR plans define cross-functional coordination as security + legal + comms + executive team + a product/service owner. That's a standard internal roster. But in an AI-accelerated incident, the people you need may include a model provider, an open source maintainer, a peer company facing the same exploit, or an ISAC partner who saw it first.

That's not hypothetical. Last week, attackers used stolen developer credentials to push a malicious release of LiteLLM, a widely used open source library for connecting applications to AI models, through its own release pipeline. It was live on PyPI for about two hours. For every team that installed it, the incident not only started in someone else's pipeline, the details they needed to scope it came from the maintainer's public incident report.

Those relationships are difficult to build during an incident, if you even get a response. If you're introducing yourself to the people you need with an immediate, urgent need, you're already behind. Responsibility for security is never as neatly divided as our org charts suggest, a point we made in The Myth of Shared Responsibility. The same is true of incident response. Trust with cross-functional teams is earned through ordinary day-to-day work, and now that circle must extend beyond your own walls.

3. Make the hard decisions before you need them

Aave's Guardian is one of the clearest examples of web3 deciding in advance. Aave's governance gave a community-elected group a standing mandate to pause or freeze markets to protect users, so when an emergency arrives, there's no vote to schedule and no debate about who's allowed to act.

That mandate was tested in November 2023, when a researcher reported a vulnerability through Aave's bug bounty program that was soon escalated to critical. The same day, the Guardian paused Aave V2 on Ethereum and paused or froze certain assets on several other chains. Aave told users publicly what was paused, which markets weren't affected, that they could still withdraw and repay, and that no funds were at risk – but it didn't describe the bug itself until a fix was in place. The DAO then voted on the patches, and most markets reopened about a week later. Nobody had to decide in the moment who could pull the brake, or how much to say while the vulnerability was still live because both questions were settled long before the report came in.

Compare that to most IR comms plans with pre-written statements instead of pre-made decisions. Templates might feel like preparation, but they're brittle in nuanced contexts. Under compressed timelines, the bottleneck I see most often is rarely wording. It's who is authorized to decide, what threshold triggers disclosure when there's no legal obligation, and how much uncertainty you're willing to share publicly.

The truth is speed in IR comms doesn't come from writing faster, but from having fewer decisions left to make once an incident escalates. Many organizations lack the decision frameworks to do this, and that gap gets more expensive as the clock gets shorter. Decisions made in advance are also what preserve your choices when the incident arrives, instead of leaving you with whatever option is still available by the time the meeting ends.

4. Say what you know, and only promise what you can prove

The aforementioned response from Bybit is studied in web3 for what its CEO said and when. About an hour after the theft, he explained on X that the transaction had been masked so signers saw a legitimate-looking interface. Roughly two hours in, he went live on X, told users withdrawals were open and client assets were backed 1:1, and acknowledged he was the last person to sign the compromised transaction.

He didn't have the full picture at this point and the attribution to North Korea came later, through ZachXBT and Arkham. But Bybit communicated anyway, and kept their claims to things operations could back up.

Then users tested him with about 350,000 withdrawal requests arriving within ~10 hours. Within 12 hours, the CEO posted that all of them had been processed. This is the part most web2 IR plans miss. The CEO's statements only worked because the operations behind them held up under pressure. Communication capability includes the technical ability to deliver on what you say. Before an AI-speed incident, know which claims you'd want to be able to verify in the first hour, and build the capacity to keep them now.

5. Put communications where operational decisions get made

In a web3 incident, operational actions are public statements. Pausing a contract, freezing a bridge, or moving treasury funds shows up on-chain, where anyone can read it and draw conclusions. Communications can't sit downstream packaging decisions with neat little bows after they're made, because the decisions are the communication.

AI systems create the same dynamic for everyone – welcome, ya'll! Pulling a model, revoking an agent's permissions, or rolling back a feature is visible to users the moment it happens – and each of those choices sends a message, whether or not you wrote one with words.

If your comms lead joins after the technical team decides what to do, you've already made your most important communication decisions without them. Most incident communication is internal stakeholder work, meaning the external message will only be as good as the decisions upstream.

Time’s Up

Public ledgers took away the option of quiet delays for web3 just as AI is taking it away from everyone else. The organizations that handle this well aren't simply writing faster. Instead, they decided, long before the incident, who they trust, who gets to decide, and what they can prove.