Over the last year, I’ve had more conversations than I can count with developers, AppSec teams, CISOs, and platform engineers—all asking some version of the same question:
“Our pipelines look clean… so why do we still feel exposed?”
I’ve felt that tension too.
As someone who has spent years working across application security, developer platforms, and now deeply in AI security conversations, it’s become increasingly clear to me that the discomfort isn’t about tooling maturity, it’s about a fundamental shift in how software behaves.
AI isn’t just changing how we build software. It’s changing what software is. And that’s why traditional AppSec is starting to feel insufficient. Application Security followed a familiar rhythm.
Scan the code -> Fix the findings ->Patch the dependencies. Repeat.
It wasn’t perfect, but it worked because applications themselves were predictable. They didn’t think. They didn’t reason. They didn’t talk back. SAST, SCA, container scanning, dependency checks, these tools were designed for a world where applications were static and deterministic.
They were great at answering:
- Is this function vulnerable?
- Is this dependency outdated?
- Does this image contain known CVEs?
But they were never designed to answer a much harder question: “How does this system behave?”
Modern applications aren’t just AI-generated anymore. They’re AI-powered.
We’re embedding LLMs into:
- internal copilots
- customer-facing assistants
- search engines
- decision-making workflows
And once you do that, the security boundary expands fast. You’re no longer securing just:
- code
- libraries
- containers
You’re also securing:
- prompts
- training and inference data
- model behavior
- and how the system responds to real-world, adversarial input
This is where many teams start feeling uneasy—even when all the scanners say “green.”
Because the real risk often isn’t in the code. It’s in how the AI reasons.
That’s why issues like prompt injection, indirect data leakage, behavioral manipulation or hallucination-driven exposure and often never show up in a scan report. Nothing is technically “wrong” with the code. But the system is still unsafe. Also, that’s the gap AppSec teams are now staring at.
Now, we have started to see a big shift, we are moving from asking:
“Does this code compile safely?”
to asking:
“Does this AI behave safely under pressure?”
That requires new thinking, new practices, and new visibility.
One thing I keep noticing in conversations is how few organizations can confidently answer:
- Which AI models are in production?
- Where did they come from?
- What data do they rely on?
- What prompts shape their behavior?
- What licenses and constraints apply?
An AI Bill of Materials (AI BoM) is foundational here. You can’t secure what you can’t see and AI is no exception. AI security doesn’t belong in a silo.
It has to be:
- part of existing AppSec workflows
- connected to code, dependencies, and configuration
- actionable for developers and security engineers
This isn’t about replacing traditional AppSec. It’s about expanding it. Because AI isn’t replacing developers either it’s becoming part of the SDLC and AppSec engineers have to evolve with it.
The future of AppSec isn’t about choosing between traditional security or AI security. It’s about bringing them together.
In the AI era:
- scanning code is the baseline
- understanding behavior is the differentiator
- testing intelligence becomes as important as testing logic
If you’re building with AI today, this isn’t optional. It’s simply the next chapter of Application Security and like every chapter before it, we’ll adapt, learn, and build better systems because of it. What excites me most about this shift isn’t the tools or the terminology it’s the mindset change.
For the first time in a long time, Application Security is about asking better questions, not just running better scans. I genuinely believe this is a moment of opportunity for AppSec engineers.