Skip to main content
Docs
Intro call

Guide

Blocking Shadow AI & Rerouting to BRANE

2026-07-22

Note

Who is this guide for?

Audience: IT leads at our customers (typically 100–2,000 employees, Windows/M365 environment, small IT team).
Purpose: Block public AI services (ChatGPT, Claude, Gemini & co.) on the corporate network in a controlled way and steer employees to the internal BRANE instance.
As of: July 2026. Domains and vendor categories change constantly; always prefer the firewall vendors’ self-updating category filters over hand-maintained lists.

1. Framing: blocking is steering, not a wall

Network blocking does not fully prevent shadow AI — it cannot reach personal smartphones, copy-paste, or AI features embedded in SaaS tools. Its job is different: make the sanctioned internal AI the path of least resistance and create visibility.

The numbers (Germany, 2025/26):

  • ~42% of German companies observe or suspect private AI use; only 26% provide official AI access — just 23% at 20–99 employees (Bitkom, Oct. 2025).
  • 66% of office professionals admit using AI tools they believe are banned. Pure bans push usage onto personal devices — exactly where IT sees nothing.
  • Germany’s data-protection authorities (DSK) explicitly recommend internal usage rules instead of uncontrolled “open” AI systems (guidance “KI und Datenschutz”, 2024).

Tip

Consequence

Always combine blocking + offering an alternative, never block alone. The block redirects — to BRANE.

2. Four-phase approach

Phase 0 — Measure (1–2 weeks, effort: small)

Establish the baseline before enforcing — it doubles as your success metric:

  • M365 environments: Microsoft Defender for Cloud Apps → Cloud Discovery → filter the “Generative AI” category. Shows users and data volume per app — no extra install if Defender for Endpoint (Business Premium/E5) is deployed.
  • Everyone else: run the firewall AI category in monitor mode for 1–2 weeks; analyze DNS/proxy logs against the domains in section 3.
  • Output: which services, how many users, which departments.

Warning

Data protection

Aggregate only — see section 4 (data protection).

Phase 1 — Network block (effort: small to medium)

Path A — firewall category (recommended if an NGFW exists): every mainstream vendor now ships a ready-made, self-updating AI category:

Vendor Category Note
Sophos Firewall App category “Generative AI” (signature pack ≥ 18.20.86) Requires Web Protection / Xstream
Fortinet FortiGate FortiGuard web filter “Artificial Intelligence Technology” (category 100), FortiOS 7.4.1+ Without deep SSL inspection blocking works via SNI (effective, but browser error page instead of block page)
Palo Alto URL category “artificial-intelligence”, plus granular sub-categories (e.g. AI Conversational Assistant) Also offers a “Continue” coaching page
Check Point App category “Generative AI Tools”
Cisco Umbrella / DNSFilter DNS category “Generative AI” New AI apps are added automatically

Path B — DNS filtering (no NGFW license): internal DNS/AD DNS override zones, or Pi-hole/AdGuard Home with a maintained list. Best free list: UT1 “ai” by Université Toulouse (daily GitHub mirror: olbat/ut1-blacklists, file blacklists/ai/domains). Hand-maintained lists go stale within weeks — someone must own maintenance.

Close the bypass routes immediately (mandatory, ~15 minutes each)

  1. Block QUIC/HTTP-3: drop outbound UDP 443 (and UDP 80) — otherwise browsers tunnel past TLS inspection. Clean fallback to TCP, no user impact.
  2. Block DoT: drop outbound TCP/853.
  3. Block DoH: block well-known public DoH resolvers (dns.google, cloudflare-dns.com, 1.1.1.1, 8.8.8.8, 9.9.9.9 …); many NGFWs ship a “DNS over HTTPS” app signature.
  4. Disable browser DoH by policy: Chrome/Edge DnsOverHttpsMode = off via GPO/Intune; Firefox: answer the canary domain use-application-dns.net with NXDOMAIN on internal resolvers and/or enterprise policy DNSOverHTTPS: Enabled=false.

Phase 2 — Friendly redirect instead of an error page (effort: medium)

The difference between “IT blocked something again” and “oh, we actually have something better” is the block page.

The HTTPS problem, stated honestly: if you DNS-sinkhole chatgpt.com to an internal server, browsers first show a TLS certificate warning — the internal server cannot present a valid certificate for chatgpt.com. There are exactly three clean ways out:

  1. Distribute an internal CA to managed devices (GPO/Intune, AD CS or the filter vendor’s CA). The block server then mints valid per-domain certificates. Best UX; managed devices only.
  2. Serve the block page from the firewall/proxy — if TLS inspection is already on, the NGFW serves a proper, customizable block page.
  3. Accept the TLS error and handle the redirect through communication instead (intranet notice, email, browser start page). Zero effort, worst UX.

