Making Copilot Safe: A Network-Layer DLP Proxy with Pseudonymisation (and a Private LLM When You Need It)

Enterprises want the productivity benefits of Microsoft Copilot and other LLMs without risking exposure of personal data, regulated content, or trade secrets. Native controls help, but they rarely provide real-time, inline enforcement at the network layer, nor do they automatically pseudonymise sensitive data before it reaches an LLM.

AI DataFireWall addresses this by operating as a DLP proxy integrated downstream of your existing secure web gateway (e.g., Zscaler, Palo Alto). It uses advanced pattern matching to detect personal and sensitive data, and then pseudonymises that data inline, so work continues while risk is neutralised. For cases that defy pattern matching like legal privilege, opinion, or legal hold, an optional private LLM can be invoked under policy to raise accuracy and reduce blind spots. When paired with the private LLM, customers in trial are seeing ~98% accuracy on sensitive-content detection across conventional and non-conventional patterns (vendor internal benchmarks).

This architecture aligns with how enterprises already deploy network security: composable, layered, and proxy-friendly so you can adopt quickly without breaking TLS or re-plumbing endpoints. It’s a pragmatic path to make Copilot (and the rest of your LLM estate) safe, observable, and compliant.

Threat Model: How Sensitive Data Reaches LLMs

Even well-intentioned users will eventually paste or reference content that shouldn’t be shared with a model. Typical exposure paths include:

• Direct personal data: names, emails, phone numbers, national IDs, bank/health info embedded in prompts or attachments.

• Quasi-identifiers: combinations (role, team, date, postcode) that re-identify individuals at scale.

• Confidential business content: unreleased financials, deal terms, customer lists, roadmap docs.

• Regulatory/hold constraints: content under legal hold, litigation privilege, or sensitive HR investigations.

• Context-driven sensitivity: prompts implying wrongdoing (“this proves…”) or subjective reputational risk that pattern rules don’t capture.

  
  

Native governance tools typically log and control after the fact or at the SaaS boundary. The gap is inline, content-aware enforcement that transforms data (via pseudonymisation) so collaboration can continue safely.

Design Principles

1. Deterministic first, semantic when needed. Use advanced pattern matching to catch personal and sensitive data with predictable, explainable rules. Escalate to the private LLM for ambiguous cases (privilege, opinion, legal hold) controlled by policy.

2. Pseudonymise rather than block (by default). Identify and replace risky fields (e.g., “Jane Doe”, “john.doe@company.com”) with consistent pseudonyms that preserve workflow and analytical utility (e.g., ben@contextul.io).

3. Stay composable. Chain as a downstream DLP proxy behind your primary SWG (Zscaler, Palo Alto, etc.), leveraging existing TLS, egress, and identity no endpoint agents or certificate surgery required.

4. Minimise blast radius: Be inline only where necessary (e.g., Copilot, Graph API, approved LLM endpoints). Don’t inspect bulk HTTPS, just the high-risk app categories.

5. Auditability and sovereignty: Provide complete event logs without retaining raw payloads; keep any model inference inside the customer trust boundary.

   
   

Reference Architecture (Copilot-First, Estate-Wide Ready)

[User/Device]
     |
     v
[Primary SWG: Zscaler / Palo Alto]
     | (policy routes only LLM/Copilot traffic to DLP chain)
     v
[AI DataFireWall: DLP Proxy]
  - Advanced pattern matching
  - Pseudonymisation / redaction
  - Optional private LLM (policy-triggered)
     |
     v
[LLM Destinations: Microsoft Copilot, Graph API, other approved models]

Why this resonates with enterprises:

• Leverages existing SWG investment and identity posture; no rip-and-replace.

• Separation of concerns: SWG handles TLS, routing, macro policies; DLP proxy handles content-level controls.

• Reduced lock-in and minimal client impact: no endpoint reconfiguration; routing remains familiar.

  
  

Detection & Enforcement

What gets detected (deterministic layer)

• Direct identifiers: names, emails, phone numbers, employee IDs, national IDs.

• Financial & health indicators: IBANs, card PANs (with Luhn checks), MRNs, ICD codes.

• Document markers: “Confidential”, “Attorney-Client Privileged”, internal doc labels.

• Quasi-identifiers: structured combinations (role + unit + date + location) that increase re-identification risk.

Action policies (per data class and destination): allow, mask/pseudonymise, block, quarantine, user-justify + supervisor approve.

