AI Security in 2026

From Understanding AI Risks to a Mature Control System

When we published our foundational article “Artificial Intelligence Security” in November 2024, the main question for many companies was: why does AI require separate attention from security, risk management, and leadership at all? At that time, it was important to explain the fundamental risks: trust in the model, confidentiality, manipulation, opacity, data attacks, errors in outputs, and the need to manage AI throughout its entire lifecycle. In that article, we examined threat models, practical guidance, and approaches to minimizing AI risks.

Today, the conversation has changed. In 2025–2026, AI is increasingly ceasing to be a browser experiment or a separate product feature. AI is being embedded into legal, financial, engineering, customer-facing, analytical, and operational processes. LLMs are used as internal assistants. RAG systems gain access to corporate documents. AI agents connect to tools and APIs. Executives expect not demos from such solutions, but measurable business impact.

As a result, AI security is no longer merely a matter of general awareness. It is no longer enough for companies to know that prompt injections, data leaks, hallucinations, or model bias risks exist. They need to understand exactly where AI is used, what data it sees, what actions it can perform, who is responsible for the outcome, how the system logs events, how suppliers are controlled, how changes are verified, and what evidence of maturity can be shown to an auditor, investor, client, or regulator.

In other words, mature AI security in 2026 is no longer a one-off model check. It is a combination of architecture, risk assessment, access management, data security, testing, monitoring, operational processes, strategic governance, and regular reassessment.

Glossary AIBOM — an inventory of components, dependencies, and artifacts associated with an AI system. API — application programming interface. DAST — dynamic application security testing. DevSecOps — embedding security into the development, delivery, and operation of software. DLP — data loss prevention. EU AI Act — the European Union Artificial Intelligence Act. GPAI — general-purpose AI model. IAM — identity and access management. ISO/IEC — international standards in information technology and cybersecurity. LLM — large language model. MCP — Model Context Protocol, a standard for connecting AI assistants to external tools, data, and interfaces. NIST — the U.S. National Institute of Standards and Technology. OWASP — an open community and foundation that develops practical application security materials. RAG — retrieval-augmented generation, an architecture in which an LLM generates an answer using external knowledge sources. SAST — static source code security analysis. SIEM — a system for collecting, correlating, and analyzing security events. SOC — a security operations center for monitoring and responding to security incidents.

An AI System Is No Longer Just a Model

One of the main mistakes in early approaches to AI security was treating the model as the primary and almost the only object of protection. Now an enterprise AI system usually consists of a much larger number of components.

It may include an LLM, a RAG pipeline, a vector database, knowledge base documents, system prompts, user queries, conversation logs, external APIs, agents, plugins, MCP servers, cloud services, authorization mechanisms, input and output filtering tools, observability tools, and response processes. An error in any of these layers can lead not merely to an “incorrect answer,” but to a data leak, disruption of a business process, execution of an unwanted action, or legal risk.

This is especially visible in RAG systems. At first glance, RAG looks like a convenient way to give an LLM access to up-to-date corporate knowledge without retraining the model. At the same time, from a security perspective, RAG creates a new critical layer. Documents, access rights, vector indexes, embeddings, search mechanisms, retention rules, data sources, and context selection logic become part of the attack surface. In its materials on data security for generative AI, OWASP explicitly highlights the need to account for the entire data layer — from training and fine-tuning datasets to user prompts and final model responses.

The practical risk here is not limited to a classic data leak. A document in the knowledge base may contain a hidden instruction for the model. A vector index may indirectly reveal sensitive knowledge. A user may receive an answer based on a document to which they should not have access. Logs may retain commercial, personal, or legally significant data longer than company policies allow. Therefore, RAG security is simultaneously about data security, architecture, access rights, and model behavior.

Prompt Injections Have Become a Business Risk, Not a Lab Curiosity

Prompt injections have long ceased to be an amusing trick for demonstrating chatbot weaknesses. In corporate environments, indirect prompt injection is especially dangerous. A malicious instruction may be located not in the user’s request, but in a document, email, web page, ticket, comment in a task management system, or another external source that the AI perceives as context.

If AI only responds to the user, the consequences may be limited to an incorrect recommendation or disclosure of part of the context. However, if AI is connected to tools, email, CRM, DevOps systems, financial operations, or administrative APIs, a prompt injection may already affect the system’s actions. At that point, an error turns from an information risk into an operational one.

