Why Classic Cybersecurity Doesn't Protect AI Systems

Every second company that has deployed an AI agent or a language model protects it exactly like an ordinary microservice: with a firewall, a dependency scanner and an access policy. It sounds reasonable, but in practice it is like installing a steel door in a house that is missing a wall. Boris Matsakov, a Data Science engineer at Cloud.ru, put his finger on a problem the industry still prefers to ignore in his analysis on Habr: classic DevSecOps and AI security are two different perimeters, and one does not replace the other.

The core of the divergence is simple and fundamental. DevSecOps was built over decades around a well-understood threat model: there is a perimeter, there are dependencies, there is infrastructure and there are access rights. Secure each of these layers and the system is safe.

But AI models are attacked in a completely different way. Prompt injection lets an attacker take control of a model's behavior through specially crafted text. Poisoning of training data distorts the model's decision-making logic long before it reaches production.

Context manipulation makes an AI agent perform actions its creators never anticipated. None of these attacks touches infrastructure in the traditional sense. They hit what makes AI intelligent: the data and the model's ability to interpret it.

The problem is especially acute with agentic systems: autonomous AI agents that do not merely generate text but make decisions, call external APIs, work with databases and execute chains of actions. If an ordinary language model can loosely be compared to a consultant who gives advice, an AI agent is an employee with access to corporate systems. Compromising such an employee through prompt injection means getting not just a wrong answer but real impact on business processes. And infrastructure protection is powerless here by definition: from the firewall's point of view, the agent does exactly what it is allowed to do, sending requests and receiving responses.

The good news is that the industry is not standing still. Over the past year and a half, several serious frameworks have emerged that make it possible to build a practical defense. OWASP has released two separate Top 10 vulnerability lists, one for LLM applications and one for agentic systems. Google introduced SAIF, the Secure AI Framework, with a risk map that helps companies assess threats systematically. MITRE extended its renowned ATT&CK knowledge base into the ATLAS project, which catalogs attack techniques specific to machine learning systems. Each of these tools fills its own niche: OWASP provides a checklist of concrete vulnerabilities, SAIF a risk assessment methodology, and ATLAS a language for describing attacks and building threat models.

The bad news is that a single standard still does not exist. There is no "GOST", no ISO standard, no mandatory framework that prescribes a specific set of measures to companies. Each team interprets "a secure AI system" in its own way, and that interpretation often boils down to what the in-house DevSecOps engineers already know how to do. This creates a dangerous illusion of security: formally, every procedure is followed, the scanners are green, access is segregated, yet the model remains vulnerable to attacks the security team may not even suspect.

The practical takeaway for business looks like this: AI security should be treated as a separate perimeter layered on top of existing DevSecOps, not built into it. That means separate expertise on the team, a separate set of testing tools (model red teaming, prompt injection testing, training data audits) and a separate threat model that accounts for the specifics of machine learning. The OWASP, SAIF and ATLAS frameworks provide a sufficient foundation, so there is no need to reinvent the wheel.

The AI security industry is now roughly where classic cybersecurity was in the early 2000s: the threats are real and the tools are emerging, but mature standards do not exist yet. Companies that start building this perimeter now will gain not only a technical advantage but a competitive one, because in two to three years regulators will inevitably arrive with requirements, and those who are prepared will find it easier to adapt.