Has AI made security easier?

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:

Support me with a paid subscription

I thought about what picture to choose for this week’s post, and I chose a pristine, perfectly organized desk environment. It represents a calm, orderly state of operations. This is the exact environment that all security practitioners wish for in their networks, but sadly, nothing could be further from the truth when you look at actual AI-native companies. In the real world, things are inherently messy, fluid, and chaotic. Modern security teams have to spend the majority of their cycles figuring out highly creative ways to keep their systems clean, predictable, and tidy.

Last week, I discussed why it is so critical for security vendors to focus on winning AI-native customers, even if that market segment feels small today.

The reason this design partner matters is because the broader market will inevitably inherit these exact same operational needs in the near future. To build a product for the future, you have to understand the frontier today. One of the core insights from observing these AI-native organizations is that they don’t just stack new AI tooling on top of a 2010 corporate blueprint. They are structured materially differently from traditional companies in order to maximize their engineering velocity.

Before talking about how AI makes security easier, we have to acknowledge the elephant in the room. I regularly see an endless stream of articles and social media posts detailing how AI is creating unprecedented security headaches and making life miserable for defensive teams. To a certain extent, I completely agree with that perspective.

The widespread availability of LLMs has allowed non-engineers and non-technical business units to spin up autonomous applications. These users do not understand basic cloud permissions, data lifecycle management, or identity boundaries. Because the race to deploy AI features has been so heavily rushed, these internal toolings are being rolled out with almost zero traditional guardrails. Honestly, as an industry, we haven’t even fully figured out what guardrails we should be enforcing, or what level of autonomy we should grant an internal agent.

Two distinct characteristics make this problem incredibly difficult to solve, and they compound on top of each other. First, the underlying frontier models change completely every few months. Second, the inherent non-determinism of LLMs means it is nearly impossible to predict how a model will behave when hit with an unexpected edge case. Nothing bothers an enterprise security team more than a lack of predictability and unmapped edge cases.

When you layer this unpredictable technology on top of a corporate culture, it naturally leads to blazing fast operations and hyper-accelerated development. This velocity compounds basic configuration mistakes. Running autonomous agents without guardrails is a clear recipe for operational disaster. But building rigid boundaries around a moving target requires immense, continuous engineering effort. While I firmly believe security teams must learn this skill to survive, I recognize that dedicating a full team to chasing model drift simply isn’t feasible for most lean organizations.

However, if you look past the initial noise of model vulnerabilities, the massive structural benefits of AI become clear. I wrote about the early philosophical markers of this shift over a year ago, back when frontier models were significantly less capable than they are today.

Over the last six months, autonomous AI agents have crossed a critical capability threshold when it comes to writing code. It is now entirely possible to execute complex, end-to-end infrastructure development simply by prompting an agent, requiring little to no manual typing from the engineer. This is the day-to-day reality inside AI-native companies.

Despite the skepticism of old-school purists, these agents generate surprisingly high-quality code. The trick is understanding that it is rarely a one-shot process. Achieving an enterprise-ready result requires a continuous, iterative conversation with the agent to refine the logic and catch anomalies. But even with that back-and-forth iteration loop, the timeline is orders of magnitude faster than writing everything out manually line by line, or assigning the task to a junior engineer who has to spend three days reading documentation. When you wrap an AI agent in the proper testing harness, it speeds up engineering velocity exponentially.

The security value here is profound: AI has made doing anything in code substantially easier. While there are a million tactical examples of this, like spinning up python scripts to clean and normalize messy security logs, the most massive structural win is occurring in infrastructure security.

I might be biased here as someone who has spent their career working hand-in-hand with infrastructure and platform teams, but cloud deployment has historically been defined by a brutal tradeoff between velocity and security.

When a product team needed to ship a feature fast, they went into the AWS or GCP cloud console and manually clicked buttons to spin up databases, storage buckets, and IAM roles. This was fast, but it was a nightmare for security. Manual console configurations leave no paper trail, cannot be audited efficiently, and inevitably lead to severe configuration drift and orphaned, public-facing assets. Security teams tried to fix this by mandating Infrastructure as Code (IaC) via Terraform. But writing clean, modular Terraform files manually is tedious and confusing, turning the infrastructure team into a massive bottleneck that slowed down the entire business.

AI completely breaks this deadlock. Writing declarative Terraform code via an agent like Cursor or Copilot is now significantly faster and more convenient than clicking through a cluttered web console. The beauty of this shift is that product teams can now generate a very solid, usable first version of their own infrastructure files without the organization needing to put them through intensive, specialized IaC training.