Prompt injections are not the only class of risks for LLM applications. The 2025 version of OWASP Top 10 for LLM Applications identifies also sensitive information disclosure, supply chain risks, data and model poisoning, insecure output handling, excessive autonomy, system prompt leakage, misinformation, uncontrolled resource consumption, and weaknesses in vector databases and embeddings. This clearly shows how far the topic has moved beyond classic penetration testing. It is now necessary to test not only forms, roles, and APIs, but also how the model interprets instructions, context, and the boundaries of its authority.

AI Agents Increase the Cost of Error

In a typical scenario, an LLM generates text, code, analysis, or a recommendation. In an agentic scenario, the system may plan steps, choose tools, access external sources, run commands, modify records, send messages, or perform actions on behalf of a user.

This is where a qualitatively new threat appears: the model begins not only to speak, but also to act.

OWASP Agentic AI Threats and Mitigations describes agents as autonomous systems whose capabilities and risks have grown sharply due to integration with LLMs and other generative AI. A separate OWASP Top 10 for Agentic Applications 2026 list already focuses on the risks of autonomous and agentic systems that plan and make decisions, as well as act within complex workflows.

For businesses, this means that the traditional principle of least privilege must be complemented by the principle of least autonomy. An agent should not have more data, tools, or permissions than required for a specific scenario. Ideally, its actions should be scoped, verifiable, logged, reproducible, and, where possible, reversible.

Special attention is required for actions with consequences: changing configurations, sending emails, creating payments, deleting data, managing infrastructure, updating code, changing access rights, publishing documents, and communicating with clients. In such scenarios, technical restrictions alone are not enough; clear business rules are also needed: when an agent may act independently, when human confirmation is required, when an action is blocked, and when an incident is escalated to the security or compliance team.

MCP and External Tools Expand the Attack Surface

MCP and similar mechanisms for connecting AI to external tools have quickly become one of the most interesting and, at the same time, riskiest areas. They make AI more useful: an assistant can work with files, systems, APIs, internal data, and corporate processes. This is precisely what turns the integration layer into a new security object.

In its practical guide to secure MCP server development, OWASP emphasizes that such servers are a critical connection point between AI assistants, external tools, APIs, and data sources. Unlike ordinary APIs, MCP servers often operate with delegated user permissions, dynamic tools, and call chains. This increases the potential damage from a single vulnerability. The guide separately highlights secure architecture, strict authentication and authorization, validation, session isolation, and deployment hardening.

In practice, this means that the tool layer cannot be treated as a technical “wrapper” around the model. It must be designed as a full-fledged trust zone: with separation of read and write operations, token restrictions, scope control, dedicated logging, denial policies, abuse tests, and an understanding of the “blast radius” — that is, the maximum possible damage in the event of compromise or error.

The AI Supply Chain Is Becoming Part of Security

In classic software security, companies have long been accustomed to thinking about dependencies, libraries, containers, images, packages, and external suppliers. In 2025, this problem reached a qualitatively new level. In the OWASP Top 10, the risk of supply chain compromise became one of the three highest-priority risk classes. In 2026, this trend intensified significantly. In AI, this problem does not disappear; it becomes more complex.

An AI system may depend on an external model, open weights, a dataset, an orchestration framework, a model inference library, a vector database, a fine-tuning tool, an external reranker, a moderation service, a cloud API, a test suite, or a third-party agent. A vulnerability, substitution, or lack of transparency in any of these components may affect security, reproducibility, quality, legal cleanliness, or compliance.

That is why model registries, artifact provenance control, versioning of models and data, supplier checks, evidence collection, and AIBOM are playing an increasingly important role. For a mature company, the question is no longer “which model are we using?” but “can we explain what components the AI system consists of, where they came from, who is responsible for them, what data they process, how they are updated, and how we will prove this during an audit?”

The Regulatory and Governance Layer Has Become Practical

The EU AI Act began entering into force on 1 August 2024, but at that time practical AI regulation still seemed distant. For companies operating in the EU or with European clients, it is no longer abstract. Certain prohibitions and AI literacy obligations have applied since February 2025. Governance rules and obligations for providers of general-purpose AI models started applying in August 2025. On 2 August 2026, the EU AI Act enters into full application, although additional phased exceptions and transitional periods are provided for certain cases.

It is important not to confuse organizational roles. The obligations of a general-purpose model provider, an AI system developer, and a company that deploys a third-party AI service in its own processes differ. For most clients, AI compliance practice begins not with the question like “are we a GPAI model provider?” but with inventorying use cases, AI literacy, prohibiting unacceptable practices, assessing high-risk cases, establishing contractual requirements for suppliers, and collecting evidence of control.

In July 2025, the General-Purpose AI Code of Practice was published as a voluntary tool to help providers of general-purpose models demonstrate compliance with their obligations under the EU AI Act, including transparency, copyright, safety, and security blocks for the most advanced models.

Regulatory requirements are only part of the picture. Even if a particular AI system does not fall into the strictest category, clients, auditors, investors, and partners increasingly ask questions about strategic governance: whether there is an inventory of AI use cases, who owns the risk, how data is classified, who approves integrations, how changes are tested, how incidents are handled, which suppliers are used, and what evidence of control can be provided.

Various reference documents are useful here, although none of them solves the entire task by itself. NIST AI RMF remains a convenient language for AI risk management and has been supplemented by the generative AI profile NIST AI 600-1. NIST SP 800-218A develops secure development practices for generative AI and AI foundation models based on SSDF. NIST AI 100-2e2025 provides a taxonomy and terminology of attacks on machine learning, while the preliminary NIST Cyber AI Profile connects AI with cyber risk management, protecting AI systems, using AI in defense, and countering AI-enhanced attacks. ISO/IEC 42001 sets requirements for an AI management system, and ISO/IEC 23894 helps embed AI risk management into organizational processes.

A mature approach does not come down to choosing “one correct standard.” A connected system is built: strategic governance at the leadership level, architectural decisions at the product level, data and access control at the engineering level, testing at control points, monitoring at the operations level, and evidence at the compliance level.

Why Classic Application Security Is No Longer Enough

AI security does not replace classic application security. On the contrary, without it, a reliable AI system cannot be built. Web applications, APIs, authentication, authorization, encryption, secrets, logs, infrastructure, cloud security, secure development, SAST, DAST, and DevSecOps remain the mandatory foundation.

The problem is different: this foundation is no longer enough.

An LLM may follow a malicious instruction that looks like ordinary or invisible text. RAG may disclose knowledge through non-obvious links between documents. An agent may make a permitted API call in an impermissible business context. The model’s output may become input for another system and trigger a vulnerability at the next step. Logs may contain sensitive prompts and responses. A model provider may change the behavior of a service without the client’s familiar release cycle.

Therefore, AI security requires expanding classic practices. Threat modeling must take into account not only users, roles, and APIs, but also context sources, system prompts, agent capabilities, data flows, tool chains, and decision points. Hardening must include not only servers and containers, but also model settings, tool restrictions, context policies, session isolation, output filters, agent action logging, and data retention control. Monitoring must track not only errors and attacks on infrastructure, but also suspicious prompts, unusual retrievals from the knowledge base, policy bypass attempts, growth in query costs, behavior drift, and anomalous agent actions.

Private LLMs: Useful, but Not a Panacea

Companies with confidential data are increasingly discussing local, private, or limited-connectivity LLMs. This is a reasonable direction. In some scenarios, it reduces dependence on external providers, decreases the risk of transferring confidential data to public services, and gives more control over infrastructure, logs, access policies, and the model lifecycle.

However, a local LLM does not make a system secure by itself.

If the model has access to poorly classified documents, if RAG is built without considering access rights, if agents receive excessive privileges, if prompts and responses are stored without a retention policy, and if monitoring and testing are absent, then local deployment simply moves the risk inside the perimeter. Sometimes it even creates a false sense of security. A company believes that “data does not leave the organization,” but does not control who inside the organization can access it through the AI interface.

Therefore, local and private LLMs should be treated as an architectural tool, not as universal protection. They are especially useful when combined with data classification, IAM, segmentation, logging, DLP, secure RAG, model supply control, regular assessment, and a clear responsibility model.

From Risk Assessment to Control Implementation

For many organizations, the natural first step is an AI security assessment. It is necessary to understand where AI is already used, what data is processed, which suppliers are involved, whether RAG is present, whether agents exist, which APIs are connected, what rights are delegated, how logs are structured, what requirements apply, and which risks are most critical.

On the other hand, maturity appears only when assessment turns into a managed system of change. A risk register is useful not by itself, but as a basis for decisions: what to fix first, what to accept as a conscious risk, where to change the architecture, where to restrict access, where to add human confirmation, where to enable monitoring, where to reconsider a supplier, and where to postpone automation until controls are in place.

Our practice is built precisely at this intersection of audit and implementation. It logically connects two areas: security audit and testing — to identify risks, vulnerabilities, and weak points; and security implementation — to design secure architecture, access control, component isolation, data protection, monitoring, and practical strengthening of AI systems.

This approach is important because AI security rarely comes down to a single report. In a real project, assessment is often followed by architectural analysis, threat modeling, RAG review, agent permission analysis, prompt injection testing, leak testing, logging configuration, monitoring recommendations, preparation of operational processes, and reassessment after changes.

What a Mature AI Security Program Should Include

