Anyone enforcing client-side PII redaction before using an AI tool?
Posted by BoOgieymann47@reddit | sysadmin | View on Reddit | 23 comments
We’ve been evaluating internal usage of AI tools across teams (support, HR, ops).
Big issue:
Users are pasting sensitive data into browser-based tools:
- Names + addresses
- Internal tickets
- Occasionally financial info
We can block domains, audit traffic, etc.—but that doesn’t solve the “paste into textbox” problem.
I’ve been experimenting with a browser-layer approach:
- Detect UK-specific PII (postcode, NI, sort code + account number)
- Highlight inline using the Highlight API
- Allow one-click redaction before submission
- Everything runs locally (no outbound calls)
Question:
Has anyone implemented something similar at scale?
Or are you handling this purely via policy + training?
Feels like DLP doesn’t fully cover modern AI usage patterns.
abhi1510@reddit
Are you building by something around this? If so, let me know. I’d love to figure out how this can be solved.
BoOgieymann47@reddit (OP)
Yeah, I’ve been exploring a few ideas. Mostly focused on catching or surfacing sensitive data right at the point of entry, especially in browser-based workflows where a lot of this seems to happen unintentionally.
Still figuring out what works best in practice, but happy to share more if it helps.
False_Ranger2831@reddit
Using a browser-layer approach for local redaction is smart. Many will agree that training and policy is not enough when speed is more important than security for the user. When you collect data before it reaches the cloud, the browser becomes a blocking mechanism rather than an audit audit trail. The demand for “clean” data flows will, by 2026, become the norm, with companies putting data through strict checklists to guarantee the accuracy of customer outreach, and not just for security. Teams are now resorting to tools like LeadScout AI to ensure that the B2B data they ingest in the first place is already highly curated and verified. LeadScout organizes and secures the business profiles that come in while you filter the data going out. This way, your teams can qualify those profiles and rely on AI for outreach without having to dirty their hands and with no risk of “dirty” data.
Josh_Fabsoft@reddit
Full disclosure: I work at FabSf which makes AI File Pro.
Your browser-layer PII detection approach sounds solid for catching obvious patterns. The challenge you're describing is real - once data hits those external AI tools, you've lost control.
We built AI File Pro specifically to address this gap. Instead of trying to redact data before it goes to external AI services, our approach keeps everything on-premises. You get AI-powered document processing, organization, and search without any data ever leaving your network.
For your use case, teams could process support tickets, HR docs, and financial records locally while still getting intelligent file naming, automatic organization, and natural language search. The AI runs entirely within your infrastructure - no API calls to external services where PII could be exposed.
The pricing model is also different - it's a one-time license rather than per-query costs that can get expensive with heavy usage. Plus you maintain complete audit trails since everything stays internal.
Your browser detection is good defense-in-depth, but having a secure alternative for the actual AI processing eliminates the risk entirely. We offer a free 1GB trial if you want to test how it handles your typical document workflows without any external data transmission.
The combination of your client-side detection plus on-prem AI processing would give you pretty comprehensive coverage for this problem.
Josh_Fabsoft@reddit
Full disclosure: I work at FabSoft, which makes AI File Pro.
Your browser-layer PII detection approach sounds solid for catching obvious patterns. The challenge you're describing is real - once data hits those external AI tools, you've lost control.
We built AI File Pro specifically to address this gap. Instead of trying to redact data before it goes to external AI services, our approach keeps everything on-premises. You get AI-powered document processing, organization, and search without any data ever leaving your network.
For your use case, teams could process support tickets, HR docs, and financial records locally while still getting intelligent file naming, automatic organization, and natural language search. The AI runs entirely within your infrastructure - no API calls to external services where PII could be exposed.
The pricing model is also different - it's a one-time license rather than per-query costs that can get expensive with heavy usage. Plus you maintain complete audit trails since everything stays internal.
Your browser detection is good defense-in-depth, but having a secure alternative for the actual AI processing eliminates the risk entirely. We offer a free 1GB trial if you want to test how it handles your typical document workflows without any external data transmission.
The combination of your client-side detection plus on-prem AI processing would give you pretty comprehensive coverage for this problem.
acorn222@reddit
I think prompt security is meant to prevent PII or sensitive data being sent in these chatboxes.
I wouldn't personally recommend it as it's not architected very well though in my opinion and I've tried to get them to patch some issues before I publish my blog post on it.
I'm pretty sure there are a few enterprise DLPs that try to address users sending PII but from what I've seen, they give the users more of a warning after the data has been sent as opposed to before, and send the admins a notification to tell them about it.
Enterprise DLPs also scare me as most (extension based) increase your attack surface and essentially exfiltrate everything you do online.
BoOgieymann47@reddit (OP)
with what I’ve seen as well. A lot of current DLP approaches seem to focus more on detection/alerting after the fact rather than preventing sensitive data from being entered in the first place, and agreed on the extension point — anything that sits in the browser definitely needs careful trust assumptions.
acorn222@reddit
Yeah I think the latency would just be too high if it had to do a round trip to the DLP servers then back to the client to approve the prompt, lots of them use their own LLMs to see if the prompt is safe.
It's also crazy how much these DLPs collect, I've built an automated system to scan for malware and vulnerabilities and DLPs keep getting flagged as malware as they exhibit a lot of the same behavior, but it's going to a "trusted" server instead? They're not even stripping query params!
BoOgieymann47@reddit (OP)
Yeah, latency is definitely one of the big practical constraints, especially if you try to do real-time interception with a server round-trip. On the DLP point, I think that’s the uncomfortable trade-off, anything that inspects browser content at that level inevitably ends up behaving like a high-privilege agent. Even if the intent is legitimate, from a technical perspective, it can look very similar to malicious interception patterns (DOM access, clipboard hooks, network visibility, etc.), so I can see why it would get flagged in security tooling. It really feels like a trust vs visibility trade-off rather than a clean “safe/unsafe” split.
bageloid@reddit
It's negligible(~35msec) in our Forcepoint setup, the DLP processing is done on the same box that hosts the proxy. That's doing exact document matching against millions of statements and an EDM profile that has 12 million or so cells.
Browser based is always going to be the best for prevention, but you can also have other methods on endpoints. Forcepoint(not an ad, it's just what we have) lets you do extension based or endpoint self hosted proxy based detection, with all processing done on agent.
BoOgieymann47@reddit (OP)
Yeah especially keeping processing local to the proxy/agent removes most of the latency concerns And agreed on the trade-off. Anything doing deep inspection at that layer inevitably needs very high privilege access, so the implementation details and trust boundaries become just as important as the detection logic itself.
Interesting that Forcepoint supports both extension-based and endpoint/proxy-based modes that kind of flexibility seems necessary depending on the environment.
bageloid@reddit
They made that pivot when Google announced Manifest V3, which I assume makes life harder for DLP tools.
acorn222@reddit
MV3 did introduce some changes in the web request handling, but it's still very easy to just monkeypatch fetch/xmlhttprequests via the scripting api
bageloid@reddit
I think it was more of a decision to not hinge product functionality on unilateral decisions made by Google.
BoOgieymann47@reddit (OP)
Relying too heavily on browser-level hooks does feel fragile long-term, especially when the platform itself can change capabilities or tighten restrictions. Moving critical logic closer to the endpoint/proxy layer seems like a more stable direction in that sense.
dar0775@reddit
If everything is running locally, whats the problem? which model are you using?
BoOgieymann47@reddit (OP)
If it’s truly local with no external transmission, then the risk is much lower. The concern people usually raise is less about model location and more about whether any data leaves the environment unintentionally through integrations, logging, or browser-based layers.
dar0775@reddit
If you are concerned about egress security than checkout pipelock. That would be suitable in your scrnario.
BoOgieymann47@reddit (OP)
Thanks, I’ll take a look at it. Egress control is definitely part of the broader picture, especially when dealing with browser data flows and inputs.
dar0775@reddit
You need controls at both at endpoint as well as infra/network layer. Plus you need to treat all input data as untrusted data be it user input or uploaded document or received email. For endpoints you can check promptfoo.
BoOgieymann47@reddit (OP)
Layering controls across endpoint, network, and infrastructure is really the only way this holds up in practice, especially with untrusted input coming from so many different sources.
I’ll check out promptfoo as well sounds useful for the endpoint-side validation piece.
Jaaames_Baxterrr@reddit
I use Crowdstrike Data Protection for this. Although it doesn't redact it, it just blocks files/clipboard pasting for the classifications that you set up.
BoOgieymann47@reddit (OP)
Yeah, that’s a solid approach for controlling exfiltration paths like clipboard and file movement. It still leaves the “in-the-moment input” problem, though, where data gets composed or pasted before those controls trigger.