Safe AI Adoption

Artificial intelligence is becoming a new interface to enterprise data, applications, and actions. Employees are adopting public AI tools, developers are embedding models into products, and agents are beginning to call business systems on a user's behalf. The opportunity is significant, but the security model must evolve with it.

Safe adoption does not mean blocking AI. It means giving people and teams an approved path to use it while preserving control over sensitive data, identities, models, and connected tools.

This paper focuses on three Cloudflare capabilities that together address the full lifecycle of AI risk: AI Gateway for governing and inspecting model traffic, MCP server portals for controlling agent tool access, and Secure Web Gateway for governing how employees interact with external AI services.

The goal: accelerate useful AI adoption while making access explicit, data use observable, and risk manageable.

Executive summary

AI introduces familiar security concerns in unfamiliar forms. Sensitive data can leave through a prompt. A model endpoint can be abused at machine speed. An agent can reach tools and data with more authority than intended. At the same time, blunt restrictions often push users toward unmanaged alternatives.

A durable AI security program should answer four questions:

1. What AI is in use? Discover sanctioned and unsanctioned applications, model endpoints, and agent connections.
2. Who can use it, and how? Apply identity, device, application, and least-privilege policies.
3. What data can move through it? Inspect prompts and responses for sensitive content, risky intent, and credential exposure.
4. How is it protected and operated? Detect AI-specific threats, control token usage and cost, and retain the telemetry needed to improve policy over time.

Why AI changes the control model

Traditional applications expose predefined inputs and deterministic workflows. AI systems accept natural language, interpret intent probabilistically, and increasingly decide which tools to call. This expands the attack surface in three ways.

Data becomes conversational. A user can disclose source code, credentials, customer records, or financial information in a prompt as easily as attaching a file. Responses can also contain sensitive or inappropriate content generated by the model itself.

Tokens are a shared resource that can be abused. Unlike traditional API calls, LLM requests consume tokens at variable rates. Without controls, a single application, automated pipeline, or malicious actor can exhaust provider quotas, drive significant unexpected cost, or degrade availability for legitimate users. Prompt stuffing — submitting unusually large inputs — can also be used as a vector to force model behavior or extract system prompt content.

Access can become action. Agents connect models to APIs, repositories, SaaS platforms, and internal systems via the Model Context Protocol (MCP). A compromised prompt or overprivileged tool can turn an incorrect model output into an unauthorized action against a real system.

The right response is defense in depth: inspect traffic at the model layer, enforce identity and least privilege at the tool layer, and apply policy at the workforce access layer — with shared telemetry across all three.

AI Gateway

Guardrails

Guardrails provide real-time content moderation on both the prompts your application sends to a model and the responses the model returns. Evaluation runs on Cloudflare's network using two purpose-built models: Llama Guard 3 8B for hazard category classification and Prompt Guard 2 86M for prompt injection detection.

Each of the following categories can be configured independently for prompts and responses, with actions of Block (prevent), Flag (log and allow), or Ignore (skip evaluation):

Best practices: Guardrails

• Start with Flag, not Block. Enable all categories in Flag mode initially. Review logs to understand what your application encounters before moving high-confidence risks to Block. This avoids disrupting legitimate use during rollout.
• Enable P1 (prompt injection) on all customer-facing applications. Injection attempts to override system prompts or extract internal context are common. Block P1 on prompts as a default for any externally accessible AI endpoint.
• Enable S7 (Privacy) on responses. This catches cases where the model itself outputs PII or sensitive content — not just what the user sends. Response-side inspection is frequently overlooked.
• Set S6 (Specialized advice) based on application context. A general-purpose assistant may need S6 flagged; a purpose-built medical or legal tool may need to suppress it or handle it in application logic.
• Understand the fail-safe behavior. Categories set to Block will block requests if the evaluation infrastructure is unavailable. Categories set to Flag will allow requests to proceed. Design your configuration around acceptable failure modes.
• Account for latency. Guardrails add approximately 500ms per request. For long prompts or responses, content is chunked and evaluated in segments, increasing latency further. Factor this into SLA design and consider which categories are strictly necessary for your use case.
• Note streaming behavior. On gateway endpoints, Guardrails buffers the full response before evaluation — converting streamed responses to non-streamed. Plan for this in latency-sensitive applications.

