TL;DR: AI security in an organization involves both protecting applications made available to external users and controlling how employees use AI tools. As artificial intelligence becomes more widely adopted, new threats emerge, including prompt injection, Shadow AI, data leaks, and uncontrolled integrations with corporate systems. Solutions such as AI Gateway and DLP help monitor communication with AI models and protect confidential information. An effective AI security strategy is built on four pillars: visibility, application protection, data protection, and governance, enabling organizations to use AI securely and in a controlled manner.
Artificial intelligence has rapidly become part of organizations' daily operations, finding applications in both internal processes and customer-facing solutions. Employees use AI models to analyze information, work with code, and automate repetitive tasks, while companies increasingly deploy their own chatbots, assistants, and mechanisms that help users find information and products.
As AI adoption continues to grow, the attack surface that must be considered in a cybersecurity strategy is also expanding. Organizations need to understand not only where language models are being used, but also who has access to them, what information is sent to them, which systems they can communicate with, and how AI applications made available to external users are protected.
Two Dimensions of AI Security: Inbound and Outbound
AI security can be divided into two directions. The first area, referred to as inbound, concerns AI-powered applications that an organization makes available to external users. These may include customer service chatbots, assistants available on websites, or mechanisms that allow users to describe their needs so that a model can search for and recommend relevant products.
Behind the user-facing interface is a model that processes incoming requests. Making such an application publicly available therefore requires organizations to consider scenarios in which someone attempts to manipulate its behavior, obtain information the system should not disclose, generate large volumes of requests, or misuse access to the model.
The second area, outbound, approaches the issue from the opposite perspective. Employees use external AI models and applications, submitting prompts, documents, code, and other information as part of their daily work. In this case, the priority is understanding which tools employees use, what data they share with them, and whether information that should remain within the organization's environment can be detected and prevented from leaving it.
Distinguishing between these two directions helps organizations structure their AI security approach and select protective mechanisms that address the actual risks involved. The threats affecting internet-facing AI applications differ from those associated with employees using external AI services.
What Security Threats Are Associated with AI?
The risks associated with artificial intelligence can be categorized according to the direction of communication. On the one hand, organizations must protect their own AI applications made available to external users. On the other, they need to control how employees use public AI models, what information they submit, and which systems they can integrate with these tools.
Inbound – Threats to AI Applications
• Prompt injection – involves attempting to influence a model's behavior through specially crafted instructions, such as persuading it to ignore previous instructions or reveal its system prompt. Unlike many traditional attacks, the threat may arise primarily from the content and meaning of a request, making it necessary to consider the context of the prompt when detecting such attempts.
• Sensitive information disclosure – users may attempt to manipulate a model into revealing data, instructions, or other information they should not be able to access. This risk concerns both the data processed by the application and information related to its configuration or internal operation.
• Denial of Wallet – in applications that rely on paid AI models, deliberately generating large numbers of requests or particularly lengthy prompts can become a significant problem. When model usage is billed based on token consumption, such activity can increase resource utilization and, consequently, the costs incurred by the organization.
• Using an application as an LLM proxy – a publicly accessible chatbot may be exploited to process requests unrelated to its intended purpose. In this scenario, users take advantage of the model and resources paid for by the organization to perform their own tasks. This makes it important to monitor not only the volume of requests but also their subject matter.
• Bots, scraping, and DDoS – the use of language models does not eliminate traditional threats affecting web applications. Automated traffic may be used for scraping or generating large volumes of requests, while DDoS attacks may aim to disrupt service availability. AI-specific security controls should therefore complement standard application protection mechanisms.
Outbound – Risks Associated with Employees Using AI
• Shadow AI – employees may use various AI tools without the organization's full knowledge, leaving security teams with insufficient visibility into which models are being used and how. Without this information, it becomes difficult to assess the risks associated with individual services and determine which should be permitted, monitored, or blocked.
• Data leakage to external models – information may leave the organization's environment when employees copy content into prompts or upload documents and code snippets.
• Uncontrolled integrations – data transfers to external services do not occur exclusively through prompts and uploaded files. Integrations and plugins represent another communication channel, potentially extending AI tools' access to information stored in other systems. Organizations should therefore account for these connections when assessing AI-related risks.
AI Agents and MCP
A separate area of risk involves systems in which artificial intelligence can use tools, retrieve information from other applications, and perform specific operations.
These capabilities are offered by AI agents, which can carry out a sequence of actions using the resources available to them based on an assigned task. Model Context Protocol (MCP) plays an important role in enabling such integrations by facilitating communication between AI applications and external tools and data sources.
Consider an AI agent integrated with a company's CRM system, tasked with retrieving customer information and preparing summaries for the sales team. If the agent has excessively broad permissions, it may also gain access to data that is unnecessary for completing the assigned task. An additional threat arises when it processes content from untrusted sources, such as CRM notes containing malicious instructions designed to influence its behavior.
In such a scenario, an attacker may attempt to persuade the agent to retrieve additional information, transfer it to another tool, or perform an operation that the user did not authorize. The success of such an attack depends, among other factors, on the permissions granted to the agent, the configuration of its integrations, and the mechanisms controlling its actions.
How Can Communication Between Applications and AI Models Be Secured?
Protecting AI applications goes beyond detecting attempts to manipulate models. It is equally important to control how applications communicate with AI services, what requests are sent to them, and how the associated resources are managed.
In organizations using multiple language models, communication may take place between various applications and AI service providers. This makes it more difficult to achieve full visibility into traffic, monitor the usage of individual models, and enforce consistent policies.
One way to organize this communication is to introduce an intermediary layer between applications and AI models. This enables organizations to centralize request handling, monitor service usage, and manage how traffic is routed to individual models. One example is Cloudflare AI Gateway, which provides capabilities such as request monitoring, traffic management, fallback mechanisms, and response caching to reduce latency and costs.
This allows organizations to gain greater control over resource utilization and reduce their dependence on a single provider. For example, if one model becomes unavailable, a properly configured fallback mechanism can route requests to an alternative service.
However, controlling communication alone does not address every aspect of AI security.
DLP – Controlling Data Sent to AI Tools
Simply knowing which applications employees use is not enough. The next step is determining what information is being shared with those applications. Data Loss Prevention (DLP) mechanisms can analyze user traffic and respond when certain types of data are about to be transmitted to external tools.
Consider a developer who encounters a problem while working on an application, copies a section of code into an AI tool, and asks the model to identify and fix the error. From the user's perspective, this is simply a way to accelerate their work. However, the submitted code may contain a production API key or other authentication credentials that should not be shared with an external service.
If the user's traffic passes through a controlled environment, DLP mechanisms can detect such information and enforce an appropriate policy, for example, blocking the transmission and informing the user which element triggered the restriction. Logging the event is equally important. While blocking prevents a specific attempt to transmit sensitive data, recording the event enables subsequent analysis and allows relevant information to be forwarded to external tools, such as systems used by the SOC team.
From Visibility to Governance – Four Pillars of AI Security
An AI security strategy can be structured around four interconnected areas: visibility, application protection, data protection, and governance. This sequence is intentional, as effectively securing an environment is difficult when an organization does not know where and how artificial intelligence is already being used.
The first step is establishing visibility into both AI applications provided by the organization and tools used by employees. This includes identifying endpoints, models, users, and communication channels with external services.
The second pillar is application protection, which should address both threats specific to language models, such as prompt injection and Denial of Wallet, and traditional web application risks, including bots, DDoS attacks, and traffic abuse.
The third area is data protection, which involves controlling information sent by users to external models through mechanisms such as DLP and Secure Web Gateway policies.
The final pillar is governance, which involves continuously managing AI usage policies and adapting them to changes within the organization's environment.
Visibility is the common foundation of all four areas. Without knowing where AI operates, who uses it, what data it processes, and which systems it can communicate with, an organization lacks the information needed to make informed security decisions.
The objective does not have to be blocking artificial intelligence entirely. What matters more is establishing a framework that allows organizations to determine which solutions are permitted, which activities should be monitored, what data requires additional protection, and under what circumstances traffic should be blocked.
Text autors:
