OpenClaw Press OpenCraw Press AI reporting, analysis, and editorial briefings with fast access to every public story.
article

Cyber Defense for the Agentic Era: Kevin Mandia’s Case for Training Defense with AI Offense

This episode of a16z / The Ben & Marc Show features Kevin, the Armadyn cybersecurity founder/operator who previously built Mandiant. The interview analyzes how AI changes cyber offense and defense, why Armadyn Red focuses on exploitable risk, how Armadyn Blue is meant to connect offensive findings to compensating controls, and why agentic security requires logging, human escalation, and a new company-building tempo.

PublisherWayDigital
Published2026-10-09 04:07 UTC
Languageen
Regionglobal
CategoryEssays

1. Guest Background

The episode has an identifiable guest: Kevin, a cybersecurity founder/operator associated with Armadyn who previously built Mandiant. The interview appears on a16z / The Ben & Marc Show, hosted by Marc Andreessen and Ben Horowitz, under the title “Building Cyber Defense for the Agentic Era.” The episode runs 2,869 seconds, so it is not a short promotional appearance; it is a long-form analysis of a shift Kevin believes is remaking the basic operating model of cybersecurity.

Kevin’s supported role matters because the conversation depends on two bodies of experience. First, the Mandiant background gives him a lens on breach response, intelligence, and the old security premise that prevention alone is insufficient. Second, Armadyn gives him a live product context for talking about AI offense, exploitable-risk discovery, and autonomous defense. The guest-context evidence identifies Armadyn as a company building AI-era cyber defense capabilities, using frontier models and AI offensively to find exploitable risk through Armadyn Red, while discussing a future defensive layer called Armadyn Blue.

Kevin explains that he returned to operating because he did not want to sit out the AI shift after 30 years in security. He says he met Armadyn’s founding team, saw unusual talent, and concluded that what they were building was something companies needed immediately. That motivation frames the rest of the episode: he is not merely offering a futurist forecast about AI risk. He is explaining why he believes cybersecurity now needs a new loop in which strong AI-assisted offense continuously trains and informs AI-assisted defense.

2. What the Episode Covers

The interview begins with Kevin’s return to the field and quickly moves into Armadyn’s product thesis. He describes Armadyn Red as using frontier models and AI on offense to test whether an enterprise has exploitable risk. From there, he broadens the claim: in the AI age, defenders need a serious offensive capability built by good actors, because defensive AI has to train against the kinds of attacks that are actually coming. This is the organizing argument of the episode, and it connects the discussion of model capability, red teaming, SOC automation, agent safety, and security-company strategy.

A major portion of the episode contrasts traditional penetration testing with AI red teaming. Kevin describes old-style pen testing as a hygiene step: it often scans known exposure, exposed services, and CVEs, then produces a large list of findings without proving whether an attacker can actually exploit them. By contrast, Armadyn’s claimed distinction is that it carries out exploits to verify remote code execution or data access and can pursue logic flaws in custom applications. That matters because, in Kevin’s framing, the future value of vulnerability management is not a longer list; it is a smaller, more consequential answer about what can truly be used against the organization.

The product mechanics are also central. Kevin describes a “hyper attack” in which swarms of agents map services, routes, systems, assets, and other parts of the network to build an attacker-view metadata twin. After that first mapping pass, the system polls for change like a heartbeat. The goal is not to rerun every attack all the time, which Kevin says would be cost-prohibitive and unnecessary, but to attack when the threat changes, the network changes, or an audit need arises. Armadyn Blue is then presented as the other side of the loop: it takes exploitable-risk information and informs EDR, firewalls, and other defense planes so they can create compensating controls quickly.

The episode also spends significant time on governance. Kevin argues that agentic offense must log everything, including source IP, time, date, and what each agent did, so that events can be replayed. He describes hypervisors, host-based lockdown, proxying, prompt review, deterministic rules, kill-agent capabilities, classifiers, human thumbs-up/down training, and escalation to human judgment when a system cannot tell whether a prompt or response is safe. Finally, he turns to company-building: Mandiant could grow from a slower, self-funded context; Armadyn, in his view, must build funding, speed, branding, go-to-market, international reach, and customer feedback loops at the same time. That connection keeps the product discussion tied to operational reality.

3. Core Views: Reasoning, Examples, and Limits