Data Loss Prevention (DLP)

AI Gateway DLP scans prompts and model responses for sensitive data using Cloudflare DLP profiles. Because evaluation occurs at the gateway layer, it does not require TLS decryption or changes to the application beyond routing traffic through the gateway.

Each DLP policy specifies one or more profiles to match against, an action (Flag or Block), and whether to check requests (prompts), responses, or both. The following predefined profiles are available:

Best practices: DLP policies

• Start in Flag mode. Apply all policies as Flag first. Review matched events in the Logs tab to understand detection volume and confirm accuracy before switching to Block. This is especially important for PII profiles, which can have false positives in conversational content.
• Apply separate policies to requests and responses. Prompt-side DLP catches data users are submitting to the model. Response-side DLP catches sensitive content the model generates or retrieves. Both directions matter and may warrant different profiles and actions.
• Use the PII profile with the proximity requirement in mind. The predefined PII profile matches only when three or more unique identifiers appear close together — a deliberate design to reduce false positives from isolated names or email addresses in ordinary conversation.
• Build custom profiles for organization-specific data. Predefined profiles cover common data types but will not detect internal identifiers such as employee IDs, customer account numbers, or proprietary project names. Create custom profiles with regex patterns or exact-match datasets for these.
• Use payload logging to retain evidence. By default, Cloudflare does not write matched content to disk. Enable payload logging or Logpush to retain encrypted copies of matched content for incident investigation and compliance purposes.
• Test profiles before enforcement. Use the Test scan feature with representative sample content to validate detection accuracy before applying Block actions in production.

Token leakage and credential protection

Token leakage in AI contexts covers two related risks: the leakage of AI provider API keys and credentials, and the abuse of LLM tokens (the unit of model consumption) through excessive or malicious usage. AI Gateway addresses both.

Protecting API keys and provider credentials

• Use BYOK (Bring Your Own Keys / Store Keys). AI Gateway can securely store AI provider API keys on Cloudflare's infrastructure. Applications route requests through the gateway without ever handling the provider key directly, eliminating the risk of keys being embedded in application code, environment variables, or client-side bundles.
• Enable Authenticated Gateway. Require a valid Cloudflare-issued token for every request to the gateway. This ensures that only authorized callers — applications, services, and users with valid credentials — can invoke the gateway and reach provider endpoints.
• Apply DLP to detect credentials in prompts and responses. Users sometimes inadvertently paste API keys, SSH private keys, or cloud provider credentials into prompts. Apply a DLP policy targeting credential patterns on requests and Block when a match is found.
• Use Cloudflare Access in front of the gateway. For internal applications, place Cloudflare Access in front of the AI Gateway endpoint to require identity-provider authentication before any request reaches the model.

Controlling token consumption and abuse

• Apply rate limiting at the gateway. Set fixed or sliding window rate limits on the number of requests per user, team, or application. This prevents any single caller from consuming a disproportionate share of provider quota and limits the blast radius of a compromised credential or misconfigured automation.
• Configure spend limits. AI Gateway can enforce cost-based budgets per model, provider, or custom metadata dimension (such as user ID or team). When a budget is reached, further requests are blocked until the limit resets, providing a hard ceiling on runaway cost from automated pipelines or abuse.
• Use caching for repeated prompts. Identical or semantically similar prompts can be served from cache rather than forwarded to the provider. This reduces token consumption and provider cost for predictable or repetitive workloads.
• Monitor token counts in analytics. AI Gateway logs token counts per request. Review these analytics to establish a baseline for normal usage and set alerts or rate limits when consumption deviates significantly. Anomalously large prompts can indicate prompt stuffing attempts.
• Configure retries and model fallback conservatively. Automatic retries increase token consumption and cost if misconfigured. Set retry limits deliberately and use model fallback to route to a less expensive model tier when the primary model is unavailable, rather than retrying indefinitely against a premium endpoint.