When the private LLM is invoked

• Privilege & legal hold: content referencing litigation, protected counsel communication, or mandated preservation.

• Opinion/intent: text that conveys subjective conclusions, whistleblowing, reputational implications.

• Contextual red flags: “this email proves…”, “hide evidence…”, “circumvent control…”.

• Control path: Policy determines LLM use (off by default; enable per app/OU/sensitivity level). The LLM runs privately within your trust boundary; it does not train on your data and is stateless (no retention).

Example policy snippet (illustrative)

rules:
  - id: copilot_personal_data
    match:
      destinations: ["microsoft_copilot","graph_api"]
      detectors: ["email","phone","person_name","employee_id"]
    action: pseudonymise
    logging: full_event_no_payload

  - id: legal_hold_context
    match:
      destinations: ["microsoft_copilot"]
      detectors: []
      private_llm: ["legal_hold","attorney_client_privilege"]
    action: block_with_guidance
    logging: full_event_excerpt

  - id: opinion_reputation
    match:
      destinations: ["approved_llm_list"]
      private_llm: ["opinion_or_reputation_risk"]
    action: require_user_justification
    logging: summary_only

Pseudonymisation: Doing It Right

Goals: preserve utility while removing recognisability.

• Consistency scopes: per-session or per-tenant stable pseudonyms (e.g., Person_42 always maps to the same subject within a case) to support multi-turn prompts and reproducibility.

• Format-preserving: maintain data types (e.g., date → date-like token, email → email-like token) to reduce model confusion.

• Reversibility under strict control: if your legal team needs re-identification, keep keys in a separate KMS/HSM with split duties. Under GDPR, pseudonymised data remains personal data when reversible—treat it accordingly.

• Policy-aware transformations: e.g., pseudonymise for Copilot but block outright for non-approved LLMs.

  
  

Performance & Reliability

• Inline DLP proxy: designed for low-latency transformation. Typical p95 decisioning is sub-100 ms for deterministic rules (guideline; tune per deployment).

• Private LLM path: opt-in per policy; adds variable latency (e.g., 150–300 ms typical guidance), so use selectively (high-risk destinations, privileged keywords, specific OUs).

• Scale-out: stateless workers behind your load balancer with horizontal scaling; pre-warm model runtimes when LLM inspection is enabled.

• Fail modes:

  • Fail-closed for high-risk destinations (e.g., Copilot admin endpoints, legal hold content).

  • Fail-open with alert for low-risk traffic to protect productivity during transient issues.

• Health checks: SWG routes around unhealthy DLP nodes; per-node circuit breakers and back-pressure.

Accuracy: With private LLM enabled for non-conventional patterns, internal benchmarks show 98% overall detection accuracy (blend of deterministic + LLM judgments). Deterministic precision/recall remains tunable via rule granularity and validation sets.

Security, Compliance & Audit

• Data residency: run DLP proxy and private LLM inside your tenant/VPC (UK/EU options) to meet sovereignty needs.

• Encryption: in transit (TLS) end-to-end; at rest for logs/keys; LLM inference is stateless.

• Logging: event-level telemetry (time, user, app, rule, action, detectors fired) with payload minimisation; optional privacy-preserving excerpts for investigations.

• Governance mapping:

  • GDPR (data minimisation, purpose limitation, security by design) via inline transformation and least-retention logs.

  • DPIA/TRA support with pre-filled controls for network placement, data flows, and residual risk.

  • Sector overlays: NHS DSPT, FCA expectations, PCI/HIPAA where applicable (map personal/sensitive classes to your control catalog).

    
    

Integration Recipes - Hypothetical examples

With Zscaler (ZIA)

• Approach: Use policy-based routing so traffic destined to Copilot/Graph/approved LLMs is chained from Zscaler to AI DataFireWall.

• Identity: Preserve user identity headers (e.g., Entra ID) for per-user policy and audit correlation.

• Failover: If DLP chain is unhealthy, Zscaler policy falls back to default path (per risk appetite).

• 
  

With Palo Alto Networks (PAN-OS)

• Approach: Forward proxy or decryption broker patterns with selective decryption/routing to the DLP proxy based on URL categories/app-ID for Copilot/LLMs.

• Separation of duties: PAN-OS handles TLS policies and general web control; AI DataFireWall handles content-aware masking/blocking.

In both patterns, you don’t replace the primary proxy/SWG—you compose a specialised DLP stage for LLM traffic only. This lowers change risk and procurement friction.