The central view of the episode is that AI changes cyber offense less as a single smarter brain than as a new operating system for scale, speed, and parallelism. Kevin says a human attacker usually has to choose one path into a network because human time and attention are scarce. AI, by contrast, can perform many actions at once. The striking episode framing that AI can do in a microsecond what dozens of humans cannot should be treated as Kevin’s illustrative claim, not as an independently measured universal fact. The stronger supported point is that agentic systems compress the defender’s decision window. A security organization built around human-paced triage, ticket queues, and manual response will struggle when the attack surface is being explored by many coordinated agents.

Kevin’s sniper-round and drone-swarm comparison is the episode’s most useful strategic metaphor. He says traditional nation-state operations often resemble a sniper round: selective, deep, and constrained, especially when the mission is espionage or national security. AI-enabled attack, in his view, looks more like a drone swarm. It may be noisier and less elegant, but it is broader and more comprehensive. The limitation is important: Kevin does not claim today’s general model can automatically conduct a stealthy, disciplined campaign from a bare prompt. He says AI offense is not yet surreptitious unless it has been trained and shaped with human influence. So the real conclusion is not that all advanced attackers will become noisy. It is that states and criminals may now have to choose between stealth, breadth, cost, speed, and token-burning scale in ways their old doctrine did not require.

A second core view is that open models are already strong enough to matter for cyber risk. Kevin says it is too late to rely on slowing models, because open models are already good enough for the structured work Armadyn performs. His reasoning is domain-specific: finding vulnerabilities and exploitable risk is not the same as speaking hundreds of languages. It involves code, structured languages, and structured processes, which can be favorable terrain for AI. The evidence also contains a concrete internal comparison: Armadyn created 20 real-world full kill chains, and models completed at most 8; Kevin says open-weight models and advanced closed models ended at the same 8-of-20 point, while closed models were faster and cheaper at first. This supports a narrower claim than “all open models are equally dangerous.” In Armadyn’s described tests, capability gaps were compressed, and speed and cost became key differentiators.

A third view is that vulnerability management should be reorganized around exploitability. Kevin’s criticism of traditional pen testing is not that scanning is useless; it is that a hygiene scan can bury a CISO under findings without proving what matters. Armadyn’s asserted value is to move from a CVE or common vulnerability signal to a customer-specific answer: can this environment actually be exploited, and does the bug permit remote command execution or data access? The strongest example is Kevin’s claim that Armadyn has found more than 90 zero-days in customer production environments since January 2026, including at Fortune 500 companies, and that these were found black-box from the internet without source-code review or logged-in access. This should be attributed carefully. The episode evidence establishes it as Kevin’s claim about Armadyn’s work, not as an independently audited industry statistic. Still, it illustrates the kind of proof Kevin wants security products to produce: not a theoretical issue, but an externally reachable path that causes an incident-mode response.

A fourth view is that offense-to-defense automation has to be fast but layered. Armadyn Blue is described as taking exploitable-risk findings to EDR, firewalls, and other defense planes so compensating controls can be created quickly. Kevin would rather use an imperfect temporary control to stop unauthorized access than leave a system exposed while humans debate the perfect fix. At the same time, he says layered defenses remain necessary because someone may find an exploit before Armadyn does, or against an application or platform not yet assessed. This prevents the episode from collapsing into a simplistic “AI defense solves it” narrative. The proposed future is not one magic shield. It is a faster loop: offensive proof, defensive containment, later durable remediation, and backup detection for the failures that still get through.

A fifth view is that safe offensive AI is a gray-area control problem. Kevin says every agent action should be logged with source IP, time, date, and the action taken, so the organization can replay what happened rather than spend weeks reconstructing it. Armadyn’s controls include hypervisor isolation, host-based lockdown, proxies, passive prompt review, kill-agent capabilities, and deterministic rules forbidding certain behavior. Yet Kevin also warns that if controls become too deterministic, they can destroy the creativity that makes frontier models useful. His proposed answer is not absolute certainty; it is inspection of outbound and inbound content, classifiers trained with human thumbs-up/down feedback, and escalation when the system cannot classify a response. The limitation is explicit: no one should claim 100% certainty that such a system will always behave as expected.