What a good redirect page contains (the proven “coach page” pattern):

  1. What happened, without blame: “ChatGPT is not available on the company network.”
  2. Why, in one sentence: data protection / customer data — not “forbidden”.
  3. The alternative, one click away: a big button → internal BRANE URL, ideally SSO’d — the user is chatting 10 seconds later.
  4. Escape hatch: contact/form for exceptions and tool requests (offloads the helpdesk and feeds governance).

Minimal example:

<!doctype html><meta charset="utf-8">
<title>External AI is not available here</title>
<div style="max-width:520px;margin:15vh auto;font-family:system-ui;text-align:center">
  <h1>This AI service is not available on the company network</h1>
  <p>To protect customer and company data, AI requests are routed
     through our internal, secure AI platform.</p>
  <p><a href="https://brane.YOUR-DOMAIN.com" style="display:inline-block;
     padding:12px 28px;background:#0085C7;color:#fff;border-radius:8px;
     text-decoration:none;font-weight:600">→ Open BRANE — same question, safely</a></p>
  <p style="color:#667"><small>Need a tool or an exception?
     <a href="mailto:it@YOUR-DOMAIN.com">Contact IT</a></small></p>
</div>

Soft launch: where available, start in warn mode rather than hard block (Microsoft Defender “Warn”, Palo Alto “Continue” page): notice + proceed-at-own-risk, switch to block after 2–4 weeks.

Phase 3 — Operate (ongoing, effort: small)

  • Define an exception process (who can request what, who decides, SLA).
  • Monthly report: block events (firewall/DNS) next to BRANE usage. Success = block events falling because internal usage rises — not because usage moved to phones.
  • Keep category feeds current; with manual lists: quarterly review.

3. Domain reference

Caution

First — two things not to break

  1. Never block openrouter.ai network-wide if your BRANE box uses OpenRouter for cloud routing: scope the block to client subnets and allowlist the appliance IP.
  2. Block API endpoints (Tier 3) only after review — they can hit legitimate developer tooling and line-of-business apps.

Tier 1 — Major consumer chatbots (always block)

Service Domains Notes
ChatGPT chatgpt.com (wildcard) · chat.openai.com (legacy redirect) · ios.chat.openai.com, android.chat.openai.com, desktop.chat.openai.com (native apps!) · auth.openai.com, auth0.openai.com · *.oaistatic.com · *.oaiusercontent.com (file up/downloads) · sora.com, sora.chatgpt.com Do not wildcard *.openai.com — that also kills platform.openai.com (developer console). Never block shared third parties (Stripe, Cloudflare challenges, Intercom) globally.
Claude claude.ai · *.claudeusercontent.com · downloads.claude.ai · optionally platform.claude.com + api.anthropic.com (then also hits API/Claude Code) Cleanest case: all dedicated domains.
Google Gemini gemini.google.com (own A-records, DNS/SNI-blockable) · bard.google.com (legacy) · aistudio.google.com, makersuite.google.com · notebooklm.google.com · API: generativelanguage.googleapis.com Never block by IP, never accounts.google.com. AI answers inside Google Search are not separable via DNS. Google’s supported control is the Workspace service toggle (NotebookLM has its own).
Microsoft Copilot copilot.microsoft.com · copilot.com · copilot.ai · copilot.cloud.microsoft bing.com/chat and m365.cloud.microsoft/chat are not DNS-separable (shared domains). Microsoft explicitly advises against network blocks — supported paths: M365 Integrated Apps block, Edge policies, AppLocker, Tenant Restrictions v2 against personal Microsoft accounts.

Tier 2 — Secondary chatbots (category filters cover most)

perplexity.ai (+ pplx.ai) · poe.com (+ *.poecdn.net) · *.deepseek.com · grok.com + x.ai (note: Grok inside X at x.com/i/grok needs path filtering) · chat.mistral.ai (+ code.mistral.ai) · meta.ai (embedded Meta AI in WhatsApp/Instagram is not separable) · character.ai (+ c.ai) · you.com · pi.ai (+ heypi.com) · chat.qwen.ai + tongyi.aliyun.com · kimi.com (+ kimi.ai, kimi.moonshot.cn) · manus.im · chat.z.ai, chatglm.cn · doubao.com · yuanbao.tencent.com · yiyan.baidu.com · genspark.ai · duck.ai · janitorai.com · jasper.ai · copy.ai · elevenlabs.io

Warning

Special case Hugging Face

huggingface.co/chat is a path only; blocking the whole domain breaks legitimate model downloads.