SIEM & SOC

• Sentinel/Splunk: ship event summaries + rule IDs; include correlation IDs so SOC can trace a user/session end-to-end.

• Example (Sentinel KQL):

AIDF_Events
| where DestinationApp in ("microsoft_copilot","graph_api")
| summarize Blocks = countif(Action == "block"),
            Masks = countif(Action == "pseudonymise"),
            Allows = countif(Action == "allow")
          by UserPrincipalName, bin(TimeGenerated, 1h)

Operations: Runbooks & KPIs

Runbook highlights

• Rule lifecycle: propose → canary in shadow → promote to prod with time-boxed monitoring.

• False-positive triage: SOC tags event; product team inspects detector hits; adjust thresholds or add allow-lists for low-risk tokens.

• LLM policy tuning: start narrow (legal hold/privilege only), expand to opinion/reputation once baselines stabilise.

KPIs

• Block/Mask Ratio: aim for mask > block to sustain productivity.

• FP Rate on personal-data detectors: <1–3% in steady state (tune per domain).

• LLM-assist Invocation Rate: ideally <10–20% of Copilot traffic; higher suggests tightening deterministic rules.

• Latency p95 per path; alert on LLM-path spikes.

  
  

Possible Rollout Plan (Copilot-First)

1. Discovery & scopingIdentify Copilot endpoints and approved LLMs; classify high-risk groups (Legal, HR, Finance).

2. Pilot in monitor-onlyMirror traffic; collect detections; validate with privacy/legal.

3. Enable pseudonymisation on low-risk cohortsStart with Finance/HR prompts to Copilot; keep private LLM off.

4. Introduce private LLM selectivelyTurn on for legal hold/privilege detection; measure latency and accuracy.

5. Scale to estateAdd Gemini/Bedrock/custom models; refine policies by OU and geography.

6. OperationaliseIntegrate SIEM dashboards, weekly tuning cadences, and governance reporting.

   
   

FAQ & Common Objections

Q: Isn’t this what Microsoft Purview already does?

A: Purview is powerful for classification, labeling, and post-hoc controls. AI DataFireWall provides real-time, inline enforcement with pseudonymisation before model exposure, and adds private LLM inspection for non-pattern risks.

Q: Will this break TLS or require endpoint changes?

A: No. We run as a downstream proxy; your primary SWG keeps handling TLS and device posture. No cert swaps or endpoint agents needed.

Q: Isn’t regex DLP noisy?

A: Basic regex is. Our advanced pattern matching uses multiple signals (checksums/format validation/adjacent context) and can invoke a private LLM to curb false negatives for nuanced risks.

Q: Latency concerns?

A: Deterministic path is designed for sub-100 ms p95 decisions. The private LLM path is policy-gated for high-risk cases only.

Q: Data retention and sovereignty?

A: No raw payload retention; logs are minimised and encrypted. The private LLM runs inside your trust boundary without training on your data.

RFP/Buyer’s Checklist

• Architecture: Downstream DLP proxy compatible with Zscaler/PAN; no endpoint change; no TLS breakage.

• Detection: Advanced pattern matching for personal/sensitive data; policy-controlled private LLM for non-conventional categories.

• Actions: Pseudonymise/block/allow/quarantine with format-preserving transformations and consistent pseudonyms.

• Accuracy: Target ~98% overall when private LLM is enabled for contextual cases (internal benchmarks).

• Performance: Sub-100 ms p95 deterministic; controlled LLM invocation.

• Privacy: Stateless inference; zero retention; EU/UK residency options.

• Audit: Rich event logs without payload storage; SIEM integration; DPIA templates.

• Operations: Canary/tuning workflow, KPIs, runbooks; clear fail-open/closed policies per app risk.

  
  

Conclusion

If you want Copilot to accelerate knowledge work safely, the most reliable control point is the network layer, close enough to be inline and universal, yet modular enough to compose with your existing SWG and governance stack. AI DataFireWall’s approach, deterministic DLP with pseudonymisation, augmented by an optional private LLM for the hard cases, lets you keep the productivity promise of LLMs without accepting data-exposure risk.

It’s a pragmatic design that mirrors how enterprises already secure web, email, and API traffic: defence-in-depth, separation of concerns, and minimal friction to adopt. Start with Copilot, prove value fast, then extend the same guardrails to the rest of your LLM estate, on your terms.