Why traditional cybersecurity doesn’t protect AI systems

Every other company that has deployed an AI agent or language model protects it just like an ordinary microservice — with a firewall, dependency scanner, and access policies. It sounds reasonable, but in practice it's as if you put a metal door on a house that's missing one entire wall. Boris Matsakov, a Data Science engineer at Cloud.ru, formulated precisely the problem that the industry so far prefers not to notice in his analysis on Habr: classical DevSecOps and AI security are two different contours, and one does not replace the other.

The divergence is simple and yet fundamental. DevSecOps was built over decades around an understandable threat model: there is a perimeter, there are dependencies, there is infrastructure and access rights. Protect each of these layers — and the system is secure.

But AI models are attacked in completely different ways. Prompt injection allows an attacker to hijack the model's behavior through specially crafted text. Training data poisoning distorts the very logic of decision-making long before the model reaches production.

Context manipulation forces an AI agent to perform actions that its creators did not anticipate. None of these attacks touch the infrastructure in the traditional sense — they strike at what makes AI artificial intelligence: the data and the model's ability to interpret it.

The problem is especially acute with agentic systems — autonomous AI agents that don't just generate text but make decisions, call external APIs, work with databases, and execute chains of actions. If an ordinary language model can be roughly compared to a consultant who gives advice, then 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 here infrastructure protection is powerless by definition: from the firewall's perspective, the agent is doing exactly what it's allowed to do — sending requests and receiving responses.

The good news is that the industry is not standing still. Over the past eighteen months, several serious framework documents have been developed that allow building a practical defense system. OWASP released two separate Top 10 vulnerability lists — for LLM applications and for agentic systems. Google presented SAIF — the Secure AI Framework with a risk map that helps companies systematically assess threats. MITRE expanded its legendary ATT&CK database to the ATLAS project, cataloging attack techniques specific to machine learning systems. Each of these tools fills its own niche: OWASP provides a checklist of specific vulnerabilities, SAIF provides a risk assessment methodology, ATLAS provides a language for describing attacks and building threat models.

The bad news is that a unified standard still does not exist. There is neither a "GOST" nor an ISO, nor a mandatory framework that would prescribe a specific set of measures for companies. Each team interprets in its own way what a "secure AI system" means, and often this interpretation boils down to what in-house DevSecOps engineers already know how to do. This creates a dangerous illusion of protection: formally all procedures are followed, scanners are green, access is controlled — but the model is meanwhile vulnerable to attacks that the security team may not even suspect.

The practical conclusion for business looks like this: AI security needs to be viewed as a separate contour that overlaps with existing DevSecOps rather than being embedded in it. This means separate competencies in the team, a separate set of tools for testing — red teaming models, checking for prompt injection, auditing training data — and a separate threat model built taking into account the specifics of machine learning. The OWASP, SAIF, and ATLAS frameworks provide sufficient basis so you don't have to reinvent the wheel.

The AI security industry is currently at roughly the same place classical cybersecurity was in the early 2000s: threats are real, tools are emerging, but mature standards don't exist yet. Companies that start building this contour now will gain not just a technical advantage but a competitive one — because in two or three years regulators will inevitably come with requirements, and it will be easier to adapt for those who are prepared.