Alex Stamos on AI’s Security Crisis: Defense Has to Become Affordable

1. Guest Background

Alex Stamos approaches this roughly hour-long Decoder interview as someone responsible for making security work inside an AI company. He is Cognition’s chief security officer, a lecturer at Stanford University’s Cyber Policy Center, and a longtime cybersecurity practitioner. Host Nilay Patel asks him to explain what AI is changing about attacks, what defenders can realistically automate, and why organizational decisions may matter as much as model capability.

Stamos’s historical reference point is the development of the security profession itself. He recalls attending early Defcon gatherings and belonging to the generation of hackers that companies hired to test their systems. That experience gives his argument a particular focus: the industry’s practices developed around assumptions about scarce expertise and the people required to conduct an operation. He believes those assumptions are weakening.

His present work also shapes the proposals. Stamos says Cognition uses its tools to help companies repair vulnerabilities after attacks, while emphasizing that it is not an incident response company. He therefore speaks with relevant operational exposure, but also as a participant describing his own organization’s approach. His customer observations and product-related examples provide a practitioner’s perspective; the interview does not turn them into independent evaluations of effectiveness. That distinction matters when he moves from explaining a problem to recommending how businesses should spend money, delegate authority, or rebuild software.

2. What the Episode Covers

The episode’s starting point is a change in the relationship between researching an attack and carrying it out. Stamos describes the traditional sequence as finding a vulnerability, developing an exploit, and subsequently deploying it against targets. In his account, AI can bring those stages together around a live target: discover a weakness, generate exploit code, and continue the intrusion. The practical concern is the shrinking interval between encountering a system and producing an effect on it.

He illustrates the potential reach with a reported chain of compromises. Based on what was known at the time, Stamos says API keys stolen from Fireworks enabled access to Cursor, after which a malicious plugin reached approximately 5,000 additional companies. He calls these potential breaches. The interview does not establish that every company was successfully compromised. The example’s significance is the path through interconnected providers and credentials, rather than a verified final victim count.

A separate recollection connects cybersecurity to ordinary services. Stamos describes a medical and dental supplies distributor hit by ransomware, leaving dental offices canceling appointments because they could not obtain gloves and other supplies. He contrasts roughly one security employee and a ten- or twelve-person IT team with a twenty-person attacking group. Those figures describe his example of organizational imbalance, rather than a staffing ratio applicable to the whole sector. The business consequences extend beyond the organization whose computers were attacked.

Stamos then broadens the defensive agenda beyond finding bugs. By his estimate, software security accounts for about 25 percent of his own CSO responsibilities, and the remaining 75 percent has benefited less consistently from AI. He wants more attention on security operations: monitoring logs, investigating suspicious activity, deciding what happened, and responding without disabling the business. These percentages are his characterization of his job, not a measured breakdown of every security organization.

His description of a security dark age is similarly a forecast and metaphor. He expects a difficult transition, not an eventual state of permanent perfection. Some breaches do not require a software flaw, so improving code cannot close every route available to an adversary.

The conversation also considers responsibility for AI-enabled harm. Stamos supports liability when a laboratory’s own agent infrastructure directly attacks outside systems, while treating malicious users drawing on models from multiple sources as a different problem. He warns that refusals can interrupt legitimate defense because offensive and defensive work are difficult to distinguish. He would accept slower frontier progress while cheaper defensive models catch up. His broader concern is human uplift: people becoming more capable of harming other people. His criticism of friend-like AI and photorealistic companionship products extends that concern into product ethics, rather than supplying a technical explanation for network intrusions.

3. Core Views: Reasoning, Examples, and Limits

The strongest part of Stamos’s analysis is his separation of two constraints that previously limited attackers. One was expertise: a relatively small group could perform sophisticated vulnerability research and exploit development. The other was operational staffing: taking research into a campaign required people to execute it. He argues that AI weakens both constraints, distributing some advanced skills while allowing fewer operators to direct more activity. This is a change in how capability can be organized, even when an individual underlying technique is familiar.

His own qualification is essential. Stamos says he can use a desktop Mac to reverse engineer a Microsoft patch and work toward stable exploit code, but the process is not fully automatic and still requires skill. The episode therefore supports a claim about expanding access to capability, not a conclusion that any inexperienced person can reliably complete every stage of an attack. Collapsing that distinction would make his warning more dramatic and less useful.

On defense, his central criterion is whether useful capability can run at the required volume. He proposes traditional classifiers for terabytes or petabytes of logs, followed by small language models and escalation to larger models for harder investigations. The reasoning is that data volume and reasoning difficulty should not force every input through the same expensive system. A colleague’s reported price of roughly $900 for one frontier-model investigation illustrates the pressure. It is a secondhand figure for a particular product, not an industry tariff or a complete accounting of defensive costs. Stamos says Cognition is retraining open-weight models to reduce expense. The relevant comparison is cost alongside effectiveness: a powerful investigator that cannot be used frequently enough may leave much of the workload untouched.

