Why AI Security Is Just Application Security

When I started in this field twenty years ago as a software developer, the threat model was simple. One person wrote the code, and another person reviewed it. That balance is now gone. After leading a global software security community for many years, I have learned that the hardest change is not buying a new tool. It is helping engineers accept that application security now has to fight on two fronts at the same time.

The first front is using AI to defend our software. My teams use AI assistants to review findings, build threat models, and write safer code, and they work faster than any manual review. But there is a clear risk. AI writes code faster than our checks can read it, and "the assistant wrote it" has become the new version of "it compiled." Speed without proof of where the code came from is still risk.

The second front is protecting the AI itself. Securing a retrieval system or an agent-based application breaks many of the rules our older tools were built on. A prompt injection attack is not a memory bug. An agent with too many permissions is not the same as a badly set storage account. When I work with red and blue teams, the real weaknesses sit in places our scanners were never built to see.

My view, after building these programs, is simple. We should stop treating AI security as a separate field added on top of application security. It is application security. The questions are the same. Can we trust the input? Do we give only the access that is needed? Can we prove where things came from? The only new part is that the system no longer behaves the same way every time. Leaders who wait for tools to catch up will protect yesterday's software while shipping tomorrow’s.