What I'm thinking about going into Blackhat/Defcon
It's going to be a different experience for me
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:
I’ve been buried in a mix of work projects and heavy travel over the last few weeks, which means I’m a bit behind on newsletter posts. I briefly thought about re-posting an older essay, but I couldn’t find one that felt right. I’d much rather take the extra time to bring you a fresh, timely perspective.
Next week, I’m heading to Las Vegas for Hacker Summer Camp, specifically Black Hat USA and DEF CON 34.
This trip looks slightly different for me than in years past. I haven't done the full dual-conference marathon, attending both Black Hat and DEF CON in one stretch, since my venture capital days. Back when I was on the investor side, my schedule was overwhelmingly tilted toward Black Hat: back-to-back vendor meetings, pitch decks, and executive suites, with maybe a quick afternoon walk through the DEF CON vendor floor. Later in my career, the pendulum swung completely the other way. I spent almost all my time steeped in DEF CON’s technical tracks, making only brief appearances at Black Hat.
This year, I’m tackling the entire week. I plan to spend the first half at Mandalay Bay for Black Hat before shifting gears over to the Las Vegas Convention Center for the full DEF CON experience. I know I’ll probably be exhausted by Sunday, but I’m deliberately taking this dual approach to report on a specific dynamic I’ve been tracking: How the rise of the technical practitioner is changing how security value is built, sold, and evaluated.
The split lens: Black Hat vs. DEF CON
We all know the traditional dichotomy between these two events. Black Hat is the commercial, CISO-heavy venue packed with polished pitch decks and vendor booths selling enterprise silver bullets. DEF CON is the hands-on, practitioner-led floor where people actually pull apart systems, write exploits, and demonstrate real fixes.
What makes 2026 fascinating is how much the narrative around AI has evolved over the past six months. We’ve watched the public rhetoric cycle move rapidly from “AI will automate security away” to “AI is full of dangerous slop” to the current reality: AI is an execution engine that only works if the person operating it deeply understands application architecture.
I expect to see this contrast clearly in Vegas:
At Black Hat, the focus will likely remain on higher-level positioning: vendors selling autonomous AI SOC analysts, prompt-firewalls, and productivity platforms promised to boost CISO output.
At DEF CON, the conversation will shift from abstract risk to tactical execution: red teams demonstrating prompt-injection chains against live production agents, blue teams building open-source context engines, and practitioners analyzing real-world model failures.
The gap between these two conversations will expose who has actually operationalized AI versus who is merely buying wrappers.
Evaluating tools in the AI era
When walking the Black Hat floor, people always ask how I separate real products from hype. The reality is that it’s rarely something you can judge from a marketing slide. I usually have to see a live demo, and then I immediately reach out to my network of security peers at AI-native companies to understand how the software actually behaves in production.
Crucially, I don’t subscribe to the purist idea that a product being a “wrapper” is inherently bad. It is completely fine if a tool relies on underlying frontier models, as long as it delivers an exceptional, low-friction product experience.
The real diagnostic question is whether the vendor is solving a problem I actually care about in an AI-forward way. An AI-native security tool should eliminate administrative friction, not add to it. I don’t want to log into another bloated web dashboard every morning to manage alerts; I want a tool where I can interact with a conversational interface or agent to handle investigations, trigger audits, and query telemetry naturally. Platforms like RunReveal and Formal are great examples of software moving toward this frictionless, conversational reality. I’m curious to see how many vendors at Black Hat have actually embraced this product philosophy, rather than just slapping an LLM chatbot on top of a 2010 enterprise dashboard.
The practitioner hive mind
On the flip side, when I head to DEF CON, I don’t anchor myself in a single technical village or stick to a pre-planned schedule. I approach the floor with the goal of absorbing organic insights across the entire ecosystem.
Security is fundamentally a team sport. The threat landscape moves too fast, and the technical surface area is too vast for any single engineer or CISO to figure out everything in isolation. Knowledge sharing is the true engine of defense. I go to DEF CON to absorb the creative edge cases and defensive patterns that I haven’t thought of yet, learning directly from the practitioners who are testing the boundaries of model behavior and cloud infrastructure.
This hive-mind dynamic is where the real value lives. However, it also highlights a growing organizational gap. At DEF CON, you constantly hear practitioners complain that executive leadership doesn’t understand the day-to-day realities of modern software engineering. As development velocity accelerates through AI coding agents, traditional security teams that rely on gatekeeping are getting left behind. Organizations struggling with this transition don’t just need new tools; they need structural resets in leadership. To retain top technical talent, companies must empower leaders who speak the language of builders.
Building for the “day-one” security team
Historically, early-stage startups avoided hiring dedicated security professionals until they hit scale or faced immediate enterprise deal-breakers. Security tools were built almost exclusively for large enterprise accounts with massive budgets, leaving the early-stage market underserved. It’s a dynamic that platforms like Huntress famously proved was a massive, overlooked opportunity.
Today, I’m seeing a distinct shift: companies are looking to hire their first security engineer much earlier in their lifecycle.
In an AI-native environment, a 10-person engineering team can ship the volume of code that used to require 50 developers. Because technical debt and architectural drift compound at machine speed, waiting until Series B to think about application state or identity boundaries is a massive risk.
As I’ve written about before, this early-hire profile looks fundamentally different today. Startups don’t need a traditional risk manager or compliance officer who manages spreadsheets; they need a technical generalist and a builder. They need an engineer who can write code, establish programmatic guardrails, configure cloud infrastructure, and build the foundational security context alongside product developers.
This early-stage market is significantly more lucrative than traditional SMB because these high-growth startups hold real budget and deploy modern cloud infrastructure. But traditional enterprise security tools don’t work for a solo security engineer. They need programmable, low-friction infrastructure tools that integrate directly into their CI/CD pipelines.
The Ultimate Reset
Ultimately, the practitioners will win out.
Executives are increasingly realizing that non-technical leaders who manage headcount from a distance cannot keep pace with machine-speed engineering. We are returning to an era where technical competency is a baseline requirement for security leadership. The most effective security leaders will be the ones who can go deep into the stack, build automated guardrails, and enable engineering velocity.
Products alone won’t solve the structural changes facing our industry. The most interesting work is happening at fast-growing companies where technical arguments drive architectural decisions. I’m looking forward to spending the week in Las Vegas testing these hypotheses on the ground, and I’ll be sharing my takeaways and field notes right here on the blog.