Controlling Employee AI Usage on Managed Devices: Browser Controls, Cloudflare AI Gateway, and AWS Bedrock

While employee use of AI tools like ChatGPT and Claude offers productivity benefits, it also creates security risks by allowing company data to leave the organization without standard controls. It recommends against simply blocking all AI, which drives shadow usage, and instead advocates for a control architecture that separates three use cases, with browser-based controls being the most important for managed devices. The recommended approach involves routing traffic through a Secure Web Gateway with DLP inspection, enforced via MDM, to classify AI tools as approved, restricted, or blocked.

Employees are already using AI. They may use ChatGPT to rewrite emails, Claude to summarize documents, Gemini to analyze spreadsheets, Perplexity to research topics, or GitHub Copilot to assist with code. The productivity value is real. The security risk is also real. The problem is not that people use AI. The problem is that company data can leave the organization through AI tools without the same controls we normally apply to email, SaaS applications, cloud storage, source code repositories, or production systems. For an organization with managed devices, the recommended answer is not “block all AI.” That usually drives shadow usage. A better approach is to build an AI control architecture that separates three different use cases: Browser-based AI control requires SWG, CASB, and DLP Cloudflare AI Gateway controls API traffic from applications AWS Bedrock controls Bedrock-based internal AI applications These three controls solve different parts of the problem. They are complementary, not interchangeable. The Core Problem A user on a company-managed macOS or Windows device can open a browser and paste sensitive data into an AI chat tool. That data may include: - customer information - source code - production logs - API keys - incident reports - financial data - unreleased business plans - internal policy documents - vulnerability details - cloud account identifiers - screenshots from internal systems From a security perspective, this is not only an AI problem. It is a data egress problem. The AI tool is simply the destination. The right control question is: How do we stop sensitive company data from being pasted, uploaded, or sent into unauthorized AI systems while still allowing employees to use approved AI safely? To answer that, the architecture must control three paths. Use Case 1: Browser-Based AI Control Requires SWG, CASB, and DLP This is the most important use case for governing employee AI usage on company-managed devices. When an employee opens: https://chatgpt.com https://claude.ai https://gemini.google.com https://www.perplexity.ai they are using AI through a browser session. Cloudflare AI Gateway and AWS Bedrock do not automatically sit between the user and those websites. The browser is talking directly to the SaaS AI provider unless you force traffic through a controlled inspection path. That inspection path is usually: Managed Device ↓ MDM-enforced agent / secure browser / proxy ↓ Secure Web Gateway ↓ DLP inspection ↓ CASB / SaaS policy ↓ Approved or blocked AI application In Cloudflare environments, this usually means Cloudflare One with Gateway, Access, DLP, CASB, and WARP. Cloudflare Gateway is the inline control point for browser-based AI traffic, including prompt controls, DLP, and Shadow AI visibility. Cloudflare also supports CASB integrations with AI providers such as ChatGPT, Claude, and Gemini for posture and data visibility. What This Solves Browser-based controls address the highest-volume human behavior risk. They help answer: - Which AI tools are employees using? - Are they using approved or unapproved tools? - Are users pasting sensitive data into AI prompts? - Are users uploading confidential files into AI tools? - Are users using personal AI accounts instead of enterprise tenants? - Which departments or users generate the most AI data exposure risk? - Which AI traffic should be blocked, warned, logged, or allowed? This is the layer that governs employees using AI through browser sessions. Target Architecture Company Managed Device | | MDM-enforced Cloudflare WARP / secure proxy v Cloudflare Gateway | | DNS + HTTP inspection + TLS inspection v DLP Policy Engine | | Detect secrets, source code, customer data, PII, financial data v AI Application Policy | | Allow / block / warn / isolate / log v Approved AI SaaS | | ChatGPT Enterprise / Claude Enterprise / Gemini Workspace v CASB + SIEM + Audit Logs Practical Implementation Step 1: Define Approved and Unapproved AI Tools Start with a simple AI application classification model. approved ai tools: - ChatGPT Enterprise - Claude Enterprise - Gemini for Google Workspace - GitHub Copilot Business - Internal Bedrock AI Assistant restricted ai tools: - personal ChatGPT accounts - personal Claude accounts - personal Gemini accounts - unknown AI writing tools - unreviewed browser-based AI tools - AI tools without enterprise logging or contractual protection blocked ai tools: - AI tools hosted in untrusted jurisdictions - tools with no privacy controls - tools that allow anonymous upload of company files - tools used to bypass company policy This gives Security, IT, Legal, and business teams a shared control vocabulary. Do not start with a vague policy like “use AI responsibly.” Translate the policy into enforceable categories. Step 2: Enroll Managed Devices For company-managed devices, traffic enforcement should be pushed through MDM. For macOS, use your MDM platform to deploy: - Cloudflare WARP client - device certificate - Cloudflare root certificate for TLS inspection - browser configuration profiles - DNS/proxy enforcement profile - controls that prevent users from disabling the agent - posture checks for device compliance For Windows, use Intune, GPO, or equivalent endpoint management. The goal is simple: No managed device should access AI SaaS directly without passing through the corporate control path. Step 3: Enable DNS and HTTP Inspection DNS control alone is not sufficient. DNS can tell you that the user visited chatgpt.com . It cannot reliably inspect what the user pasted into the prompt. To inspect browser-submitted content, you need HTTP inspection and, in most cases, TLS inspection. That means: User browser ↓ encrypted HTTPS Cloudflare certificate trusted by device ↓ inspected by Gateway Policy decision ↓ re-encrypted HTTPS AI SaaS destination Without TLS inspection, your control will mostly be domain-level allow/block. With TLS inspection, you can enforce prompt-level DLP and file-upload controls where supported. Step 4: Create DLP Profiles for AI Prompts Create DLP profiles specifically for AI usage. Generic DLP rules are often too noisy for this use case. AI prompt DLP needs to focus on data that should not be pasted into third-party AI systems. Recommended profiles: dlp profiles: credentials and secrets: examples: - AWS access keys - GitHub tokens - private keys - OAuth client secrets - database passwords - Kubernetes secrets - JWT signing keys source code: examples: - application code - Terraform modules - Kubernetes manifests - CI/CD pipeline files - authentication logic - payment logic customer data: examples: - customer names - emails - account numbers - transaction records - support tickets - CRM exports production logs: examples: - authentication logs - WAF logs - API Gateway logs - database logs - incident evidence regulated data: examples: - PCI data - health data - financial records - government identifiers - HR records Use different actions depending on severity. policy actions: secrets detected: action: block user message: "This prompt appears to contain credentials or secrets. Submission is blocked." customer pii detected: action: block or require approved ai user message: "Customer data must only be used in approved enterprise AI tools." source code detected: action: allow only for approved engineering ai user message: "Source code can only be submitted to approved engineering AI environments." low risk business text: action: allow with logging Step 5: Control File Uploads Prompt text is not the only risk. Users may upload: - PDFs - spreadsheets - CSV exports - screenshots - source code archives - incident reports - architecture diagrams - contract documents The policy should treat uploads as higher risk than short typed prompts. Example policy: If destination is public AI tool AND action is file upload THEN block. If destination is approved enterprise AI tenant AND file contains sensitive data THEN allow only for approved groups or require warning/justification. If destination is internal AI portal THEN allow based on user role and data classification. Step 6: Enforce Tenant Control This is where many organizations create avoidable gaps. They allow chatgpt.com , but users log in with personal accounts. That creates a gap: Same domain Different risk A corporate ChatGPT Enterprise workspace does not carry the same risk profile as a personal ChatGPT account. The same is true for Claude and Gemini. Use tenant controls where available to enforce: Allow corporate tenant Block personal tenant Block unmanaged accounts For Google Workspace environments, this becomes especially important because personal Google accounts and corporate Google accounts may access similar services. Step 7: Send Logs to SIEM At minimum, log: ai usage log fields: - user - device - department - source ip - destination ai app - approved or unapproved tool - action - policy decision - DLP profile matched - severity - timestamp - file upload indicator - tenant/account type if available Route these logs to your SIEM or data lake. Detection examples: Alert when one user triggers more than 5 AI DLP blocks in 24 hours. Alert when source code is repeatedly submitted to unapproved AI tools. Alert when a privileged engineer attempts to paste production secrets into AI. Alert when a user accesses a newly observed AI domain. Alert when an unmanaged device accesses approved AI tools without posture compliance. Example Browser Policy policy name: Control Browser AI Usage conditions: destination category: AI Tools device posture: managed identity provider: corporate sso rules: - name: Block Secrets in AI Prompts if: dlp match: - aws access key - private key - github token - database password then: action: block log: true - name: Block File Uploads to Unapproved AI if: ai tool status: unapproved action: file upload then: action: block log: true - name: Allow Approved Enterprise AI if: ai tool status: approved tenant: corporate dlp match: none then: action: allow log: true - name: Warn on Low-Risk Prompt to Unapproved AI if: ai tool status: unapproved dlp match: none then: action: warn log: true What This Does Not Solve Browser controls do not fully govern your own AI applications. They also do not provide deep model behavior controls such as: - prompt template governance - model selection - model fallback - token budget enforcement - model output filtering - agent tool approval - retrieval policy - application-level audit trail That is where Cloudflare AI Gateway and AWS Bedrock come in. Use Case 2: Cloudflare AI Gateway Controls API Traffic from Apps Cloudflare AI Gateway is useful when your company has applications that call AI models through APIs. Example: Security reporting app ↓ Cloudflare AI Gateway ↓ OpenAI / Anthropic / Google / Workers AI / other supported model provider This is materially different from browser-based AI usage. Cloudflare AI Gateway does not automatically control employees typing directly into ChatGPT or Claude from a browser. It controls AI traffic from applications that you intentionally route through the gateway. Cloudflare describes AI Gateway as a way to observe and control AI applications with analytics, logging, caching, rate limiting, retries, and model fallback. What This Solves Cloudflare AI Gateway addresses the application AI governance problem. It helps answer: - Which internal application is calling which model? - How many tokens are being used? - What is the cost trend? - Which model provider is failing? - Which application is abusing AI calls? - Should requests be cached? - Should traffic fall back to another model? - Which API keys and model endpoints are being used? - Can AI traffic be centrally logged? This is useful for platform engineering, DevSecOps, application teams, and security operations. Target Architecture Internal Application | | API request v Company AI Client SDK / Proxy Wrapper | v Cloudflare AI Gateway | | Logging, analytics, caching, rate limiting, retries, fallback v Model Provider | | OpenAI / Anthropic / Google / Workers AI / others v Response | v Application Example Enterprise Use Cases Cloudflare AI Gateway is a good fit for: Security Hub finding summarizer GuardDuty alert explanation tool Datadog log summarization assistant customer support AI assistant internal documentation chatbot developer code review helper AI-powered compliance evidence summarizer These are controlled application workflows, not unmanaged browser sessions. Practical Implementation Step 1: Inventory AI API Usage Identify where teams are calling AI APIs. Look for: OPENAI API KEY ANTHROPIC API KEY GOOGLE API KEY BEDROCK LLM chat.completions messages.create Search in: - GitHub repositories - CI/CD variables - Kubernetes secrets - Terraform state - developer documentation - Datadog logs - AWS Secrets Manager - local .env files where possible - platform engineering service catalogs The goal is to stop teams from independently wiring AI providers with unmanaged keys and inconsistent logging. Step 2: Create a Standard AI API Route Instead of allowing this: Application → OpenAI directly Application → Anthropic directly Application → Google directly force this: Application → Cloudflare AI Gateway → Model provider This lets the company centralize: - observability - rate limits - caching - retries - fallback - usage analytics - traffic ownership Step 3: Require Application Identity Do not treat all AI API calls as the same risk. Each app should have its own identity. Example: ai applications: security-reporting-service: owner: security-engineering allowed models: - claude-sonnet - gpt-4-class-model monthly budget usd: 500 log level: metadata and policy data allowed: security findings without secrets customer-support-assistant: owner: customer-operations allowed models: - approved-support-model monthly budget usd: 2000 log level: metadata only data allowed: sanitized customer cases developer-code-helper: owner: platform-engineering allowed models: - approved-code-model monthly budget usd: 1000 log level: metadata and dlp data allowed: non-secret source code Step 4: Add Pre-Gateway Policy Checks Cloudflare AI Gateway gives you application AI traffic control, but you should still add a policy layer before model invocation. Recommended pattern: Application ↓ Company AI Policy Middleware ↓ DLP / classification / authorization ↓ Cloudflare AI Gateway ↓ Model Provider The middleware should check: pre request checks: - user identity - application identity - data classification - prompt size - secret detection - customer data detection - approved use case - model allow-list - budget limit This avoids sending sensitive content to the model provider just because the app can reach the gateway. Step 5: Add Cost and Abuse Controls AI cost can quickly become an operational and financial control issue. Implement: controls: - per-application rate limit - per-user rate limit - monthly token budget - model allow-list - block expensive models for low-value workflows - cache repeated prompts where appropriate - alert on sudden usage spikes Example detection: An internal documentation chatbot normally uses 100k tokens per day. It suddenly uses 8 million tokens in 2 hours. Trigger alert and throttle. Step 6: Log for Audit, But Be Careful Do not blindly log full prompts and responses when they may contain sensitive data. Recommended logging model: logging strategy: metadata: - application - user - model - provider - token count - latency - policy decision - cost estimate - error status sensitive payloads: default: do not log exception: approved debug mode with retention limit For regulated environments, prompt logging can become a second data leakage path. Example App Gateway Policy policy name: Internal AI API Gateway Control rules: - name: Require Approved Application if: application identity: unknown then: action: block - name: Block Secrets Before Model Call if: prompt contains: - private key - aws secret access key - github token then: action: block - name: Enforce Model Allow List if: requested model: not in application allow list then: action: block - name: Apply Budget Control if: monthly budget remaining: exceeded then: action: throttle or block - name: Route Approved Traffic if: policy decision: allow then: route: cloudflare ai gateway Where This Fits with Browser Control Use Cloudflare Gateway, CASB, and DLP for users in browsers. Use Cloudflare AI Gateway for company applications calling AI providers through APIs. Both should send logs to the SIEM, but they operate at different layers. Browser AI usage: User browser → SWG/CASB/DLP → AI SaaS Application AI usage: Internal app → AI Gateway → Model provider Use Case 3: AWS Bedrock Controls Bedrock-Based AI Applications AWS Bedrock is the right control point when the organization wants to build a company-owned AI service. This is usually the cleanest model for sensitive workflows. Instead of telling users: Go to ChatGPT and paste this security report. you provide: https://ai.company.com The user authenticates with corporate SSO, chooses an approved workflow, and the request is processed through policy, Bedrock Guardrails, logging, and access control. What This Solves AWS Bedrock addresses the internal governed AI platform problem. It helps answer: - Which users can use which internal AI workflows? - Which models are approved? - Which prompts are allowed? - Which responses should be blocked or masked? - Which workflows can use internal documents? - Which actions require human approval? - How do we keep sensitive workflows inside AWS? - How do we enforce guardrails before and after model invocation? AWS Bedrock Guardrails can evaluate user inputs and model responses. Guardrails can also detect and filter sensitive information such as PII in prompts and responses. AWS also supports using the ApplyGuardrail API independently, allowing applications to evaluate text without invoking a foundation model. Target Architecture Employee | v Internal AI Portal | v Google SSO / Okta / Entra ID | v Authorization Layer | v Prompt Policy Engine | v Amazon Bedrock Guardrails - Input | v Amazon Bedrock Model | v Amazon Bedrock Guardrails - Output | v Audit Logging | v Employee For RAG: Employee | v Internal AI Portal | v Identity + Authorization | v Retriever | | checks document permissions v Kendra / OpenSearch / S3 / Confluence / Google Drive Index | v Context Assembly | v Bedrock Guardrails | v Bedrock Model | v Response + Citations + Audit Practical Implementation Step 1: Define Internal AI Workflows Do not start by giving users a generic chatbot with broad, undefined access. Start with approved workflows. Example: approved internal ai workflows: security report summarizer: users: - security-engineering - security-management allowed data: - Security Hub findings - GuardDuty findings - sanitized Datadog logs prohibited data: - raw secrets - customer PII unless masked - production credentials policy assistant: users: - all employees allowed data: - approved internal policies - employee handbook - security standards prohibited data: - confidential investigations - HR restricted records devsecops assistant: users: - engineering - devsecops allowed data: - non-secret source code - architecture docs - IaC templates prohibited data: - private keys - production secrets - customer data incident response assistant: users: - security-incident-response allowed data: - incident tickets - WAF logs - CloudTrail - EDR summaries prohibited data: - unmasked customer PII unless approved This is safer than a general-purpose AI portal with no business context. Step 2: Put SSO and RBAC in Front Use your identity provider. Example: Google Workspace / Okta / Entra ID ↓ SAML or OIDC ↓ Internal AI Portal ↓ RBAC by group Example access model: roles: employee: workflows: - policy assistant - writing assistant engineer: workflows: - policy assistant - devsecops assistant - code explainer security engineer: workflows: - security report summarizer - incident response assistant - threat intel assistant executive: workflows: - executive risk summary - policy assistant Step 3: Use Bedrock Guardrails Create different guardrails for different workflows. Example: guardrails: employee general guardrail: block: - credentials - PII - confidential financial data - harmful content mask: - email addresses where not required - phone numbers - personal identifiers security workflow guardrail: block: - credentials - private keys - exploit instructions outside approved workflow allow with logging: - CVE analysis - incident summaries - threat intelligence engineering guardrail: block: - hardcoded secrets - customer data - production credentials allow: - code explanation - test generation - Terraform review - Kubernetes manifest review The operational point is important: Different workflows need different guardrails. A security analyst investigating a WAF rule should be allowed to discuss malicious payloads. A general employee chatbot should not. Step 4: Add Deterministic Policy Before Bedrock Guardrails are important, but the architecture should not rely only on the model safety layer. Add deterministic checks before the model call. Request arrives ↓ Authenticate user ↓ Check workflow permission ↓ Check data classification ↓ Run DLP ↓ Apply Bedrock Guardrail ↓ Invoke model Example pre-check: python def authorize ai request user, workflow, prompt, attached files : if not user.is authenticated: return "block", "User is not authenticated" if workflow not in user.allowed workflows: return "block", "User is not authorized for this workflow" if contains secret prompt or files contain secret attached files : return "block", "Secrets are not allowed in AI prompts" if workflow == "general employee assistant" and contains customer pii prompt : return "block", "Customer PII is not allowed in this workflow" return "allow", "Request approved" Step 5: Protect Retrieval-Augmented Generation RAG can become a data leakage path if permissions are not enforced. Bad pattern: Index all company documents Let the model answer anything from the index Good pattern: User asks question ↓ Check user identity ↓ Retrieve only documents the user is allowed to access ↓ Filter sensitive content ↓ Send minimal context to model ↓ Return answer with citations If the user cannot access a document in Google Drive, Confluence, Jira, or S3, the AI should not be able to reveal it. Step 6: Add Human Approval for High-Risk Actions For AI agents, the biggest risk is not answering a question. It is taking action. High-risk actions should require approval: approval required for: - sending external emails - creating or deleting cloud resources - changing IAM policies - modifying Kubernetes deployments - closing security findings - creating production firewall rules - changing WAF rules - opening public GitHub pull requests - exporting customer records Recommended flow: AI proposes action ↓ Policy engine checks risk ↓ Human reviewer approves ↓ Action is executed by controlled service account ↓ Audit log records who approved and what changed Do not let an AI model directly hold standing admin credentials. Step 7: Log the Right Events For Bedrock-based applications, log: audit events: - user identity - workflow name - model ID - guardrail ID - input policy decision - output policy decision - DLP result - retrieved document IDs - action requested - approval status - timestamp - latency - token usage Do not store sensitive prompt payloads by default unless there is a clear legal and security requirement. Use short retention for sensitive debug logs. Example Bedrock AI Portal Policy policy name: Internal Bedrock AI Assistant rules: - name: Require SSO if: user authenticated: false then: action: block - name: Enforce Workflow Authorization if: requested workflow: not allowed for user then: action: block - name: Block Secrets if: prompt or file contains: - private key - aws secret access key - github token - database password then: action: block - name: Restrict Customer Data if: data type: customer pii workflow: not in - approved customer support ai - approved security ir ai then: action: block - name: Apply Bedrock Guardrail if: previous checks: passed then: action: evaluate with bedrock guardrail - name: Require Human Approval if: requested action: - modify iam - deploy to production - send external email - close security finding then: action: require approval Solving the Full Problem: Governing AI Usage on Company-Managed Devices Now let’s combine the three use cases into a single enterprise architecture. Recommended End-State Architecture ┌──────────────────────────┐ │ Company Identity Provider │ │ Google / Okta / Entra ID │ └─────────────┬────────────┘ │ v ┌──────────────────────┐ ┌──────────────────────┐ │ Managed User Device │──────▶│ Cloudflare Gateway │ │ MDM + WARP + Browser │ │ SWG + DLP + CASB │ └──────────────────────┘ └──────────┬───────────┘ │ ┌───────────────────────┼───────────────────────┐ │ │ │ v v v ┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐ │ Approved AI SaaS │ │ Unapproved AI SaaS │ │ Internal AI Portal │ │ ChatGPT Enterprise │ │ Block / Warn / Log │ │ AWS Bedrock-based │ │ Claude Enterprise │ └────────────────────┘ └─────────┬──────────┘ │ Gemini Workspace │ │ └────────────────────┘ v ┌────────────────────┐ │ Bedrock Guardrails │ │ Input + Output │ └─────────┬──────────┘ │ v ┌────────────────────┐ │ Bedrock Models │ └────────────────────┘ Application AI Traffic: ┌──────────────────────┐ │ Internal Apps │ │ Security / DevOps │ └──────────┬───────────┘ │ v ┌──────────────────────┐ │ AI Policy Middleware │ └──────────┬───────────┘ │ v ┌──────────────────────┐ │ Cloudflare AI Gateway│ └──────────┬───────────┘ │ v ┌──────────────────────┐ │ External Model APIs │ └──────────────────────┘ Central Monitoring: All layers → SIEM / Security Data Lake / Audit Dashboard What Each Layer Owns | Layer | Primary Purpose | Controls | |---|---|---| | MDM | Device enforcement | Agent deployment, certificate install, prevent bypass | | SWG | Browser traffic control | DNS/HTTP/TLS inspection, allow/block AI tools | | DLP | Data protection | Detect secrets, PII, source code, regulated data | | CASB | SaaS AI posture | Tenant controls, app posture, out-of-band visibility | | Cloudflare AI Gateway | App/API AI traffic | Logging, analytics, caching, rate limits, retries, fallback | | AWS Bedrock | Internal AI platform | Governed model access, Guardrails, internal workflows | | SIEM | Monitoring and response | Alerts, audit trails, investigation | The Minimum Viable Control Plan If starting from zero, implement in this order. Phase 1: Policy and Visibility Create the AI Acceptable Use Policy. Define: Approved AI tools Restricted AI tools Blocked AI tools Allowed data Prohibited data Exception process Logging expectations Disciplinary and incident handling process Start logging AI destinations through secure web gateway. Output: AI usage inventory Top AI domains Top users Top departments Known risky tools Initial exception list Phase 2: Managed Device Enforcement Deploy enforcement through MDM. MDM ↓ Cloudflare WARP / secure proxy ↓ TLS certificate ↓ Browser restrictions ↓ Gateway policies Controls: Block unknown AI tools Allow approved AI tools Warn on restricted AI tools Block file upload to public AI tools Log all AI traffic Phase 3: DLP for AI Prompts and Uploads Create AI-specific DLP policies. Start in monitor mode first. Then move to enforcement. Monitor → Warn → Block Do not go directly to aggressive blocking without tuning. Security teams will drown in false positives and users will work around the control. Phase 4: Enterprise AI Tenant Enforcement Move users away from personal AI accounts. Allow corporate ChatGPT Enterprise Block personal ChatGPT where possible Allow corporate Claude Enterprise Block personal Claude where possible Allow corporate Gemini Workspace Block personal Gemini where possible Phase 5: Internal AI Portal on Bedrock Build the safe path for sensitive work. ai.company.com Start with a few workflows: Security finding summarizer Policy Q&A DevSecOps assistant Executive risk summary generator Incident report assistant Add: SSO RBAC Bedrock Guardrails DLP pre-checks logging human approval for risky actions Phase 6: Cloudflare AI Gateway for Internal Apps Standardize AI API traffic. All internal apps must call AI through approved gateway paths. No unmanaged AI API keys in application repositories. No direct model provider calls from production workloads without approval. Route app traffic through Cloudflare AI Gateway where appropriate. For AWS-native Bedrock apps, route through your Bedrock policy layer and Guardrails. Recommended AI Usage Policy Wording You can use wording like this in your internal policy: Employees may use approved AI tools for productivity, analysis, drafting, summarization, coding support, and research where the data being submitted is appropriate for the approved tool and tenant. Sensitive company data, customer data, credentials, production logs, source code, regulated data, or confidential documents must not be submitted to public or personal AI tools. Sensitive workflows must use company-approved enterprise AI tenants or the internal AI platform. For engineering: Source code may only be submitted to approved engineering AI tools. Secrets, private keys, tokens, production credentials, customer data, and unreleased security vulnerabilities must not be submitted to external AI tools unless an approved workflow, tenant, and data protection control are in place. For security teams: Security findings, incident data, logs, threat intelligence, and vulnerability details may only be processed through approved security AI workflows where logging, access control, DLP, and guardrails are enabled. For managers: AI-generated output must be reviewed before use in business decisions, customer communication, regulatory reporting, production changes, or security remediation. Common Failure Modes Failure Mode 1: Buying an AI Gateway and Thinking Browser Use Is Controlled Cloudflare AI Gateway is for application AI API traffic. It does not automatically control a user pasting data into ChatGPT from a browser. For that, use SWG, CASB, DLP, tenant controls, and managed device enforcement. Failure Mode 2: Blocking AI Without Providing an Approved Path If you block every AI tool but do not provide an approved alternative, users will find workarounds. Give users: Approved enterprise AI tenant Internal Bedrock AI portal Clear data rules Fast exception process Useful security guidance Failure Mode 3: Logging Sensitive Prompts Everywhere Logging full prompts can create a new sensitive data store. Treat AI logs as sensitive. Use metadata-first logging unless full prompt capture is explicitly required and legally approved. Failure Mode 4: No Tenant Control Allowing chatgpt.com is not enough. You need to distinguish: Corporate ChatGPT Enterprise workspace vs. Personal ChatGPT account The risk profile is different. Failure Mode 5: RAG Without Permission Enforcement If an AI assistant can retrieve documents the user cannot normally access, you have created a privilege escalation path. RAG must enforce document-level permissions before retrieval. Practical Control Matrix | Scenario | Correct Control | Example Decision | |---|---|---| | User pastes customer data into personal ChatGPT | SWG + DLP + tenant control | Block | | User uses ChatGPT Enterprise for low-risk writing | SWG + CASB | Allow and log | | User uploads production logs to public Claude | SWG + DLP | Block | | Internal security app calls Anthropic API | Cloudflare AI Gateway + policy middleware | Allow with logging/rate limits | | DevOps app summarizes Security Hub findings | Bedrock or AI Gateway depending on architecture | Allow through approved workflow | | Internal AI assistant answers policy questions | AWS Bedrock + RAG permissions | Allow | | AI agent wants to change IAM policy | Bedrock workflow + human approval | Require approval | | Unknown AI website appears in traffic logs | SWG discovery | Block or review | Final Recommended Design For company-managed devices, use this design: 1. MDM enforces the control path. 2. Cloudflare Gateway controls browser AI traffic. 3. DLP blocks sensitive prompts and uploads. 4. CASB monitors approved AI tenants. 5. Tenant control blocks personal AI accounts where possible. 6. Cloudflare AI Gateway controls AI API calls from internal applications. 7. AWS Bedrock powers sensitive internal AI workflows. 8. Bedrock Guardrails inspect input and output. 9. RAG enforces source-document permissions. 10. SIEM receives logs from every layer. This gives the organization practical control without unnecessarily suppressing productivity. The key is to avoid mixing up the three layers: Browser AI usage → SWG / CASB / DLP Application AI API traffic → Cloudflare AI Gateway Internal AWS-native AI workflows → AWS Bedrock + Guardrails Once that separation is clear, the architecture becomes easier to implement, explain, audit, and operate.