Why AI has made security hard
An honest, non-rant-y assessment
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:
This is an atypical newsletter for me because I always try to take a somewhat contrarian approach and avoid the easy path. But I do think a balanced, deeply pragmatic view is required when we look at exactly how artificial intelligence has disrupted enterprise defense. I recently wrote about the flip side of this coin, tracking the specific ways that AI has actually made security a lot easier for lean teams. In general, I’ve also talked about how security has, in many ways, become easier.
But I am a pragmatist, and I realize that nothing in engineering comes for free. When technology shifts, our problems don't magically disappear; they simply change shape and migrate to a different layer of the stack. It is only natural that the rapid democratization of LLMs and autonomous code agents has made security intensely more difficult in several distinct ways.
Unlike the endless stream of lazy think-pieces filling up social media feeds, I am not here to rail against AI or complain about the volume of model slop entering the ecosystem. I am incredibly biased in favor of this technology. I use it daily, I believe it is structurally transformative, and it is undeniably here to stay.
It has been a while since I sat down to break down the mechanics of why security is inherently hard. To understand the true threat landscape of 2026, we have to look past the superficial vulnerabilities and dissect the structural and organizational bottlenecks that are quietly fracturing security teams.
The experimentation entitlement
The actual day-to-day difficulty of securing AI varies wildly depending on the maturity of the company. Perhaps this is an obvious observation, but security is exponentially harder at companies that are still in the frantic experimentation phase than at enterprises with a mature, established AI infrastructure.
Mature companies have learned the hard way that the benefits and systemic risks of AI are variable. They understand that every single deployment requires an intense look at the data lineage, model boundaries, and runtime execution layers. They know how to calculate whether a specific security trade-off is worth the operational friction.
Companies stuck in the hyper-optimistic experimentation phase operate under a dangerous delusion of entitlement. Because their leadership believes the immediate macro benefits of AI automatically outweigh any abstract downstream risks, they demand completely unfettered access to the technology.
In practice, this doesn’t just mean developers installing unvetted IDE extensions or running local model variants on their laptops. It spreads across every single non-technical department in the business. You have finance teams plugging proprietary revenue models into third-party consumer playgrounds just to see what happens, and HR teams uploading sensitive employee tracking sheets to external tools without checking data retention policies.
These teams want the full experience instantly, and they treat any security boundary as an existential threat to company velocity. They want to open the floodgates and give every internal application access to everything, completely rejecting the idea that an AI’s data access should be explicitly gated. Crafting proper, granular identity and access controls requires deep technical nuance and immense clock time, i.e., luxuries that optimistic, speed-obsessed organizations refuse to waste resources on in the short term. By chasing a frictionless user experience, they build a massive mountain of structural risk before they even ship their first production feature.
The asymmetry of failure
This friction exposes the stark asymmetry of failure that exists between a security organization and an AI adopter. Consider how a modern engineering or product team evaluates an autonomous agent. If they deploy an internal agent that successfully auto-patches a repository or resolves a customer ticket 90% of the time, they view that as an absolute triumph. To a product manager, a 10% hallucination or error rate is simply a tolerable cost of doing business at machine speed.
But for a CISO, that 10% variance represents a catastrophic structural vulnerability. We are playing a completely different game with an entirely distinct set of rules. The goal of security is the absolute prevention of systemic failure. In our world, it only takes one single unmapped failure or one hallucinated access boundary to trigger a public data exposure, a devastating breach, or an unrecoverable operational incident.
Product-facing organizations can experiment endlessly because they only need to succeed one major time to prove their value and win the market. Ironically, this is the exact same operating model used by malicious attackers. An adversary can fail a thousand times, but they only need to find one loose prompt configuration or one over-permissioned service account to win. Security teams are trapped in the middle, forced to defend a massive, non-deterministic surface area where they have to be right 100% of the time while their own internal engineering teams are actively weaponizing the architecture with unpredictable, variable software.
The calculator dilemma and compounding debt
A common misconception among executives is that AI is creating entirely new categories of exotic cyber threats. In reality, AI rarely invents a novel vulnerability out of thin air. Instead, it acts as a massive force multiplier for your existing bad habits, poor architectural practices, and latent technical debt.
An AI application behaves exactly like a calculator. A calculator is only as smart as the human inputting the equations. If you input the wrong numbers, the machine will give you an incorrect answer with absolute certainty, performing the flawed calculation orders of magnitude faster than a human brain ever could. AI applies this exact same mechanical acceleration to software engineering. If your development team already has messy IAM configurations, poor code review discipline, or zero dependency management, throwing AI into the pipeline will magnify those subtle flaws instantly.
When humans write code manually, certain subtle architectural bugs remain isolated because human output is naturally constrained by time and cognitive bandwidth. An AI agent, however, doesn’t judge quality. It doesn’t look at a loose permission setting and think about the security implications; it simply replicates that pattern across hundreds of microservices in a matter of seconds. It uncovers latent infrastructure flaws and creates massive system sprawl before a human security engineer can even parse the initial commit log. Attackers are leveraging these exact same speed dynamics, using automated tooling to map and exploit this machine-generated sprawl faster than traditional defensive teams can react. It is an exhausting uphill battle against an automated calculator that is constantly running the wrong numbers.
The great CISO bifurcation
Because the underlying technology is moving too fast for traditional defensive frameworks, we are witnessing a massive, painful restructuring of the traditional security organization. Historically, the vast majority of security teams were built around a compliance-first mentality. They were established as administrative bodies designed to check boxes, gather audit logs, and satisfy external customer requirements. Even if a company managed to hire a few highly technical security engineers, the compliance engine always ended up swallowing the operational budget.
But as AI completely flattens the software development lifecycle, engineering teams are becoming intensely more empowered. Security can no longer manage risk through administrative policies because the technical drift between what compliance tracks and what engineering deploys is widening into a chasm.
To bridge this gap, the traditional corporate CISO role is actively fracturing into two distinct personas. On one side, the compliance-focused CISO is being rebranded as a Chief Compliance or Trust Officer, tasked exclusively with managing the brutal, paperwork-heavy external audit cycles. On the other side, companies are bringing in true engineering leaders to function as technical CISOs, individuals who have spent their careers inside repositories and explicitly understand platform architecture.
A brand new security engineering team is emerging as a critical buffer between these two worlds, designed to translate compliance requirements into programmable code guardrails that engineering can actually ingest. While this organizational change is undeniably necessary for the long-term health of the industry, it is making the day-to-day job of security incredibly chaotic in the short term. It introduces massive process confusion, upends traditional escalation pathways, and leaves the compliance-focused practitioners with significantly less organizational leverage and fewer resources than they possessed under the old model.
The market opportunity for compliance transformation
This organizational disruption highlights a fascinating, wide-open market opportunity for next-generation security startups. Right now, the vast majority of AI security vendors are suffering from massive tunnel vision. They are entirely focused on building advanced orchestration tools and agentic platforms to accelerate the work of the elite, engineering-focused security teams. But those engineering teams are already hyper-capable and slammed with core product work.
The massive, unserved market belongs to the vendor who can build software that helps the legacy, compliance-focused security team use AI to transform themselves into a modern engineering unit.
This is an incredibly difficult product to design, and it is still entirely unclear what the winning user interface will look like. But if a startup can figure out how to ingest messy, text-heavy regulatory frameworks and automatically output elegant, version-controlled context files and policy-as-code configurations that align with developer pipelines, they will unlock an elite category of enterprise spend. It is the exact same architectural playbook that Snyk used to bridge the gap between developers and AppSec, and that Wiz used to turn complex cloud infrastructure into an easily prioritized risk graph. The founder who builds the translation engine for the compliance chasm will define the next decade of enterprise security software.
Ultimately, AI has made security harder because it has stripped away the illusion of control. We can no longer hide behind static policies, slow release cadences, or manual gates. The machine of the enterprise is moving at runtime speed, and if our defensive frameworks cannot scale to manage the velocity of our own calculators, we will be left guarding an empty perimeter.