Nearly nine in ten organisations now use AI regularly in at least one business function, according to McKinsey’s The state of AI in 2026: On the road to ROI (August 2026; 1,719 participants in 97 countries, surveyed in May and June 2026). Scaling is another matter: 44% say AI is scaling across their enterprise, up from 38% a year earlier, and only 37% attribute any EBIT impact to their use of AI. Many organisations are still running pilots.
That combination is the problem in miniature. Security exposure does not wait for a full production rollout. It arrives with the first pilot that is pointed at real customer data. Organisations are starting to fund the response: 30% now have a dedicated budget for AI security, up from 20% a year earlier, although 53% still fund it from existing security budgets, according to the 2026 Thales Data Threat Report (February 2026), a survey of 3,120 IT and security professionals across 20 countries. In the same survey, 61% said their AI applications are already being targeted by attackers.
Most security stacks have not kept pace. Firewalls, web application firewalls and endpoint agents were designed to inspect network traffic, HTTP requests and process behaviour. None of them can read a prompt, judge whether a model’s response has just leaked a customer record, or distinguish an AI agent doing its job from an AI agent that has been talked into doing someone else’s.
That gap, between AI running in production and controls that cannot see inside it, is where enterprise risk is accumulating fastest. This article sets out what the AI runtime attack surface actually looks like, what the evidence says about the cost of leaving it unaddressed, and how Thales AI Security Fabric approaches it as a runtime control layer.
Why Traditional Controls Cannot See AI Risk
A prompt injection is not a malformed request. It is a grammatically correct, perfectly well-formed piece of text that happens to persuade a model to ignore its instructions. To a web application firewall inspecting the request body, it is indistinguishable from a customer asking a support question. There is no signature to match, no anomalous byte sequence, no protocol violation.
The problem deepens with retrieval-augmented generation (RAG). In a RAG architecture, the malicious instruction may never appear in the user’s request at all. It can already be sitting inside an indexed document, a scraped web page or a shared drive that was ingested weeks earlier. The attack arrives through the knowledge base, not the network.
Agentic AI raises the stakes again. A chatbot that is manipulated produces a bad answer. An agent that is manipulated takes an action: it queries a database, calls an API, moves money, or raises a ticket with privileges a user never had. The blast radius is no longer the conversation.
What the Evidence Shows
Three findings from 2026 research make the risk concrete rather than theoretical.
- Identity sprawl is a strong predictor of breaches. Organisations where AI significantly expanded the number of identities requiring access to data reported a 43% breach rate over the previous twelve months, against 11% where AI had not materially changed access patterns: a fourfold gap. Only 19% fully govern non-human identities such as service accounts and AI agents. (Netwrix 2026 Data and Identity Security Report, 10 June 2026; 2,317 respondents across 1,889 organisations.)
- Access control, not model choice, is where AI breaches originate. Of the organisations that reported an AI-related breach, 92% lacked proper AI access controls, and 68% of breached organisations lacked AI governance policies, up from 63% a year earlier. The global average cost of a breach reached $4.99 million, up 12% year on year. (IBM Cost of a Data Breach Report 2026, conducted by Ponemon Institute and published 29 July 2026; 602 organisations breached between March 2025 and February 2026.)
- Attacks on AI systems are no longer unusual. More than one in five organisations (21%, up from 13%) reported a breach involving AI models or applications. One in four malicious breaches was AI-enabled, a 56% increase on the previous year, and those breaches cost an average of $6 million, roughly $1 million more than the global average. (IBM, 2026.)
The pattern is consistent across all three: the exposure is not really the model. It is the data the model can reach, and the identities that can reach the model. We covered the wider policy picture in What Is Frontier AI, and What Are the Security Risks?
The regulatory position is more nuanced than the headlines suggest. Under the EU AI Act, obligations on general-purpose AI models have applied since 2 August 2025, and since 2 August 2026 the Commission’s AI Office has been able to enforce them and impose fines, while the Article 50 transparency duties also apply (generative AI systems already on the market have until 2 December 2026 to add machine-readable marking of AI-generated content). The high-risk obligations, though, were deferred by the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026): to 2 December 2027 for stand-alone Annex III systems, and 2 August 2028 for AI embedded in regulated products. The extra time applies to the paperwork, not to the risk.
The AI Runtime Attack Surface
The OWASP Top 10 for LLM Applications, updated by the OWASP GenAI Security Project in its 2026 edition (August 2026), has given the industry a shared vocabulary for this. The entries enterprise teams meet most often in production are these:
- Prompt injection and jailbreaking (LLM01): instructions that override the application’s intended behaviour, delivered directly or indirectly.
- Sensitive information disclosure (LLM02): models returning personal data, financial records, credentials or API keys that were never meant to appear in an output.
- Hidden context exposure (LLM08, formerly system prompt leakage): exposure of the internal instructions, guardrails and business logic that define how the application behaves, handing an attacker a map of the controls.
- Vector and embedding weaknesses (LLM09): unclassified or unprotected data ingested into a vector store, where it becomes retrievable by anyone who can query the assistant. This is the RAG pipeline failure mode.
- Improper output handling (LLM10): model output passed downstream into a browser, shell or database without validation.
- Unbounded consumption (LLM06): deliberately expensive requests that degrade availability or inflate inference costs.
- Data and model poisoning (LLM05): interference with model behaviour through the data used in pre-training, fine-tuning or embedding.
- Excessive agency (LLM03): an AI system granted more autonomy, tool access or permission than its task requires. It climbed from sixth to third place in the 2026 edition, and it is the entry that matters most as deployments move from assistants to agents.
For agent deployments, OWASP’s separate Top 10 for Agentic Applications for 2026 (December 2025) extends this vocabulary to risks such as agent goal hijacking, tool misuse, and identity and privilege abuse.
Most of these cannot be caught by testing a model before deployment. They are runtime conditions, and they require runtime controls.
Thales AI Security Fabric
Thales launched its AI Security Fabric on 11 December 2025, positioning it as a runtime security layer for agentic AI and LLM-powered applications, covering the models, the data behind them, and the identities that interact with them.
Two modules were available at launch, and they are the two components listed on Thales’ AI Security Fabric page today:
- Imperva AI Application Security: runtime protection for in-house applications built on LLMs, deployed as a SaaS reverse proxy between the application and the model and supporting any major LLM provider, self-hosted or third-party. Imperva states that it addresses five of the OWASP Top 10 for LLM Applications: prompt injection, sensitive information disclosure, system prompt (hidden context) exposure, improper output handling and unbounded consumption. Imperva says guardrails for tool calls, which would address excessive agency, are planned.
- RAG Security: discovery, classification and protection of sensitive data before it is ingested into retrieval-augmented generation applications, protection of data during embedding and within the vector database, and monitoring of interactions with the underlying data sources, using encryption and key management.
At launch, Thales said it planned to extend the fabric during 2026 with data leakage prevention, a Model Context Protocol (MCP) security gateway, and end-to-end runtime access control. As of late October 2026 these are not yet listed as components on the fabric page, so confirm availability before planning around them. The MCP gateway is the one to watch: as agentic systems standardise on MCP to reach tools and data, that protocol becomes a natural control point and, left unmanaged, a very direct path from a model to production systems.
Runtime Controls Are Only Half the Answer
Filtering prompts and outputs limits the damage an attacker can do. It does not answer the prior question: why was that data reachable in the first place?
Every AI security programme eventually meets the same wall: you cannot govern what you have never found. Sensitive data sitting unclassified in an object store, a legacy database or a forgotten document library is precisely what ends up quietly indexed into a RAG pipeline. This is where data security posture management belongs in the architecture. Thales’ own design reflects it: the RAG Security module rests on the same discovery, classification, encryption and key management disciplines as CipherTrust Data Security Posture Management, rather than treating AI security as a standalone product.
The sequence that works is unglamorous but reliable: discover and classify what you hold, protect it at the data layer with encryption and tokenisation under keys you control, decide deliberately what AI systems are permitted to reach, and then enforce that decision at runtime.
What Enterprises Should Do Now
- Inventory your AI, including the AI you did not approve. Sanctioned deployments are the easy part. With more than two-thirds of breached organisations lacking AI governance policies, according to IBM, the baseline expectation should be that unapproved tools are already in use.
- Treat AI applications as identities, not just software. Every agent, copilot and service account that touches data needs an owner, a defined scope and a least-privilege entitlement that is reviewed like any other account. The Netwrix data suggests this is where the gap opens: identities multiply faster than human-paced reviews can track them.
- Classify before you ingest. Run discovery and classification against every source feeding a RAG pipeline before it is indexed. Retrofitting classification afterwards is considerably harder.
- Put controls in the request path. Pre-deployment model testing is necessary but insufficient. Prompt injection, output leakage and consumption attacks all occur at runtime, and need inspection there.
- Keep control of your keys. For organisations subject to sovereignty and resilience requirements (DORA and the EU AI Act, Saudi Arabia’s PDPL enforced by SDAIA, the UAE’s federal data protection law), where data sits and who holds the encryption keys are compliance questions, not merely engineering ones.
- Do not read the AI Act deferral as breathing room. High-risk obligations moved to December 2027 and August 2028, but transparency duties and the AI Office’s enforcement powers over general-purpose AI are live now, and the breach data is not on a legislative timetable.
- Map controls to a recognised framework. The OWASP Top 10 for LLM Applications 2026, the OWASP Top 10 for Agentic Applications and the NIST AI Risk Management Framework give you a defensible structure to evidence to auditors and to the board.
How Sinevis Can Help
Sinevis is an authorised Thales service partner, delivering globally, with expertise across the Thales data security, application security and encryption product lines, from CipherTrust Manager and Luna HSM through to the Imperva application and API security portfolio, now part of Thales.
That breadth matters for AI security specifically, because the controls described in this article sit on both sides of the application. Runtime inspection goes in front of the model; discovery, classification, encryption and key management go behind it. Treating those as separate projects, owned by separate teams, is how organisations end up with a filtered chatbot sitting on top of an unclassified data estate.
If you are moving AI from pilot into production and need to answer what your models can reach, who can reach your models, and how you would evidence either to a regulator, get in touch or explore our cybersecurity services.