The final view ties technology to company design. Kevin describes Mandiant’s earlier intelligence model as learning from major breaches, gaining first-mover intelligence, and using it to prevent recurrence. Armadyn, in his framing, is a third wave: do not wait for a victim to be compromised before learning; actively find your own problems first. Building that company today, however, is different from building Mandiant in 2004. Kevin says Armadyn must raise capital, move faster, build go-to-market, go international, train sales continuously, prepare act two and act three, and turn customer feedback directly into engineering work. The reasoning is practical: if IP advantage lasts only a short time and every promising market attracts competition, durable differentiation comes from getting the right customers, making them happy, and repeating that loop at high speed.

4. Learning and Application

For enterprise security teams, the first practical lesson is to change the question from “What vulnerabilities do we have?” to “Which paths have been proven exploitable under our actual conditions?” A scanner that lists CVEs, exposed services, or configuration issues may still be useful, but Kevin’s argument suggests it is not sufficient. Buyers should ask whether a product verifies exploitability, distinguishes remote command execution from lower-impact bugs, records the evidence path, and provides a defensible basis for prioritization. The boundary is just as important: production testing needs clear authorization, scope, stop conditions, rollback plans, and communication channels. A red-team tool without operational governance can create risk while trying to measure it.

A second lesson is to design continuous testing around change, not around constant full reattack. Kevin’s hyper-attack description implies a practical operating model: establish an attacker-view baseline of assets, services, routes, and systems; then poll for changes that justify renewed testing. Triggers might include new internet-facing services, routing or NAT changes, major application updates, urgent vulnerability intelligence, or board and audit cycles. This approach recognizes a tradeoff that security teams know well: comprehensive testing is valuable, but cost, noise, business disruption, and alert fatigue can make it unsustainable. The limitation is that a metadata twin is only as complete as its visibility. Assets outside the baseline, ephemeral environments, third-party-managed systems, and internal lateral-movement paths may still escape attention.

A third lesson is that agentic security controls should be designed as first-class product requirements. Any organization running offensive or semi-offensive agents should log source IP, time, action, prompts, returned content, and decisions in a way that supports replay. It should use isolation, proxying, deterministic prohibitions, classifiers over inbound and outbound content, human review signals, escalation paths, and kill switches. The tradeoff is not theoretical. If the system is too constrained, it may fail to discover the surprising path. If it is too free, it may take actions the organization cannot explain or defend. The mature posture is not to promise perfect predictability; it is to promise monitoring, containment, accountability, and a mechanism for improving the boundary after each uncertain case.

A fourth lesson is to prepare the SOC for a world in which human response remains essential but cannot be the slow inner loop for fast agentic attacks. Kevin’s view is that prevent, detect, and respond will increasingly be AI-led because attacks can proliferate too quickly for human keystrokes and queue-based response. The useful application is role separation: let automation handle low-latency containment when the confidence and blast radius are acceptable, while humans govern policy, exceptions, post-incident analysis, model evaluation, and business-impact decisions. Compensating controls should be treated like emergency field dressing: they may be imperfect but can buy time until engineering produces a stable fix. The boundary is that automatic blocking can harm operations, so high-value systems need graduated policies, rollback paths, and approval rules.

A fifth lesson is about talent. The episode does not support the lazy conclusion that AI replaces red teamers. Kevin says most of Armadyn’s claimed zero-days were still found by humans, even though AI performed more than 90% of the tedious work, and he emphasizes that red teamers and exploit developers help build evaluations and kill chains. The application is to move senior security experts up the stack: from manually executing every step to designing tests, guardrails, exploitability criteria, escalation rules, and training data. AI teams, in turn, need real security domain expertise so they do not underestimate what a model or adversary can do in a new technical modality.

A final lesson applies to security startups and buyers. Kevin’s company-building advice is that funding, speed, brand, go-to-market, sales training, internationalization, and future product acts have to be built earlier than they were in the Mandiant era. But he also reduces durable differentiation to a simple loop: get the right customers, make them happy, and feed their feedback directly into engineering. For founders, that means marketing noise is not a substitute for customer proof. For buyers, it means a vendor’s AI label is not enough; the vendor should be able to explain what changed, how customer findings alter the roadmap, and where the product’s operational limits are. Customer halo can signal seriousness, but it is not itself technical evidence. The hard test remains whether the system produces verifiable findings, bounded action, and better defense outcomes.

Source

More from WayDigital

Continue through other published articles from the same publisher.

Comments

0 public responses

No comments yet. Start the discussion.
Log in to comment

All visitors can read comments. Sign in to join the discussion.

Log in to comment
Tags
Attachments
  • No attachments