There is a recurring question every time a new wave of AI tooling appears: will AI replace software engineers? Soon after comes another one: will AI replace security engineers?

For Product Security, I think the answer is more interesting than a simple yes or no. AI probably will not eliminate Product Security, but it will automate a significant portion of what many Product Security engineers do today. And that distinction matters.

AI Is Creating More Software, Not Less

One of the strange assumptions behind the “AI will replace security engineers” argument is that AI will somehow reduce the amount of software we need to secure. I believe the opposite is happening.

AI makes software cheaper and faster to produce. Developers can generate prototypes in hours, teams can create internal tools that would previously never have justified the engineering cost, and AI agents can write integrations, infrastructure definitions, configuration files, scripts, tests, and entire application components.

Which means one thing: more software.

And more software means:

more code → more dependencies → more APIs → more configurations → more attack surface.

The amount of code requiring security scrutiny is unlikely to decrease. It may explode. The difference is that security teams will no longer be able to review that code using the same processes they used before.

AI Introduces a New Attack Surface

AI does not just increase the volume of traditional software. It introduces entirely new security boundaries.

We now have to think about things such as prompt injection, agent authorization, agent identity, excessive agency, tool abuse, confused deputy problems, secrets exposure, AI supply-chain security, model and data poisoning, MCP security, sandboxing, privilege boundaries, provenance, and generated-code vulnerabilities.

Many of these are not entirely new security concepts. Authorization is not new. Privilege separation is not new. Confused deputy attacks are certainly not new. Supply-chain security is not new either.

What is new is the way AI systems recombine these problems in architectures where software can reason, select tools, access resources, and perform actions on behalf of users.

An LLM that only generates text has a limited blast radius. An agent that can read your repository, access Jira, query production systems, call internal APIs, retrieve secrets, and execute tools is a completely different security problem.

At that point, we are no longer discussing only model security. We are discussing system security.

And system security is exactly where Product Security should live.

The Vulnerable Product Security Engineer

There is, however, one kind of Product Security work that AI is extremely well positioned to automate:

scanner → finding → Jira ticket

If most of your job consists of running security tools, reading their output, performing basic classification, and opening tickets for developers, AI is coming directly for that workflow.

And perhaps it should.

A modern security pipeline can already run SAST, SCA, secret scanning, and IaC analysis; correlate findings from multiple scanners; remove duplicates; retrieve the surrounding source code; estimate whether vulnerable code is reachable; explain the issue; suggest a remediation; generate a candidate patch; generate tests for that patch; create the ticket; and assign it to the likely owner.

The human value in moving information from a scanner into Jira is rapidly approaching zero.

Adding an LLM to a bad vulnerability-management process does not magically create good Product Security. It just creates Jira tickets faster.

Finding Vulnerabilities Is Becoming Cheap

Historically, finding vulnerabilities required significant expertise, and that expertise created scarcity. Security engineers knew specialized tools, attack techniques, vulnerability patterns, and obscure implementation details that most developers did not.

AI is reducing that scarcity.

It can explain vulnerabilities, generate attack hypotheses, analyze source code, suggest payloads, identify suspicious data flows, and correlate enormous amounts of information much faster than a human reviewer.

So the economic value of simply finding something suspicious will probably decrease.

But finding a vulnerability was never the highest form of Product Security anyway.

The real value is understanding whether it matters, whether it can actually be exploited, what an attacker can control, what the blast radius is, which trust boundary has been crossed, what architectural decision created the problem, what the safest fix is, and how to prevent the same vulnerability class from appearing fifty more times.

That is where Product Security becomes engineering.

The Product Security Engineer I Would Bet On

Now consider a different workflow:

threat model → architectural review → exploitability analysis → mitigation design → patch → guardrail/tooling

This is a very different job.

The important question is no longer:

Is this line of code vulnerable?

It becomes:

Should this system have been designed this way in the first place?

That requires understanding architecture, trust boundaries, component interactions, attacker-controlled inputs, operational constraints, performance, usability, backwards compatibility, and engineering cost.

And sometimes the answer is not a vulnerability ticket. Sometimes the answer is to change the architecture, reduce the privilege of a component, remove access to a tool, enforce a separate authorization decision, prevent data from crossing a trust boundary, or build a guardrail so that an entire class of vulnerabilities becomes difficult to introduce again.

That is a very different kind of Product Security engineering.

And it is much harder to reduce to a scanner pipeline.

Product Security Engineers Should Write Code

There is another consequence: the Product Security engineer of the AI era should probably be more technical, not less.

Security teams will increasingly need people capable of transforming security knowledge into engineering leverage. That means writing security libraries, secure defaults, policy-as-code, CI/CD guardrails, static-analysis rules, automated code-review tooling, security tests, sandboxing mechanisms, authorization frameworks, and developer tooling.

Instead of manually finding the same vulnerability one hundred times, encode the knowledge that detects or prevents it.

If you discover a dangerous pattern during a code review, do not stop at opening a ticket. Ask whether you can make the pattern impossible, detectable, or at least expensive to reintroduce.

That is how Product Security scales.

And AI makes this approach even more powerful because security engineers themselves can use AI to build these tools faster.

From Vulnerability Finder to Security Multiplier

This is probably the transformation that matters most.

The old model of Product Security often treated the security engineer as a specialist sitting downstream of development: engineering builds, security reviews, security finds problems, engineering fixes them, and the cycle repeats.

That model does not scale particularly well today. It will scale even worse when AI dramatically increases software output.

The Product Security engineer of the future needs to become a security multiplier: someone who can take one security insight and turn it into a system-level improvement.

Find one vulnerability. Understand the underlying pattern. Fix the vulnerable implementation. Build the test. Create the static-analysis rule. Improve the framework. Change the secure default. Update the threat model. Create a guardrail.

Now the lesson from one vulnerability protects hundreds of future code paths.

That is leverage.

And leverage is precisely what security teams will need when the amount of generated software increases.

AI Does Not Remove the Security Engineer

It changes where the valuable work happens.

The security engineer who manually performs tasks that can be expressed as:

input → deterministic analysis → classification → ticket

should probably be worried.

The security engineer who operates at the intersection of:

software architecture + attacker thinking + secure design + exploitability + engineering

has a much stronger position.

AI will automate parts of that work too. Good.

Let it analyze thousands of findings, generate candidate patches, summarize dependency changes, inspect massive codebases, produce test cases, and correlate scanner output. Let it handle the repetitive parts.

Then use the freed capacity to work on the problems that actually require security engineering judgment.

Because the future of Product Security is not spending the day staring at scanner dashboards. It is helping engineering teams build systems where entire classes of vulnerabilities become harder to create.

So, Is Your Product Security Engineer Going to Be Replaced?

Maybe. But probably not for the reason people think.

The Product Security engineer who mainly operates a pipeline like:

scanner → finding → Jira ticket

is vulnerable to automation.

The Product Security engineer who works like this:

threat model → architecture → exploitability → mitigation → patch → guardrail

is not disappearing. That role is becoming more important.

AI does not reduce the attack surface. It expands it. It does not remove architectural complexity. It adds new trust boundaries. And it does not eliminate the need for security judgment.

It makes security teams responsible for protecting systems that can act, decide, retrieve, execute, and delegate at a scale we have never had before.

Finding vulnerabilities is becoming cheaper.

Understanding why a system is exploitable — and redesigning it so the vulnerability class disappears — is not.

That is the Product Security engineer I would bet on.