Observability and audit

AI Gateway logs every request and response, including prompts, model outputs, token counts, cost estimates, DLP action results, and guardrail evaluation outcomes. Logs can be filtered by DLP action, provider, model, and time range from the dashboard.

For long-term retention and SIEM integration, use Workers Logpush to export encrypted logs to external storage. This creates an auditable record of all AI interactions for incident investigation, compliance review, and policy tuning.

MCP server portals

The agent access problem

An agent operating through MCP can call file systems, databases, SaaS platforms, and internal APIs. If tool access is unmanaged, a single compromised prompt or overprivileged agent session can reach systems far beyond the intended scope. The risk is compounded by the fact that agent actions are often difficult to observe after the fact if request-level logging is not in place.

How MCP server portals work

An MCP server portal aggregates selected MCP servers behind a single, identity-aware access point protected by Cloudflare Access. When an agent or user connects to the portal, they authenticate through your existing identity provider. The portal then presents only the tools, servers, and prompts that the authenticated identity is authorized to use.

Every tool request made through the portal is logged, creating an auditable record of what the agent called, when, and under which identity.

Best practices: MCP server portals

• Protect both the portal and direct server access. Placing a portal in front of MCP servers is only effective if direct access to the underlying servers is also restricted. Use Cloudflare Access or network-level controls to ensure agents cannot reach servers by bypassing the portal.
• Enforce least privilege at the tool level. Do not expose all available tools to all users through a single portal. Create separate portals or use group-based policies to give different user populations or agent roles access only to the specific tools their work requires.
• Use your existing identity provider. MCP server portals integrate with any OIDC or SAML identity provider already in use for application access. Apply the same group memberships and conditional access policies you use for other sensitive applications.
• Review tool request logs regularly. Log data from the portal shows which tools were called under which identity. Review these logs on a defined cadence to detect unusual access patterns, identify tools that are no longer used, and maintain an accurate picture of what agents are doing.
• Define and publish an approved tool catalog. Treat the portal as a governed catalog — not an open marketplace. Require a review process before new MCP servers or tools are added, and document the business justification and data access scope for each.
• Apply session limits. Configure session durations and require re-authentication for long-running or high-privilege agent sessions. An agent session should not outlive the task it was initiated for.

Secure Web Gateway

Visibility into AI application use

Gateway classifies traffic to AI applications and surfaces usage patterns through the AI Security Report. Security teams can see which services employees are accessing, the volume of activity, and which users or groups are responsible — without needing to inspect content. This visibility is the prerequisite for any meaningful policy.

Application and action controls

Gateway supports granular controls beyond simple allow or block decisions. For many AI services, teams can govern specific in-app actions — for example, allowing employees to use a generative AI chat interface while blocking file uploads, document analysis, or the ability to share conversation history. This enables organizations to approve the productivity value of a tool while containing the data risk of its more sensitive features.

Best practices: Gateway AI policy

