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
.envfiles 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:
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.