Tier 3 — API endpoints (decide deliberately)

Endpoint Collateral damage when blocked
api.openai.com All local scripts/SDKs, IDE plugins, business apps with their own keys
api.anthropic.com Claude Code CLI and SDKs entirely
generativelanguage.googleapis.com Gemini SDKs. Never *.googleapis.com — hits Drive, OAuth, GCP
openrouter.ai Web + API on one domain — see warning above (BRANE cloud routing!)
api.mistral.ai, api.groq.com, api.together.ai, api.x.ai, api.deepseek.com, api.perplexity.ai, api.cohere.com, api.fireworks.ai Developer tooling only, low collateral
*.openai.azure.com, bedrock*.amazonaws.com Also hits your own sanctioned Azure OpenAI / Bedrock deployments — never blanket-block
Coding assistants: *.cursor.sh + *.cursorapi.com · *.githubcopilot.com · *.codeium.com/*.windsurf.com Copilot: business-plan endpoints (*.enterprise.githubcopilot.com) can be allowed separately while blocking Free/Pro

Limits of network blocking (communicate honestly)

Not reachable via domains: AI inside Google Search and Bing, Grok inside X, Meta AI inside WhatsApp/Instagram, AI embedded in sanctioned SaaS (Notion, Slack, Zoom, Canva, Grammarly), local in-browser models (WebGPU), personal phones on cellular, copy-paste. Mobile apps additionally use certificate pinning — TLS inspection cannot see them; only hostname blocks plus MDM help. These gaps are why the network layer is combined with an endpoint/browser layer — the BRANE Browser Extension (roadmap) addresses exactly this tier.

Caution

Not legal advice

Align with your DPO and, where needed, employment counsel before rollout.

  • Co-determination (§ 87(1) no. 6 BetrVG): gateways, proxies and filters that log are objectively suitable for behavior monitoring — under settled BAG case law that triggers co-determination, regardless of intent. The Hamburg labor court (16 Jan 2024 – 24 BVGa 1/24) held usage guidelines for ChatGPT via private accounts co-determination-free — but once blocking/rerouting infrastructure with logging runs in your own IT, that ruling explicitly does not carry. Practice: involve the works council early; check and amend the existing IT/internet works agreement. Browser/internet use is often already covered there — then the path is short.
  • Data protection (Art. 6 GDPR, § 26 BDSG): block and DNS logs with user attribution are personal data. Principles: aggregate statistics instead of per-person dashboards, spot checks instead of continuous monitoring, defined retention, DPIA for systematic monitoring. Whether private internet use is permitted materially changes what analysis is allowed — settle and document this first.
  • EU AI Act, Art. 4 (AI literacy): in force since 02/2025, enforceable since 08/2026 — employers must ensure sufficient AI literacy of staff. An AI usage policy + training + a sanctioned internal tool is precisely the compliance artifact Art. 4 expects — this guide contributes directly.
  • Orientation: BSI “Generative AI Models — Opportunities and Risks” (2025), DSK guidance “KI und Datenschutz” (2024), Bitkom guide “Generative KI im Unternehmen”.

5. Communication: announce first, then tighten

The sequence that works:

  1. T−2 weeks: announcement (intranet/email): why (data protection, not distrust), what changes, what exists instead (BRANE, with login link and a 3-line how-to), from when.
  2. T−0: warn mode active (where available), redirect page live.
  3. T+2 to 4 weeks: hard block. In parallel, short BRANE onboarding sessions per department (counts toward AI-Act Art. 4 training).
  4. Ongoing: keep the tool-request channel open; quarterly report to management (internal usage vs. block events).

Announcement snippet:

From [DATE], public AI services such as ChatGPT will no longer be reachable on the company network. The reason is not the AI — it’s where our data flows in the process. From today, [BRANE URL] gives you an internal AI that handles the same tasks while company data never leaves the building. Questions, requests, exceptions: [CONTACT].

6. Checklist

  • Phase 0: 1–2 weeks baseline measurement (Cloud Discovery / firewall monitor mode)
  • Works council informed / works agreement checked
  • Data protection: logging concept (aggregated, retention), DPIA if needed
  • Announcement sent to staff (T−2 weeks)
  • NGFW AI category or DNS filter with maintained list active
  • BRANE box access to openrouter.ai secured via allowlist
  • QUIC (UDP 443), DoT (853), known DoH resolvers blocked; browser DoH off via GPO
  • Redirect page live (internal CA distributed or proxy block page)
  • BRANE button on the block page tested (SSO, 1 click)
  • Warn mode 2–4 weeks, then hard block
  • Exception process defined and communicated
  • Monthly report: block events vs. BRANE usage

Sources (selection)