• Inventory before enforcing. Run Gateway in visibility mode for at least 30 days before applying block policies. Use the AI Security Report to identify which services are actually in use, who is using them, and at what volume. Policy built on real usage data is more accurate and causes less disruption than policy built on assumptions.
• Create a sanctioned service list and communicate it. Define which AI services employees are approved to use. Communicate this clearly. Users are more likely to use approved tools — and less likely to seek workarounds — when the approved path is visible and useful.
• Use action-level controls for high-value services. Rather than blocking a widely used AI service entirely, apply action-level restrictions to the behaviors that carry the most risk. File upload, document analysis, and conversation export are higher risk than basic chat use of the same service.
• Apply DLP to inspect prompt content. Gateway DLP can inspect the content of prompts submitted to AI services over HTTPS (with TLS inspection enabled). Use predefined profiles for financial data, PII, and source code, and build custom profiles for organization-specific sensitive data. Start in log mode to understand what is being submitted before applying Block actions.
• Block unsanitized HAR file uploads. Browser HAR files — often shared for debugging — frequently contain session cookies, authorization tokens, and API credentials. Gateway DLP includes a predefined detection for unsanitized HAR files. Apply a block policy on upload, or redirect users to a sanitization tool before sharing.
• Apply source code DLP profiles. Employees submitting proprietary source code to public AI tools is one of the highest-frequency data loss patterns in enterprise AI adoption. The predefined Source Code profile detects code in 12 languages using NLP. Apply it on outbound traffic to AI services.
• Segment policy by group. Not all employees have the same risk profile. Apply stricter controls — or more comprehensive DLP scanning — to groups with access to sensitive data such as engineering, finance, legal, and HR, while using lighter policy for lower-risk populations.
• Route high-risk browsing through Remote Browser Isolation. For AI services that cannot be fully governed through action controls or DLP, use Browser Isolation to execute the session remotely. This prevents data from being downloaded to the endpoint and limits clipboard and file transfer behavior.

Connecting Gateway to AI Gateway

Gateway governs employee access to external AI services. AI Gateway governs the model calls that internal applications make. These are complementary — organizations typically need both. Gateway covers the human-initiated surface; AI Gateway covers the application-initiated surface. Telemetry from both flows into Cloudflare's unified analytics, making it possible to correlate workforce behavior with application-layer model traffic in a single investigation workflow.

Design principles for durable AI governance

1. Enable a safe path first. Users adopt sanctioned tools when approved options are useful and accessible. Governance that starts with a block list without an approved alternative drives shadow adoption.
2. Observe before enforcing. Flag-mode DLP and Guardrails policies reveal what is actually happening before enforcement disrupts legitimate work. Every control should spend time in observation before moving to block.
3. Protect both directions. Inspect what users and applications send to models and what models return. Data loss happens in prompts; harmful or policy-violating content can also appear in responses.
4. Keep agent authority narrower than capability. An agent should receive only the tools and permissions required for its current task. Treat MCP tool access as you would privileged API access — require justification, scope tightly, and log everything.
5. Store credentials at the gateway, not in code. Provider API keys embedded in application code or environment variables are a persistent leak risk. Use AI Gateway's key storage to remove credentials from the application layer entirely.
6. Unify telemetry. Investigation is faster when workforce, application, model, and agent activity can be correlated. Route logs from Gateway, AI Gateway, and Access to a common destination.
7. Assume the environment will change. New AI services, model providers, agent tools, and jailbreak techniques emerge continuously. Review providers, models, tools, policies, and exceptions on a defined cadence — at minimum quarterly.

Conclusion

The central challenge of AI adoption is not choosing between innovation and control. It is designing a path where both reinforce each other.

AI Gateway, MCP server portals, and Secure Web Gateway each address a distinct layer of AI risk — model traffic, agent tools, and workforce access — and are more effective used together than in isolation. A unified telemetry stream across all three makes incidents faster to investigate and policy easier to improve.

Organizations can begin with discovery, establish approved paths, enforce controls according to risk, and improve continuously. The result is not simply safer AI. It is an operating model that allows AI to move from isolated experiments to trusted, enterprise-scale use.

Recommended next step

Run a focused AI security workshop to map one workforce use case, one AI-powered application, and one agent workflow. For each, document: data paths, identities involved, tools or providers called, current controls in place, and gaps. Use this as the input to a policy plan. This creates a practical starting point while establishing a repeatable pattern that can scale across the organization.

Further reading