{"slug": "controlling-employee-ai-usage-on-managed-devices-browser-controls-cloudflare-ai", "title": "Controlling Employee AI Usage on Managed Devices: Browser Controls, Cloudflare AI Gateway, and AWS Bedrock", "summary": "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.", "body_md": "Employees are already using AI.\n\nThey 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.\n\nThe problem is not that people use AI.\n\nThe 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.\n\nFor 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:\n\n**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**\n\nThese three controls solve different parts of the problem. They are complementary, not interchangeable.\n\n## The Core Problem\n\nA user on a company-managed macOS or Windows device can open a browser and paste sensitive data into an AI chat tool.\n\nThat data may include:\n\n- customer information\n- source code\n- production logs\n- API keys\n- incident reports\n- financial data\n- unreleased business plans\n- internal policy documents\n- vulnerability details\n- cloud account identifiers\n- screenshots from internal systems\n\nFrom a security perspective, this is not only an AI problem. It is a data egress problem.\n\nThe AI tool is simply the destination.\n\nThe right control question is:\n\nHow 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?\n\nTo answer that, the architecture must control three paths.\n\n## Use Case 1: Browser-Based AI Control Requires SWG, CASB, and DLP\n\nThis is the most important use case for governing employee AI usage on company-managed devices.\n\nWhen an employee opens:\n\n```\nhttps://chatgpt.com\nhttps://claude.ai\nhttps://gemini.google.com\nhttps://www.perplexity.ai\n```\n\nthey are using AI through a browser session.\n\nCloudflare 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.\n\nThat inspection path is usually:\n\n```\nManaged Device\n   ↓\nMDM-enforced agent / secure browser / proxy\n   ↓\nSecure Web Gateway\n   ↓\nDLP inspection\n   ↓\nCASB / SaaS policy\n   ↓\nApproved or blocked AI application\n```\n\nIn Cloudflare environments, this usually means Cloudflare One with Gateway, Access, DLP, CASB, and WARP.\n\nCloudflare 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.\n\n### What This Solves\n\nBrowser-based controls address the highest-volume human behavior risk.\n\nThey help answer:\n\n- Which AI tools are employees using?\n- Are they using approved or unapproved tools?\n- Are users pasting sensitive data into AI prompts?\n- Are users uploading confidential files into AI tools?\n- Are users using personal AI accounts instead of enterprise tenants?\n- Which departments or users generate the most AI data exposure risk?\n- Which AI traffic should be blocked, warned, logged, or allowed?\n\nThis is the layer that governs employees using AI through browser sessions.\n\n### Target Architecture\n\n```\n[Company Managed Device]\n        |\n        | MDM-enforced Cloudflare WARP / secure proxy\n        v\n[Cloudflare Gateway]\n        |\n        | DNS + HTTP inspection + TLS inspection\n        v\n[DLP Policy Engine]\n        |\n        | Detect secrets, source code, customer data, PII, financial data\n        v\n[AI Application Policy]\n        |\n        | Allow / block / warn / isolate / log\n        v\n[Approved AI SaaS]\n        |\n        | ChatGPT Enterprise / Claude Enterprise / Gemini Workspace\n        v\n[CASB + SIEM + Audit Logs]\n```\n\n### Practical Implementation\n\n#### Step 1: Define Approved and Unapproved AI Tools\n\nStart with a simple AI application classification model.\n\n```\napproved_ai_tools:\n  - ChatGPT Enterprise\n  - Claude Enterprise\n  - Gemini for Google Workspace\n  - GitHub Copilot Business\n  - Internal Bedrock AI Assistant\n\nrestricted_ai_tools:\n  - personal ChatGPT accounts\n  - personal Claude accounts\n  - personal Gemini accounts\n  - unknown AI writing tools\n  - unreviewed browser-based AI tools\n  - AI tools without enterprise logging or contractual protection\n\nblocked_ai_tools:\n  - AI tools hosted in untrusted jurisdictions\n  - tools with no privacy controls\n  - tools that allow anonymous upload of company files\n  - tools used to bypass company policy\n```\n\nThis gives Security, IT, Legal, and business teams a shared control vocabulary.\n\nDo not start with a vague policy like “use AI responsibly.” Translate the policy into enforceable categories.\n\n#### Step 2: Enroll Managed Devices\n\nFor company-managed devices, traffic enforcement should be pushed through MDM.\n\nFor macOS, use your MDM platform to deploy:\n\n- Cloudflare WARP client\n- device certificate\n- Cloudflare root certificate for TLS inspection\n- browser configuration profiles\n- DNS/proxy enforcement profile\n- controls that prevent users from disabling the agent\n- posture checks for device compliance\n\nFor Windows, use Intune, GPO, or equivalent endpoint management.\n\nThe goal is simple:\n\n```\nNo managed device should access AI SaaS directly without passing through the corporate control path.\n```\n\n#### Step 3: Enable DNS and HTTP Inspection\n\nDNS control alone is not sufficient.\n\nDNS can tell you that the user visited `chatgpt.com`\n\n. It cannot reliably inspect what the user pasted into the prompt.\n\nTo inspect browser-submitted content, you need HTTP inspection and, in most cases, TLS inspection.\n\nThat means:\n\n```\nUser browser\n   ↓ encrypted HTTPS\nCloudflare certificate trusted by device\n   ↓ inspected by Gateway\nPolicy decision\n   ↓ re-encrypted HTTPS\nAI SaaS destination\n```\n\nWithout TLS inspection, your control will mostly be domain-level allow/block.\n\nWith TLS inspection, you can enforce prompt-level DLP and file-upload controls where supported.\n\n#### Step 4: Create DLP Profiles for AI Prompts\n\nCreate DLP profiles specifically for AI usage.\n\nGeneric 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.\n\nRecommended profiles:\n\n```\ndlp_profiles:\n  credentials_and_secrets:\n    examples:\n      - AWS access keys\n      - GitHub tokens\n      - private keys\n      - OAuth client secrets\n      - database passwords\n      - Kubernetes secrets\n      - JWT signing keys\n\n  source_code:\n    examples:\n      - application code\n      - Terraform modules\n      - Kubernetes manifests\n      - CI/CD pipeline files\n      - authentication logic\n      - payment logic\n\n  customer_data:\n    examples:\n      - customer names\n      - emails\n      - account numbers\n      - transaction records\n      - support tickets\n      - CRM exports\n\n  production_logs:\n    examples:\n      - authentication logs\n      - WAF logs\n      - API Gateway logs\n      - database logs\n      - incident evidence\n\n  regulated_data:\n    examples:\n      - PCI data\n      - health data\n      - financial records\n      - government identifiers\n      - HR records\n```\n\nUse different actions depending on severity.\n\n```\npolicy_actions:\n  secrets_detected:\n    action: block\n    user_message: \"This prompt appears to contain credentials or secrets. Submission is blocked.\"\n\n  customer_pii_detected:\n    action: block_or_require_approved_ai\n    user_message: \"Customer data must only be used in approved enterprise AI tools.\"\n\n  source_code_detected:\n    action: allow_only_for_approved_engineering_ai\n    user_message: \"Source code can only be submitted to approved engineering AI environments.\"\n\n  low_risk_business_text:\n    action: allow_with_logging\n```\n\n#### Step 5: Control File Uploads\n\nPrompt text is not the only risk.\n\nUsers may upload:\n\n- PDFs\n- spreadsheets\n- CSV exports\n- screenshots\n- source code archives\n- incident reports\n- architecture diagrams\n- contract documents\n\nThe policy should treat uploads as higher risk than short typed prompts.\n\nExample policy:\n\n```\nIf destination is public AI tool\nAND action is file upload\nTHEN block.\n\nIf destination is approved enterprise AI tenant\nAND file contains sensitive data\nTHEN allow only for approved groups or require warning/justification.\n\nIf destination is internal AI portal\nTHEN allow based on user role and data classification.\n```\n\n#### Step 6: Enforce Tenant Control\n\nThis is where many organizations create avoidable gaps.\n\nThey allow `chatgpt.com`\n\n, but users log in with personal accounts.\n\nThat creates a gap:\n\n```\nSame domain\nDifferent risk\n```\n\nA corporate ChatGPT Enterprise workspace does not carry the same risk profile as a personal ChatGPT account. The same is true for Claude and Gemini.\n\nUse tenant controls where available to enforce:\n\n```\nAllow corporate tenant\nBlock personal tenant\nBlock unmanaged accounts\n```\n\nFor Google Workspace environments, this becomes especially important because personal Google accounts and corporate Google accounts may access similar services.\n\n#### Step 7: Send Logs to SIEM\n\nAt minimum, log:\n\n```\nai_usage_log_fields:\n  - user\n  - device\n  - department\n  - source_ip\n  - destination_ai_app\n  - approved_or_unapproved_tool\n  - action\n  - policy_decision\n  - DLP profile matched\n  - severity\n  - timestamp\n  - file upload indicator\n  - tenant/account type if available\n```\n\nRoute these logs to your SIEM or data lake.\n\nDetection examples:\n\n```\nAlert when one user triggers more than 5 AI DLP blocks in 24 hours.\n\nAlert when source code is repeatedly submitted to unapproved AI tools.\n\nAlert when a privileged engineer attempts to paste production secrets into AI.\n\nAlert when a user accesses a newly observed AI domain.\n\nAlert when an unmanaged device accesses approved AI tools without posture compliance.\n```\n\n### Example Browser Policy\n\n```\npolicy_name: Control Browser AI Usage\n\nconditions:\n  destination_category: AI Tools\n  device_posture: managed\n  identity_provider: corporate_sso\n\nrules:\n  - name: Block Secrets in AI Prompts\n    if:\n      dlp_match:\n        - aws_access_key\n        - private_key\n        - github_token\n        - database_password\n    then:\n      action: block\n      log: true\n\n  - name: Block File Uploads to Unapproved AI\n    if:\n      ai_tool_status: unapproved\n      action: file_upload\n    then:\n      action: block\n      log: true\n\n  - name: Allow Approved Enterprise AI\n    if:\n      ai_tool_status: approved\n      tenant: corporate\n      dlp_match: none\n    then:\n      action: allow\n      log: true\n\n  - name: Warn on Low-Risk Prompt to Unapproved AI\n    if:\n      ai_tool_status: unapproved\n      dlp_match: none\n    then:\n      action: warn\n      log: true\n```\n\n### What This Does Not Solve\n\nBrowser controls do not fully govern your own AI applications.\n\nThey also do not provide deep model behavior controls such as:\n\n- prompt template governance\n- model selection\n- model fallback\n- token budget enforcement\n- model output filtering\n- agent tool approval\n- retrieval policy\n- application-level audit trail\n\nThat is where Cloudflare AI Gateway and AWS Bedrock come in.\n\n## Use Case 2: Cloudflare AI Gateway Controls API Traffic from Apps\n\nCloudflare AI Gateway is useful when your company has applications that call AI models through APIs.\n\nExample:\n\n```\nSecurity reporting app\n   ↓\nCloudflare AI Gateway\n   ↓\nOpenAI / Anthropic / Google / Workers AI / other supported model provider\n```\n\nThis is materially different from browser-based AI usage.\n\nCloudflare 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.\n\nCloudflare describes AI Gateway as a way to observe and control AI applications with analytics, logging, caching, rate limiting, retries, and model fallback.\n\n### What This Solves\n\nCloudflare AI Gateway addresses the application AI governance problem.\n\nIt helps answer:\n\n- Which internal application is calling which model?\n- How many tokens are being used?\n- What is the cost trend?\n- Which model provider is failing?\n- Which application is abusing AI calls?\n- Should requests be cached?\n- Should traffic fall back to another model?\n- Which API keys and model endpoints are being used?\n- Can AI traffic be centrally logged?\n\nThis is useful for platform engineering, DevSecOps, application teams, and security operations.\n\n### Target Architecture\n\n```\n[Internal Application]\n        |\n        | API request\n        v\n[Company AI Client SDK / Proxy Wrapper]\n        |\n        v\n[Cloudflare AI Gateway]\n        |\n        | Logging, analytics, caching, rate limiting, retries, fallback\n        v\n[Model Provider]\n        |\n        | OpenAI / Anthropic / Google / Workers AI / others\n        v\n[Response]\n        |\n        v\n[Application]\n```\n\n### Example Enterprise Use Cases\n\nCloudflare AI Gateway is a good fit for:\n\n```\nSecurity Hub finding summarizer\nGuardDuty alert explanation tool\nDatadog log summarization assistant\ncustomer support AI assistant\ninternal documentation chatbot\ndeveloper code review helper\nAI-powered compliance evidence summarizer\n```\n\nThese are controlled application workflows, not unmanaged browser sessions.\n\n### Practical Implementation\n\n#### Step 1: Inventory AI API Usage\n\nIdentify where teams are calling AI APIs.\n\nLook for:\n\n```\nOPENAI_API_KEY\nANTHROPIC_API_KEY\nGOOGLE_API_KEY\nBEDROCK\nLLM\nchat.completions\nmessages.create\n```\n\nSearch in:\n\n- GitHub repositories\n- CI/CD variables\n- Kubernetes secrets\n- Terraform state\n- developer documentation\n- Datadog logs\n- AWS Secrets Manager\n- local\n`.env`\n\nfiles where possible - platform engineering service catalogs\n\nThe goal is to stop teams from independently wiring AI providers with unmanaged keys and inconsistent logging.\n\n#### Step 2: Create a Standard AI API Route\n\nInstead of allowing this:\n\n```\nApplication → OpenAI directly\nApplication → Anthropic directly\nApplication → Google directly\n```\n\nforce this:\n\n```\nApplication → Cloudflare AI Gateway → Model provider\n```\n\nThis lets the company centralize:\n\n- observability\n- rate limits\n- caching\n- retries\n- fallback\n- usage analytics\n- traffic ownership\n\n#### Step 3: Require Application Identity\n\nDo not treat all AI API calls as the same risk.\n\nEach app should have its own identity.\n\nExample:\n\n```\nai_applications:\n  security-reporting-service:\n    owner: security-engineering\n    allowed_models:\n      - claude-sonnet\n      - gpt-4-class-model\n    monthly_budget_usd: 500\n    log_level: metadata_and_policy\n    data_allowed: security_findings_without_secrets\n\n  customer-support-assistant:\n    owner: customer-operations\n    allowed_models:\n      - approved-support-model\n    monthly_budget_usd: 2000\n    log_level: metadata_only\n    data_allowed: sanitized_customer_cases\n\n  developer-code-helper:\n    owner: platform-engineering\n    allowed_models:\n      - approved-code-model\n    monthly_budget_usd: 1000\n    log_level: metadata_and_dlp\n    data_allowed: non-secret_source_code\n```\n\n#### Step 4: Add Pre-Gateway Policy Checks\n\nCloudflare AI Gateway gives you application AI traffic control, but you should still add a policy layer before model invocation.\n\nRecommended pattern:\n\n```\nApplication\n   ↓\nCompany AI Policy Middleware\n   ↓\nDLP / classification / authorization\n   ↓\nCloudflare AI Gateway\n   ↓\nModel Provider\n```\n\nThe middleware should check:\n\n```\npre_request_checks:\n  - user identity\n  - application identity\n  - data classification\n  - prompt size\n  - secret detection\n  - customer data detection\n  - approved use case\n  - model allow-list\n  - budget limit\n```\n\nThis avoids sending sensitive content to the model provider just because the app can reach the gateway.\n\n#### Step 5: Add Cost and Abuse Controls\n\nAI cost can quickly become an operational and financial control issue.\n\nImplement:\n\n```\ncontrols:\n  - per-application rate limit\n  - per-user rate limit\n  - monthly token budget\n  - model allow-list\n  - block expensive models for low-value workflows\n  - cache repeated prompts where appropriate\n  - alert on sudden usage spikes\n```\n\nExample detection:\n\n```\nAn internal documentation chatbot normally uses 100k tokens per day.\nIt suddenly uses 8 million tokens in 2 hours.\nTrigger alert and throttle.\n```\n\n#### Step 6: Log for Audit, But Be Careful\n\nDo not blindly log full prompts and responses when they may contain sensitive data.\n\nRecommended logging model:\n\n```\nlogging_strategy:\n  metadata:\n    - application\n    - user\n    - model\n    - provider\n    - token_count\n    - latency\n    - policy_decision\n    - cost estimate\n    - error status\n\n  sensitive_payloads:\n    default: do_not_log\n    exception: approved_debug_mode_with_retention_limit\n```\n\nFor regulated environments, prompt logging can become a second data leakage path.\n\n### Example App Gateway Policy\n\n```\npolicy_name: Internal AI API Gateway Control\n\nrules:\n  - name: Require Approved Application\n    if:\n      application_identity: unknown\n    then:\n      action: block\n\n  - name: Block Secrets Before Model Call\n    if:\n      prompt_contains:\n        - private_key\n        - aws_secret_access_key\n        - github_token\n    then:\n      action: block\n\n  - name: Enforce Model Allow List\n    if:\n      requested_model: not_in_application_allow_list\n    then:\n      action: block\n\n  - name: Apply Budget Control\n    if:\n      monthly_budget_remaining: exceeded\n    then:\n      action: throttle_or_block\n\n  - name: Route Approved Traffic\n    if:\n      policy_decision: allow\n    then:\n      route: cloudflare_ai_gateway\n```\n\n### Where This Fits with Browser Control\n\nUse Cloudflare Gateway, CASB, and DLP for users in browsers.\n\nUse Cloudflare AI Gateway for company applications calling AI providers through APIs.\n\nBoth should send logs to the SIEM, but they operate at different layers.\n\n```\nBrowser AI usage:\nUser browser → SWG/CASB/DLP → AI SaaS\n\nApplication AI usage:\nInternal app → AI Gateway → Model provider\n```\n\n## Use Case 3: AWS Bedrock Controls Bedrock-Based AI Applications\n\nAWS Bedrock is the right control point when the organization wants to build a company-owned AI service.\n\nThis is usually the cleanest model for sensitive workflows.\n\nInstead of telling users:\n\nGo to ChatGPT and paste this security report.\n\nyou provide:\n\n```\nhttps://ai.company.com\n```\n\nThe user authenticates with corporate SSO, chooses an approved workflow, and the request is processed through policy, Bedrock Guardrails, logging, and access control.\n\n### What This Solves\n\nAWS Bedrock addresses the internal governed AI platform problem.\n\nIt helps answer:\n\n- Which users can use which internal AI workflows?\n- Which models are approved?\n- Which prompts are allowed?\n- Which responses should be blocked or masked?\n- Which workflows can use internal documents?\n- Which actions require human approval?\n- How do we keep sensitive workflows inside AWS?\n- How do we enforce guardrails before and after model invocation?\n\nAWS 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`\n\nAPI independently, allowing applications to evaluate text without invoking a foundation model.\n\n### Target Architecture\n\n```\n[Employee]\n    |\n    v\n[Internal AI Portal]\n    |\n    v\n[Google SSO / Okta / Entra ID]\n    |\n    v\n[Authorization Layer]\n    |\n    v\n[Prompt Policy Engine]\n    |\n    v\n[Amazon Bedrock Guardrails - Input]\n    |\n    v\n[Amazon Bedrock Model]\n    |\n    v\n[Amazon Bedrock Guardrails - Output]\n    |\n    v\n[Audit Logging]\n    |\n    v\n[Employee]\n```\n\nFor RAG:\n\n```\n[Employee]\n    |\n    v\n[Internal AI Portal]\n    |\n    v\n[Identity + Authorization]\n    |\n    v\n[Retriever]\n    |\n    | checks document permissions\n    v\n[Kendra / OpenSearch / S3 / Confluence / Google Drive Index]\n    |\n    v\n[Context Assembly]\n    |\n    v\n[Bedrock Guardrails]\n    |\n    v\n[Bedrock Model]\n    |\n    v\n[Response + Citations + Audit]\n```\n\n### Practical Implementation\n\n#### Step 1: Define Internal AI Workflows\n\nDo not start by giving users a generic chatbot with broad, undefined access.\n\nStart with approved workflows.\n\nExample:\n\n```\napproved_internal_ai_workflows:\n  security_report_summarizer:\n    users:\n      - security-engineering\n      - security-management\n    allowed_data:\n      - Security Hub findings\n      - GuardDuty findings\n      - sanitized Datadog logs\n    prohibited_data:\n      - raw secrets\n      - customer PII unless masked\n      - production credentials\n\n  policy_assistant:\n    users:\n      - all_employees\n    allowed_data:\n      - approved internal policies\n      - employee handbook\n      - security standards\n    prohibited_data:\n      - confidential investigations\n      - HR restricted records\n\n  devsecops_assistant:\n    users:\n      - engineering\n      - devsecops\n    allowed_data:\n      - non-secret source code\n      - architecture docs\n      - IaC templates\n    prohibited_data:\n      - private keys\n      - production secrets\n      - customer data\n\n  incident_response_assistant:\n    users:\n      - security-incident-response\n    allowed_data:\n      - incident tickets\n      - WAF logs\n      - CloudTrail\n      - EDR summaries\n    prohibited_data:\n      - unmasked customer PII unless approved\n```\n\nThis is safer than a general-purpose AI portal with no business context.\n\n#### Step 2: Put SSO and RBAC in Front\n\nUse your identity provider.\n\nExample:\n\n```\nGoogle Workspace / Okta / Entra ID\n   ↓\nSAML or OIDC\n   ↓\nInternal AI Portal\n   ↓\nRBAC by group\n```\n\nExample access model:\n\n```\nroles:\n  employee:\n    workflows:\n      - policy_assistant\n      - writing_assistant\n\n  engineer:\n    workflows:\n      - policy_assistant\n      - devsecops_assistant\n      - code_explainer\n\n  security_engineer:\n    workflows:\n      - security_report_summarizer\n      - incident_response_assistant\n      - threat_intel_assistant\n\n  executive:\n    workflows:\n      - executive_risk_summary\n      - policy_assistant\n```\n\n#### Step 3: Use Bedrock Guardrails\n\nCreate different guardrails for different workflows.\n\nExample:\n\n```\nguardrails:\n  employee_general_guardrail:\n    block:\n      - credentials\n      - PII\n      - confidential financial data\n      - harmful content\n    mask:\n      - email addresses where not required\n      - phone numbers\n      - personal identifiers\n\n  security_workflow_guardrail:\n    block:\n      - credentials\n      - private keys\n      - exploit instructions outside approved workflow\n    allow_with_logging:\n      - CVE analysis\n      - incident summaries\n      - threat intelligence\n\n  engineering_guardrail:\n    block:\n      - hardcoded secrets\n      - customer data\n      - production credentials\n    allow:\n      - code explanation\n      - test generation\n      - Terraform review\n      - Kubernetes manifest review\n```\n\nThe operational point is important:\n\n```\nDifferent workflows need different guardrails.\n```\n\nA security analyst investigating a WAF rule should be allowed to discuss malicious payloads. A general employee chatbot should not.\n\n#### Step 4: Add Deterministic Policy Before Bedrock\n\nGuardrails are important, but the architecture should not rely only on the model safety layer.\n\nAdd deterministic checks before the model call.\n\n```\nRequest arrives\n   ↓\nAuthenticate user\n   ↓\nCheck workflow permission\n   ↓\nCheck data classification\n   ↓\nRun DLP\n   ↓\nApply Bedrock Guardrail\n   ↓\nInvoke model\n```\n\nExample pre-check:\n\n``` python\ndef authorize_ai_request(user, workflow, prompt, attached_files):\n    if not user.is_authenticated:\n        return \"block\", \"User is not authenticated\"\n\n    if workflow not in user.allowed_workflows:\n        return \"block\", \"User is not authorized for this workflow\"\n\n    if contains_secret(prompt) or files_contain_secret(attached_files):\n        return \"block\", \"Secrets are not allowed in AI prompts\"\n\n    if workflow == \"general_employee_assistant\" and contains_customer_pii(prompt):\n        return \"block\", \"Customer PII is not allowed in this workflow\"\n\n    return \"allow\", \"Request approved\"\n```\n\n#### Step 5: Protect Retrieval-Augmented Generation\n\nRAG can become a data leakage path if permissions are not enforced.\n\nBad pattern:\n\n```\nIndex all company documents\nLet the model answer anything from the index\n```\n\nGood pattern:\n\n```\nUser asks question\n   ↓\nCheck user identity\n   ↓\nRetrieve only documents the user is allowed to access\n   ↓\nFilter sensitive content\n   ↓\nSend minimal context to model\n   ↓\nReturn answer with citations\n```\n\nIf the user cannot access a document in Google Drive, Confluence, Jira, or S3, the AI should not be able to reveal it.\n\n#### Step 6: Add Human Approval for High-Risk Actions\n\nFor AI agents, the biggest risk is not answering a question. It is taking action.\n\nHigh-risk actions should require approval:\n\n```\napproval_required_for:\n  - sending external emails\n  - creating or deleting cloud resources\n  - changing IAM policies\n  - modifying Kubernetes deployments\n  - closing security findings\n  - creating production firewall rules\n  - changing WAF rules\n  - opening public GitHub pull requests\n  - exporting customer records\n```\n\nRecommended flow:\n\n```\nAI proposes action\n   ↓\nPolicy engine checks risk\n   ↓\nHuman reviewer approves\n   ↓\nAction is executed by controlled service account\n   ↓\nAudit log records who approved and what changed\n```\n\nDo not let an AI model directly hold standing admin credentials.\n\n#### Step 7: Log the Right Events\n\nFor Bedrock-based applications, log:\n\n```\naudit_events:\n  - user identity\n  - workflow name\n  - model ID\n  - guardrail ID\n  - input policy decision\n  - output policy decision\n  - DLP result\n  - retrieved document IDs\n  - action requested\n  - approval status\n  - timestamp\n  - latency\n  - token usage\n```\n\nDo not store sensitive prompt payloads by default unless there is a clear legal and security requirement.\n\nUse short retention for sensitive debug logs.\n\n### Example Bedrock AI Portal Policy\n\n```\npolicy_name: Internal Bedrock AI Assistant\n\nrules:\n  - name: Require SSO\n    if:\n      user_authenticated: false\n    then:\n      action: block\n\n  - name: Enforce Workflow Authorization\n    if:\n      requested_workflow: not_allowed_for_user\n    then:\n      action: block\n\n  - name: Block Secrets\n    if:\n      prompt_or_file_contains:\n        - private_key\n        - aws_secret_access_key\n        - github_token\n        - database_password\n    then:\n      action: block\n\n  - name: Restrict Customer Data\n    if:\n      data_type: customer_pii\n      workflow: not_in\n        - approved_customer_support_ai\n        - approved_security_ir_ai\n    then:\n      action: block\n\n  - name: Apply Bedrock Guardrail\n    if:\n      previous_checks: passed\n    then:\n      action: evaluate_with_bedrock_guardrail\n\n  - name: Require Human Approval\n    if:\n      requested_action:\n        - modify_iam\n        - deploy_to_production\n        - send_external_email\n        - close_security_finding\n    then:\n      action: require_approval\n```\n\n## Solving the Full Problem: Governing AI Usage on Company-Managed Devices\n\nNow let’s combine the three use cases into a single enterprise architecture.\n\n### Recommended End-State Architecture\n\n```\n                           ┌──────────────────────────┐\n                           │ Company Identity Provider │\n                           │ Google / Okta / Entra ID  │\n                           └─────────────┬────────────┘\n                                         │\n                                         v\n┌──────────────────────┐       ┌──────────────────────┐\n│ Managed User Device  │──────▶│ Cloudflare Gateway   │\n│ MDM + WARP + Browser │       │ SWG + DLP + CASB     │\n└──────────────────────┘       └──────────┬───────────┘\n                                          │\n                  ┌───────────────────────┼───────────────────────┐\n                  │                       │                       │\n                  v                       v                       v\n      ┌────────────────────┐   ┌────────────────────┐   ┌────────────────────┐\n      │ Approved AI SaaS   │   │ Unapproved AI SaaS │   │ Internal AI Portal │\n      │ ChatGPT Enterprise │   │ Block / Warn / Log │   │ AWS Bedrock-based  │\n      │ Claude Enterprise  │   └────────────────────┘   └─────────┬──────────┘\n      │ Gemini Workspace   │                                      │\n      └────────────────────┘                                      v\n                                                        ┌────────────────────┐\n                                                        │ Bedrock Guardrails │\n                                                        │ Input + Output     │\n                                                        └─────────┬──────────┘\n                                                                  │\n                                                                  v\n                                                        ┌────────────────────┐\n                                                        │ Bedrock Models     │\n                                                        └────────────────────┘\n\nApplication AI Traffic:\n\n┌──────────────────────┐\n│ Internal Apps        │\n│ Security / DevOps    │\n└──────────┬───────────┘\n           │\n           v\n┌──────────────────────┐\n│ AI Policy Middleware │\n└──────────┬───────────┘\n           │\n           v\n┌──────────────────────┐\n│ Cloudflare AI Gateway│\n└──────────┬───────────┘\n           │\n           v\n┌──────────────────────┐\n│ External Model APIs  │\n└──────────────────────┘\n\nCentral Monitoring:\n\nAll layers → SIEM / Security Data Lake / Audit Dashboard\n```\n\n### What Each Layer Owns\n\n| Layer | Primary Purpose | Controls |\n|---|---|---|\n| MDM | Device enforcement | Agent deployment, certificate install, prevent bypass |\n| SWG | Browser traffic control | DNS/HTTP/TLS inspection, allow/block AI tools |\n| DLP | Data protection | Detect secrets, PII, source code, regulated data |\n| CASB | SaaS AI posture | Tenant controls, app posture, out-of-band visibility |\n| Cloudflare AI Gateway | App/API AI traffic | Logging, analytics, caching, rate limits, retries, fallback |\n| AWS Bedrock | Internal AI platform | Governed model access, Guardrails, internal workflows |\n| SIEM | Monitoring and response | Alerts, audit trails, investigation |\n\n### The Minimum Viable Control Plan\n\nIf starting from zero, implement in this order.\n\n#### Phase 1: Policy and Visibility\n\nCreate the AI Acceptable Use Policy.\n\nDefine:\n\n```\nApproved AI tools\nRestricted AI tools\nBlocked AI tools\nAllowed data\nProhibited data\nException process\nLogging expectations\nDisciplinary and incident handling process\n```\n\nStart logging AI destinations through secure web gateway.\n\nOutput:\n\n```\nAI usage inventory\nTop AI domains\nTop users\nTop departments\nKnown risky tools\nInitial exception list\n```\n\n#### Phase 2: Managed Device Enforcement\n\nDeploy enforcement through MDM.\n\n```\nMDM\n   ↓\nCloudflare WARP / secure proxy\n   ↓\nTLS certificate\n   ↓\nBrowser restrictions\n   ↓\nGateway policies\n```\n\nControls:\n\n```\nBlock unknown AI tools\nAllow approved AI tools\nWarn on restricted AI tools\nBlock file upload to public AI tools\nLog all AI traffic\n```\n\n#### Phase 3: DLP for AI Prompts and Uploads\n\nCreate AI-specific DLP policies.\n\nStart in monitor mode first.\n\nThen move to enforcement.\n\n```\nMonitor → Warn → Block\n```\n\nDo not go directly to aggressive blocking without tuning. Security teams will drown in false positives and users will work around the control.\n\n#### Phase 4: Enterprise AI Tenant Enforcement\n\nMove users away from personal AI accounts.\n\n```\nAllow corporate ChatGPT Enterprise\nBlock personal ChatGPT where possible\n\nAllow corporate Claude Enterprise\nBlock personal Claude where possible\n\nAllow corporate Gemini Workspace\nBlock personal Gemini where possible\n```\n\n#### Phase 5: Internal AI Portal on Bedrock\n\nBuild the safe path for sensitive work.\n\n```\nai.company.com\n```\n\nStart with a few workflows:\n\n```\nSecurity finding summarizer\nPolicy Q&A\nDevSecOps assistant\nExecutive risk summary generator\nIncident report assistant\n```\n\nAdd:\n\n```\nSSO\nRBAC\nBedrock Guardrails\nDLP pre-checks\nlogging\nhuman approval for risky actions\n```\n\n#### Phase 6: Cloudflare AI Gateway for Internal Apps\n\nStandardize AI API traffic.\n\n```\nAll internal apps must call AI through approved gateway paths.\nNo unmanaged AI API keys in application repositories.\nNo direct model provider calls from production workloads without approval.\n```\n\nRoute app traffic through Cloudflare AI Gateway where appropriate.\n\nFor AWS-native Bedrock apps, route through your Bedrock policy layer and Guardrails.\n\n## Recommended AI Usage Policy Wording\n\nYou can use wording like this in your internal policy:\n\nEmployees 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.\n\nFor engineering:\n\nSource 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.\n\nFor security teams:\n\nSecurity 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.\n\nFor managers:\n\nAI-generated output must be reviewed before use in business decisions, customer communication, regulatory reporting, production changes, or security remediation.\n\n## Common Failure Modes\n\n### Failure Mode 1: Buying an AI Gateway and Thinking Browser Use Is Controlled\n\nCloudflare AI Gateway is for application AI API traffic.\n\nIt does not automatically control a user pasting data into ChatGPT from a browser.\n\nFor that, use SWG, CASB, DLP, tenant controls, and managed device enforcement.\n\n### Failure Mode 2: Blocking AI Without Providing an Approved Path\n\nIf you block every AI tool but do not provide an approved alternative, users will find workarounds.\n\nGive users:\n\n```\nApproved enterprise AI tenant\nInternal Bedrock AI portal\nClear data rules\nFast exception process\nUseful security guidance\n```\n\n### Failure Mode 3: Logging Sensitive Prompts Everywhere\n\nLogging full prompts can create a new sensitive data store.\n\nTreat AI logs as sensitive.\n\nUse metadata-first logging unless full prompt capture is explicitly required and legally approved.\n\n### Failure Mode 4: No Tenant Control\n\nAllowing `chatgpt.com`\n\nis not enough.\n\nYou need to distinguish:\n\n```\nCorporate ChatGPT Enterprise workspace\nvs.\nPersonal ChatGPT account\n```\n\nThe risk profile is different.\n\n### Failure Mode 5: RAG Without Permission Enforcement\n\nIf an AI assistant can retrieve documents the user cannot normally access, you have created a privilege escalation path.\n\nRAG must enforce document-level permissions before retrieval.\n\n## Practical Control Matrix\n\n| Scenario | Correct Control | Example Decision |\n|---|---|---|\n| User pastes customer data into personal ChatGPT | SWG + DLP + tenant control | Block |\n| User uses ChatGPT Enterprise for low-risk writing | SWG + CASB | Allow and log |\n| User uploads production logs to public Claude | SWG + DLP | Block |\n| Internal security app calls Anthropic API | Cloudflare AI Gateway + policy middleware | Allow with logging/rate limits |\n| DevOps app summarizes Security Hub findings | Bedrock or AI Gateway depending on architecture | Allow through approved workflow |\n| Internal AI assistant answers policy questions | AWS Bedrock + RAG permissions | Allow |\n| AI agent wants to change IAM policy | Bedrock workflow + human approval | Require approval |\n| Unknown AI website appears in traffic logs | SWG discovery | Block or review |\n\n## Final Recommended Design\n\nFor company-managed devices, use this design:\n\n```\n1. MDM enforces the control path.\n2. Cloudflare Gateway controls browser AI traffic.\n3. DLP blocks sensitive prompts and uploads.\n4. CASB monitors approved AI tenants.\n5. Tenant control blocks personal AI accounts where possible.\n6. Cloudflare AI Gateway controls AI API calls from internal applications.\n7. AWS Bedrock powers sensitive internal AI workflows.\n8. Bedrock Guardrails inspect input and output.\n9. RAG enforces source-document permissions.\n10. SIEM receives logs from every layer.\n```\n\nThis gives the organization practical control without unnecessarily suppressing productivity.\n\nThe key is to avoid mixing up the three layers:\n\n```\nBrowser AI usage → SWG / CASB / DLP\n\nApplication AI API traffic → Cloudflare AI Gateway\n\nInternal AWS-native AI workflows → AWS Bedrock + Guardrails\n```\n\nOnce that separation is clear, the architecture becomes easier to implement, explain, audit, and operate.", "url": "https://wpnews.pro/news/controlling-employee-ai-usage-on-managed-devices-browser-controls-cloudflare-ai", "canonical_source": "https://dev.to/mike_anderson_d01f52129fb/controlling-employee-ai-usage-on-managed-devices-browser-controls-cloudflare-ai-gateway-and-aws-akn", "published_at": "2026-05-21 11:38:03+00:00", "updated_at": "2026-05-21 12:03:16.168426+00:00", "lang": "en", "topics": ["artificial-intelligence", "cybersecurity", "enterprise-software", "data", "cloud-computing"], "entities": ["ChatGPT", "Claude", "Gemini", "Perplexity", "GitHub Copilot", "Cloudflare", "AWS Bedrock"], "alternates": {"html": "https://wpnews.pro/news/controlling-employee-ai-usage-on-managed-devices-browser-controls-cloudflare-ai", "markdown": "https://wpnews.pro/news/controlling-employee-ai-usage-on-managed-devices-browser-controls-cloudflare-ai.md", "text": "https://wpnews.pro/news/controlling-employee-ai-usage-on-managed-devices-browser-controls-cloudflare-ai.txt", "jsonld": "https://wpnews.pro/news/controlling-employee-ai-usage-on-managed-devices-browser-controls-cloudflare-ai.jsonld"}}