What Is AI Cybersecurity?

AI cybersecurity is the practice of securing artificial intelligence as part of your attack surface: the models, datasets, agents, MCP servers, prompts and AI-generated code inside your software, plus the new attack techniques that target them. It also covers the reverse direction, using AI to strengthen defence, but the first direction is the one that creates exposure today. That is the short answer to what is AI cybersecurity. It is worth being precise about it, because the term gets used for two very different things, and buying the wrong one leaves the other unguarded.

AI cybersecurity meaning, in two directions #

The AI cybersecurity meaning splits along a simple line: are you protecting the AI, or are you being protected by it?

Securing AI. Your organisation builds with AI and develops using AI. That introduces assets nobody inventoried and failure modes conventional tooling was never designed for: a prompt that accepts untrusted input, an agent with more permission than its task needs, a dataset that poisons a model, an MCP server nobody approved. This is where the incidents happen.

AI for security. Machine learning applied to detection, triage, explanation and remediation: cutting alert noise, prioritising exploitable findings, and writing the fix. This is where efficiency comes from.

Most vendors and most articles collapse the two. The AI cybersecurity meaning that matters operationally is that they are separate programmes with separate owners. One is an attack surface problem. The other is a productivity problem.

What is AI cybersecurity protecting? #

An inventory, before a control. Every item below is an asset a security team is now accountable for.

• Models, whether self-hosted, fine-tuned or called through a provider API
• Datasets used for training, fine-tuning, evaluation and retrieval
• Agents and agent servers that act autonomously inside your systems
• MCP servers that expose tools and data to those agents
• Prompts, skill files, rules files and guardrails, the configuration layer that governs AI behaviour
• Inference endpoints and the credentials that reach them
• AI coding assistants in use across your teams, and the code they generate
• AI dependencies: the frameworks and packages your AI stack pulls in

Notice how little of that is application code. That is precisely why a SAST tool, an EDR agent and a cloud posture tool can all report green while an agent on a laptop is exfiltrating data through its own email tool.ols you connected. Neither is application code, so neither is covered by the tooling you already run.

The three attacks that only exist because of AI #

Knowing which family you are looking at tells you where the control belongs, and this is where the AI cybersecurity meaning stops being abstract.

The first family targets the model’s instructions. Prompt injection has held the top position in the OWASP Top 10 for LLM Applications since the list existed, for a simple reason: any point where a model reads text it did not author is an entry point. The dangerous version is indirect. Nobody types the attack, the model retrieves it, from a support ticket, a web page, a pull request comment or a document someone uploaded. The model cannot tell instructions from content, so it follows both. Give that model tools and the same technique becomes tool injection: change what the agent believes a tool does, and it will act against you using your own credentials. Excessive agency is the multiplier. An agent holding broader permission than its task requires is the difference between a nuisance and an incident.

The second family targets the configuration layer. Prompts, rules files, skill files and MCP server definitions decide what AI does in your environment, and none of them are application code. The Rules File Backdoor showed how far that goes: zero-width Unicode characters carry instructions a human reviewer physically cannot see, the assistant obeys them, and it never mentions them in its response. The technique is catalogued in MITRE ATLAS as AML.CS0041. The same layer routinely holds provider credentials in plain text and grants assistants read access to far more of the filesystem than anyone intended. In agentic coding, this layer is the steering wheel, and almost nobody reviews it.

The third family targets the AI supply chain. Models, datasets and the packages around them arrive from outside. Slopsquatting is the clearest case: language models invent package names, attackers register them, and the agent installs the attacker’s code on request. Research presented at USENIX Security 2025 found that 19.7% of packages recommended by LLMs do not exist, and that hallucinated names recur often enough to be farmed. Alongside it sit poisoned training and retrieval data, embeddings that leak their source material, untrusted MCP servers wired straight into an agent, and vulnerable AI frameworks pulled in as dependencies.

Underneath all three is shadow AI: the models, agents, assistants and MCP servers already running without approval, review or inventory. It is the default state in most organisations, and it is why the first control is always a list.

What is not? #

It is not AI governance. Governance answers whether you should use a model and under what policy. AI cybersecurity answers whether the model, the agent and the wiring between them can be attacked.

It is not a filter in front of a chatbot. Runtime prompt filtering is one control among many. It sees nothing about the MCP server on a developer’s laptop, the poisoned rules file in the repository, or the credential in an AI config.

It is not covered by what you already run. Traditional application security stops at the repository and does not know what a model is. Endpoint tooling watches the operating system and does not understand packages, MCP servers or assistants. AI attacks land in the gap between them.

It is not only about generative AI. Classical machine learning in fraud, pricing and risk scoring is a target too, through poisoning, evasion and model extraction.

The frameworks that define the field #

OWASP Top 10 for LLM Applications: the working taxonomy for LLM application risk, and the one most security teams map findings to

OWASP Top 10 for Agentic Applications 2026: the companion list for autonomous, tool-using systems, published in December 2025

OWASP GenAI Security Project: the umbrella effort, including data security, MCP server guidance and red teaming resources

NIST AI Risk Management Framework and its Generative AI Profile: the governance vocabulary regulators and boards recognise

MITRE ATLAS: the adversarial technique knowledge base for AI systems, with real case studies

EU AI Act: the legal framework, including technical documentation duties that an AI inventory helps you satisfy

Where to start #

Inventory. Find every model, dataset, agent, MCP server and AI assistant in use, from code, dependencies and configuration rather than from a survey.

Map the relationships. Risk lives in the wiring: which agent reaches which tool, which dataset feeds which model.

Read the configuration layer. Treat prompts, skill files, rules files and MCP definitions as security artifacts and review them like code.

Scope permissions. Give every agent the narrowest tool surface and the least autonomy its job allows.

Enforce where it runs. Most AI risk sits on developer machines, so policy has to apply at the endpoint, before an unapproved server or a malicious package executes.

Securing the AI you use and the AI you build with #

The practical answer to what is AI cybersecurity is that it starts with visibility and ends with enforcement. Xygeni discovers every AI asset in your SDLC, including the models, agents, MCP servers, datasets, skill files and prompts nobody declared, maps how they connect, and detects the risks specific to them: prompt and tool injection, malicious instructions in rules and skill files, insecure MCP configuration, secrets in AI files and slopsquatted AI dependencies. Findings map to the OWASP Top 10 for LLM Applications and point at the exact file and line. An AI-BOM gives your auditors something defensible, and policy is enforced at the developer endpoint, where most AI risk actually runs.

The same intelligence applies to the findings from the scanners you already own, so AI security extends your stack instead of replacing it. See what your agents are connected to at Xygeni.

FAQ #