Because of this, there is officially no longer any valid reason for a product engineer to have admin or write access to the cloud console. Permissions should be completely revoked. If an organization shifts to an AI-assisted Git workflow, the console should become a read-only environment.

This architectural change frees up the infrastructure and platform security teams. Because they are no longer burdened with the constant, traditional operational work of manually provisioned resources, they actually have the bandwidth to respond to real production emergencies better. Terraform becomes the frictionless default because product teams can generate their own pull requests automatically.

Instead of gatekeeping deployments, infrastructure teams can focus their cycles on building specialized AI audit agents to programmatically evaluate these generated PRs in CI/CD before they hit production. It eliminates a massive point of friction: forcing platform infrastructure experts to play support desk for product engineers who barely know how to write a configuration block. That old setup was painful and inefficient for both sides. AI has made security easier by aligning the developer’s path of least resistance with security’s gold standard.

Beyond infrastructure, this code-generation capability completely redefines the scalability of product security reviews. Historically, a traditional product security review required a highly specialized engineer to sit down with a development team, manually gather context on how a new feature worked, read through thousands of lines of undocumented code, and guess where the architectural flaws might live. It was completely unscalable.

AI allows security teams to automate the first-pass contextual review. Out of the box, an LLM is exceptionally good at parsing an entire repository, mapping data flows, and generating a highly accurate summary of a feature’s architecture.

The challenge isn’t the raw engine; it’s how you feed it internal business context. Security teams are scaling these workflows by defining explicit, comprehensive context files directly inside the codebase. This includes everything from markdown files mapping out internal data classification tiers, to prompt libraries that explicitly dictate how authentication must look across microservices, to architecture-as-text patterns.

Of course, context codebases suffer from drift just like any other software component. If left unpruned, outdated documentation will lead to model hallucination or missed flaws. In an AI-forward organization, keeping this context clean is a shared responsibility owned by both security and engineering. This completely kills the traditional “us vs. them” organizational ownership battle. Because security teams now have the programmatic capacity to scale alongside engineering instead of being buried under a mountain of manual tickets, they can collaborate directly with product developers to continuously maintain the accuracy of the context layer.

This framework allows product security to scale across hundreds of developers without adding headcount, removing baseline architectural risks automatically. Crucially, it changes the talent profile required to do the job. Because the AI can instantly summarize and explain complex, undocumented code blocks, you no longer need an engineer who spends hours debugging syntax. You can deploy a high-level, strategic security thinker who excels at threat modeling, even if they aren’t a native coder, because the AI acts as their implementation translator.

The emergence of terminal-native coding agents like Claude Code pushes this engineering-centric evolution even further, significantly collapsing our historical Time to Remediate (TTR). Historically, product security teams existed merely to find flaws, write reports, and assign tickets to engineers who would fix them weeks down the line. Today, with an autonomous agent inside the terminal, security practitioners are empowered to actively generate, test, and ship the code fixes themselves.

However, this structural shift creates a brutal internal talent filter. It heavily favors a very specific profile: security professionals who possess genuine, foundational software engineering skills.

If a practitioner does not understand core application logic, dependency structures, and CI/CD parameters, they cannot safely guide an autonomous agent to patch a production repository. Organizations face a sharp fork in the road. They must explicitly develop this technical talent internally and foster a deep culture of engineering-level ownership within the security organization. If security teams refuse to upskill, they will be left behind completely. Because software engineers are already using these identical AI tools to write code at blistering speeds, they will naturally absorb the security function themselves if the security team remains an administrative roadblock. Either way, deep software engineering competency has officially become a necessary baseline for defense.

This architectural shift fundamentally redefines how we measure a successful security organization. We are moving away from traditional, useless operational metrics—like the total number of security reviews completed per quarter or the volume of tickets logged in a dashboard. Those were checkboxes for a bloated organization.

Instead, AI is pushing the industry toward focused outcome metrics that demonstrate true, engineering-level ownership—something security teams haven’t had in a long time. We should be looking at core engineering metrics to evaluate security performance:

• Change Failure Rate (CFR) for Security Infrastructure: How often does an automated infrastructure deploy or security guardrail trigger a production rollback or incident?

• Lead Time for Secure Changes: How quickly can a lean team safely provision a brand new, fully compliant infrastructure component from prompt to production block?

• Context Test Coverage: What percentage of our code repositories are backed by verified, up-to-date security context files that feed our autonomous audit agents?

Ultimately, by drastically lowering the friction to write secure code and analyze system architecture, AI removes the operational variance that creates risk in the first place. Security teams need to stop viewing AI as a wild, unmanageable threat surface, and start leveraging it as the ultimate engine for structural consistency. It is how a remarkably small team can unblock an entire business and ship highly secure products in lockstep with engineering.