A mature AI security program begins with visibility. A company must understand which AI use cases already exist: public services, internal assistants, RAG systems, agents, copilot features, models in products, AI in SOC, development, analytics, customer support, or legal work.

This makes it possible to classify risks: which scenarios affect personal data, trade secrets, code, financial processes, critical infrastructure, regulated industries, or decisions with a significant impact on people. Then the architecture must be assessed — the model, data, access rights, integrations, logs, suppliers, agent permissions, RAG pipeline, output control, and operational processes.

The next layer is practical controls. These include access restrictions, data source verification, input and output filtering and validation, tool isolation, separate read and write permissions, human confirmation for high-risk actions, secure MCP and API settings, secrets protection, logging, monitoring, incident playbooks, and regular testing.

Finally, repeatability is needed. An AI system changes faster than many traditional enterprise applications: models, prompts, documents, access rights, suppliers, agents, use cases, and business expectations are updated. Therefore, AI security assessment must be repeated after significant changes, and for critical scenarios it should become part of a continuous control practice.

A Consultative Approach Instead of the Illusion of Full Automation

The AI security market is rapidly filling with tools: scanners, red teaming frameworks, test suites, guardrails, model evaluation tools, monitoring solutions, strategic governance platforms, and evidence collection systems. These tools are genuinely useful. SANS Secure AI Blueprint, for example, is built around three areas — securing AI, using AI securely, and governing AI — emphasizing that AI adoption often moves faster than protective controls.

At the same time, a tool does not replace an architectural decision. An automated test may find some prompt injection issues, but it will not understand the business criticality of a specific agent action. A scanner may highlight a leakage risk, but it will not decide which data should be accessible through RAG. A monitoring system may collect events, but it will not determine on its own which of them matter for legal, financial, or operational risk.

Therefore, the right AI security roadmap should not look like a linear list of tasks that can be fully outsourced or automated by a single platform. A more mature approach is consultative support. In this model, external experts help the company form an architectural framework, conduct threat modeling, review the design, define priorities, connect technical risks with business context, validate decisions, assess alignment with applicable practices, and help the CISO, CTO, CEO, or product owner make informed decisions.

The client can implement some measures internally: through IT, the security department, DevOps, lawyers, compliance specialists, and product teams. In this scenario, the role of the external consultant is not to replace the entire internal team, but to strengthen it where an independent view, deep cybersecurity expertise, architectural rigor, and experience in assessing non-standard risks are especially important.

Conclusion: From One-Off Checks to a Managed Program

Since the publication of our previous article, AI security has changed noticeably. LLMs have become part of real business processes. RAG, AI agents, MCP, and corporate integrations have expanded the attack surface. Direct and indirect prompt injections, data leaks, supply chain risks, RAG weaknesses, excessive agent autonomy, and insufficient monitoring have become practical problems, not merely research topics. OWASP, NIST, ISO/IEC, SANS, and the EU AI Act have formed a more mature set of reference points, but they have also shown that it is impossible to create one universal engineering or regulatory structure for all AI systems. A combination of strategic governance, architecture, controls, testing, and operations is required.

For H-X Technologies, this means a natural evolution of our approach. If the basic task used to be explaining AI risks and showing why they need to be managed, the emphasis is now shifting toward assessment, implementation, and support. The focus is on secure architecture, data security, local or restricted LLMs for sensitive scenarios, AI infrastructure hardening, RAG control, agent and MCP security, monitoring, strategic governance, and consultative support for leaders and teams.

In the coming years, AI will move deeper into critical business processes. AI agents will receive more authority. Regulatory and contractual pressure will increase. Strategic AI governance will become part of corporate governance, and AI security will become increasingly integrated with the security of applications, clouds, data, IAM, SOC, SIEM, DLP, DevSecOps, and compliance.

That is why H-X is developing its AI security assessment and implementation practice: from threat modeling and RAG review to agent security, MCP, private LLMs, monitoring, and governance controls. Our task is to help clients use AI without losing control over data, access rights, and business risks.

The main ambition here is broader than checking a single chatbot or model. Organizations with complex IT architectures and regulated processes need partners who help build a mature security system around AI: from the first architectural decisions to continuous control, from threat modeling to monitoring, from regulatory compliance to practical protection of data and processes. In this area, AI security becomes not a brake on innovation, but a condition for its sustainable and controlled development.

Are you implementing LLMs, RAG, AI agents, MCP integrations, or private models? Just planning to? Or have you already implemented them and encountered problems? Discuss AI security tasks with H-X Technologies — we will help you understand which data and actions need to be brought under control, which risks should be checked first, and which security measures can be implemented without unnecessary bureaucracy.