His objection to the word swarm makes a related point about architecture. For an OpenAI-related multiagent episode, he estimates 700 to 1,400 agents and hundreds of millions of dollars in hardware; his rough electricity estimate for the Hugging Face attack is about a million dollars. He contrasts that with his judgment that the tool transcribed as Artex and similar spellings probably operates with one or two agents. These are his estimates, not audited resource accounts, and the tool name itself is inconsistent in the transcript. The analytical lesson is narrower: an expensive, inefficient multiagent event does not establish the normal cost of an attack, nor does it establish how many defensive agents an organization needs.

Economic incentives also operate inside the defender. Patel observes that prevention appears as expenditure, while restoring a damaged business has an immediately legible benefit. Stamos dramatizes the resulting delay with a hypothetical teenager buying tokens or using a gaming computer while a bank spends thirty days negotiating a contract and seeking $100 million in insurance. This is an illustration, not a documented bank incident. Its force comes from the mismatch between an attacker’s freedom to act and a defender’s process for authorizing exposure. Avoiding the risk of a test can preserve the risk that the test was intended to uncover.

Legacy software introduces a second cost comparison. From customer observations, Stamos suggests that a codebase returning around 10,000 bugs may be cheaper to rebuild than to repair individually. But his proposal depends on obtaining a working build, specifying behavior, and constructing substantial tests. A large finding count initiates an evaluation; it does not decide it. He interprets successive rounds of Linux kernel findings as evidence that better models may reveal new pools of vulnerabilities rather than steadily draining one fixed pool. The interview does not establish that this continues indefinitely or quantify the tradeoff for every codebase.

His proposed production-server kernel rebuild is the most ambitious application of that reasoning. He wants Google and Amazon to explore a safer-language implementation, discard unnecessary drivers, and preserve binary compatibility with glibc and software above it. His range of $100 million to perhaps $1 billion is an advocacy estimate, not a scoped budget. Narrowing hardware support is itself a compatibility tradeoff. He also proposes function contracts, while distinguishing them from full formal verification and acknowledging that the verification discussion exceeds his strongest expertise. None of these measures warrants a promise of absolute safety.

Finally, Stamos argues that exploitation is moving too quickly for the familiar patch-then-deploy rhythm. He describes the PHP vulnerability discussed in the episode as a fortunate near miss because practical exploitation proved difficult. That example supports reducing structural exposure before the next incident. It does not demonstrate that patching has become unnecessary; his case is for supplementing urgent repairs with changes that reduce the burden of repeatedly making them.

4. Learning and Application

A practical response begins with an authorized route to testing. Stamos recommends AI red teaming within ninety days, but this is his urgency judgment, not a universal security standard. His prediction that companies will otherwise be breached is not an independently established outcome. He acknowledges that testing can cause downtime and that a vendor’s verbal assurances may diverge from contractual disclaimers. A useful application is to agree on scope, acceptable disruption, stopping conditions, and the person who can make a business decision before testing begins. Faster authorization should make the risk explicit rather than hide it in a procurement shortcut.

Defensive autonomy needs equally concrete boundaries. Stamos describes a SOC built on Devin, connected to logs, endpoint detection and response, and cloud systems. It can disable Okta accounts, but only up to a deterministic limit; reaching the limit pages people, and further action requires approval. An organization adapting this design should specify eligible targets, action limits, escalation ownership, and the point at which automation must stop. A hard cap contains one kind of mistaken decision, but also interrupts legitimate continuing action. It therefore needs a reachable human responder, not merely an approval queue.

Automated repair should be evaluated as a chain of separate claims. Stamos says a project he is helping connects all repositories, uses Mythos and other models to find and fix thousands of bugs, writes verification tests, and merges pull requests automatically. His claim that years of human work can become days is a participant’s assessment without independent evaluation in the episode. Adopters should separately examine finding accuracy, preservation of required behavior, test quality, and eligibility for automatic merging. A generated test is evidence to inspect, not proof that the repair is correct. Faster change production is valuable only under conditions that make those changes acceptable.

The discussion of Instagram suggests another application: design for provenance instead of relying exclusively on detection. Drawing on his Facebook experience, Stamos argues that willingness to invest affects whether technical difficulty becomes a reason to stop. His proposed combination includes content detection, restricted probing of detectors, delayed enforcement, and direct camera capture. He and Patel distinguish probabilistic judgments about fabricated material from cryptographic verification of a trusted capture and custody chain. Short text, Stamos notes, offers especially little detection signal. A controlled capture-and-editing product could make narrower provenance claims, but would trade away some import and editing freedom. Proving the handling of a file does not, by itself, prove the meaning, context, or truth of the depicted event. It also cannot replace verification of a suspicious identity or payment request.

Progress measurement should preserve these distinctions. Stamos proposes tracking major breaches, wormable infrastructure vulnerabilities, and findings in components such as the Linux kernel, OpenSSL, and glibc. He reports Patch Tuesday counts rising from roughly 150–200 to more than 900 and hopes patch waves around thirty days before new model releases will shrink. These are his cited figures and proposed interpretation. Patel agrees to publish a tracker, but the episode presents no completed index. An organization borrowing the idea should examine consequences, vulnerability characteristics, and discovery timing together. More patches can reflect better discovery, while fewer patches need not establish lower underlying risk. A dashboard is useful when it makes those questions visible, rather than turning a patch count into an unexplained verdict.

Source

• Original episode: How AI is breaking cybersecurity | Decoder