What AI security means.

Five areas the index examined

The Cisco Cybersecurity Readiness Index organises its findings across five security domains. The numbers below are headline figures from the 2025 report.

Direct and indirect injection are two different mechanisms.

Direct injection is the more commonly discussed form. Indirect injection is the more operationally important one, because it can reach the model through data channels that the user does not control — and that the organisation may not have reviewed.

Retrieval-Augmented Generation changes the picture.

In a Retrieval-Augmented Generation (RAG) system, the model retrieves external documents or data and includes them in its context before generating a response. This is powerful — the model can answer questions about information it was not trained on. But it also means that the model processes content from sources that may not have been written by the user and may not have been reviewed for embedded instructions.

A document in a knowledge base, a web page fetched at query time, a support ticket or an email thread can all contain text that looks like ordinary content to a person but reads as an instruction to a language model. NIST's 2025 research on prompt injection explicitly discusses RAG as a vector for indirect injection because the retrieval step introduces content that sits alongside the system prompt and user input in the model's context window.

OWASP ranks prompt injection as the top LLM risk.

OWASP's 2025 LLM Application Top 10 lists LLM01: Prompt Injection as the highest-priority risk for LLM applications. The entry covers both direct and indirect injection and notes that the attack can lead to unintended disclosure of information, circumvention of guardrails or unauthorised actions when the model is connected to tools.

OWASP's guidance emphasises that prompt injection is not a problem that can be solved purely at the model level. Architectural decisions — input separation, least-privilege tool access, output filtering, human approval for higher-impact actions — are part of the defence.

NIST treats prompt injection as an AI-specific vulnerability class.

NIST's 2025 draft guidance on prompt injection (AI 100-4) describes it as a vulnerability that arises from the way language models process instructions alongside data. The guidance distinguishes prompt injection from traditional injection attacks (such as SQL injection) because the mechanism is different: the attacker is not exploiting a parser or a query language. They are exploiting the model's instruction-following behaviour.

NIST also notes that mitigation is an active research area. Current approaches — input sanitisation, instruction hierarchies, output monitoring, constraint enforcement — each have limitations. No single technique is considered a complete defence against all forms of prompt injection as of 2025.

Data and Retrieval — What information can the system read?

An AI system may be connected to documents, databases, knowledge bases, customer records, emails, support tickets, source code, financial data or other company information. The security questions are: which data can it retrieve, through which connection, under which identity, and for what purpose?

The same RAG architecture that makes an AI system useful — giving it access to information it was not trained on — also creates a data surface that needs to be understood. A system that can retrieve customer records, financial data and internal documents presents a different security profile from one that only processes the user's own prompt.

Tools and Permissions — What can the system do beyond answering?

When an AI system is given tools — APIs, database connections, messaging functions, workflow triggers — it moves from answering questions to performing actions. The security profile changes significantly. A system that can only generate text has one class of risk. A system that can read records, update fields, send messages or invoke external services has a wider set.

OWASP's guidance on Excessive Agency (LLM06:2025) separates three dimensions that are often confused: functionality (which tools exist), permissions (which ones the system is actually authorised to use), and autonomy (which actions can proceed without a person approving them). A tool may technically support delete operations even if the AI is only meant to read. The permission boundary is what actually limits the system, not the intended use case.

A simple consequence model

The consequence of a manipulated or erroneous instruction is different at each level. An incorrect answer may cause confusion. An incorrect database change or an unintended external action can have operational, financial or regulatory effects. This is why tool access, permissions and approval boundaries matter — they determine which level of consequence is possible.

Outputs — What does the system produce, and where does it go?

AI output can take many forms: a text answer shown to a user, a structured payload sent to another system, a generated email, a code suggestion, a database query or an API call. Each type of output carries different security implications.

One specific concern is output that contains information the system retrieved but should not disclose. If a RAG system retrieves a document containing personal data and includes that data in its response to a user who should not see it, the issue is not in the model — it is in the access control around the retrieved content. Another concern is structured output that is consumed by another application without validation — the classical "trusting the AI's output as if it were sanitised" problem.

Combined risk: when these dimensions overlap

AI security risk is rarely about one dimension in isolation. It is usually about what happens when several dimensions combine.

The practical implication is that security decisions about an AI system should not be made by looking at the model alone. The model, its tools, its permissions, its data connections, its identity, its output channels and its approval boundaries form a single system. Weakness in one part of that system can create risk even when every other part is well-designed.

Two different security questions

The two cases above involve different mechanisms and different types of evidence.

AI security is therefore not one single problem with one single fix. It requires looking at the input, the application, the access layer and the output — and understanding how a vulnerability at one point can combine with capability at another.