Your employees are pasting secrets into ChatGPT & Co-pilot & Claude & DeepSeek? Here's how to actually stop it.

Abir Joshi — Fri, 17 Jul 2026 00:09:33 +0000

Ask any engineering manager whether their team pastes code into ChatGPT and you'll get
a nervous laugh. The honest answer is constantly — a stack trace here, a config file
there, "just cleaning up this SQL." Most of it is harmless. Some of it carries an AWS
key, a database password, or a customer's PII straight to a third-party model.

I've spent the last while looking at how teams try to control this, and most of the
common approaches quietly fail. Here's what doesn't work, what does, and why.

Why this isn't a normal DLP problem

Traditional DLP watches email, file shares, and cloud storage. An AI prompt leak skips
all of them: the data goes from a browser tab to an AI provider's API over HTTPS and
never touches the channels legacy DLP inspects.

It's also invisible after the fact. Once a prompt is sent there's no sent-mail copy, no
uploaded-file record. If you didn't catch it at the moment of submission, you have no
idea it happened. Prevention has to live in the browser, or it doesn't happen at all.

The approaches that don't hold up

Blocking AI tools outright. Employees just switch to their phone or a personal laptop. You lose the productivity and keep the risk.
Network proxies / CASBs. They can see the domain but struggle to inspect encrypted prompt content without heavy MITM infrastructure — and they don't understand a DOCX dropped into a chat window.
Policy + training. Sets expectations, stops nothing in the moment.
Post-hoc SaaS scanners. Find the exposure after the data already left. Good for audit, useless for prevention.

What actually works: intercept in the browser

The only place you can reliably read a prompt is where it's typed. A managed browser
extension can patch the page's network calls, read the prompt (and any attached files)
before they send, scan against your DLP rules, and block anything that matches — all
client-side, in well under a second, with no proxy and no rerouted traffic.

That's the model I've become convinced is right, and it's the approach
Slopfence takes — a browser-native AI security platform
that runs on ChatGPT, Claude, Gemini and Copilot, extracts text from uploaded Office/PDF
files, and blocks or redacts on the ten built-in policies plus your own rules.

A rollout that takes an afternoon

Deploy the extension via Chrome/Edge GPO or your MDM (Jamf/Intune), pre-configured.
Start with default policies (SSNs, cards, AWS keys, PII) active on install.
Run alert-only for a week to baseline what your team is really sending.
Flip high-severity rules to block; scope stricter rules to Finance, Legal, Eng.
Review the audit trail and tune custom rules and document fingerprints.

If you want the deeper version of this playbook — the control matrix, the alert-vs-block
tradeoffs, and the rollout checklist — I wrote it up here:
how to stop secrets leaking to AI.

The uncomfortable truth is that your team has already adopted AI. The question is whether
you can see what they're sending it — and step in before the leak, not after.

API Middleware – a self-hosted API gateway with DLP scanning built in Laravel 11

Abir Joshi — Thu, 02 Apr 2026 13:12:48 +0000

got tired of paying for managed API gateways that didn't let me inspect the data flowing through them. So I built API Middleware — open source, self-hosted, one command to run.

GitHub: https://github.com/joshiabir/theapimiddleware

What it does

API Middleware sits between your clients and your backend services. Instead of clients hitting your backend directly, they hit the gateway, which:

Routes traffic based on the incoming domain
Scans request and response bodies for sensitive data (DLP)
Enforces rate limits (global and per-user)
Checks authentication before forwarding
Logs every request with timing — asynchronously, so it never slows down the client

Everything is configured through a web admin dashboard. No config files, no redeployments — change a DLP rule and it's live in seconds.

Architecture

Two Laravel 11 apps sharing one MySQL database:

fiona — the gateway

Request → policyControl middleware → DLP scan → HTTP proxy → DLP scan → Response
                                                                ↓
                                                         Queue job (logging)

The middleware chain in policyControl:

Looks up the domain in domain_routings
Finds the cluster and API config for the URL
Applies policies: rate limits, auth, IP filtering, honeypot detection
If all checks pass, forwards the request

The proxy uses Laravel's Http::send() with the original headers and method intact. After the response comes back, DLP runs again on the response body. Log writes go to a queue job so they never add latency.

plucker-app — the admin dashboard

Built with Livewire v3 and Jetstream. 54 Livewire components cover:

Domain routing management
Cluster and API configuration
DLP rule editor (keywords, regex patterns, bypass URLs)
Request log viewer with filtering and CSV export
Security incident feed
OAuth login (Google, GitHub, Microsoft)

The database-driven config is the key design decision: fiona reads policy state from the DB on every request, plucker writes to it. No signal needed between the two apps — policy changes are instant.

The DLP engine

Each domain can have multiple DLP policies. The scanner chains them all against the request or response body:

// Keyword match
$redacted_body = preg_replace('/' . preg_quote($policy->value, '/') . '/', '[redacted]', $body);

// Regex pattern match  
$pattern = '~' . $policy->value . '~';
$redacted_body = preg_replace($pattern, '[redacted]', $body);

Actions per policy:

alert — log the match, pass the original body through
redact — replace matches with [redacted] in the forwarded body
block — return 403 if any match is found

Invalid regex patterns are caught and skipped gracefully so one bad rule doesn't break everything.

Setup

git clone https://github.com/joshiabir/theapimiddleware.git
cd theapimiddleware
./setup.sh

The setup script installs Docker if it's not present (macOS via Homebrew, Ubuntu/Debian/Fedora via package manager), generates app keys and DB passwords, writes .env, and starts all containers.

Two services come up:

Gateway (fiona): http://localhost:8000
Admin dashboard (plucker-app): http://localhost:8001

Testing

Full PestPHP test suite using SQLite in-memory — no database needed to run tests.

cd fiona && ./vendor/bin/pest
cd plucker-app && ./vendor/bin/pest

Covers: DLP service logic, policy middleware enforcement, proxy flow, Livewire dashboard components.

Open to feedback on the architecture, especially the shared-DB pattern and the DLP chaining approach. What would you do differently?

DEV Community: Abir Joshi