Are companies preventing sensitive data from being sent to external LLM APIs | Hacker News Reader

Are companies preventing sensitive data from being sent to external LLM APIs

I’m curious how engineering and security teams are handling governance around AI usage inside companies.

As more teams integrate APIs from providers like OpenAI, Anthropic, and other LLM services, it seems possible for sensitive data to accidentally end up in prompts.

Some questions I’m trying to understand:

• Do companies route AI API traffic through some internal gateway or proxy? • How do you prevent sensitive information (customer data, credentials, internal documents) from being sent to external models? • Is AI usage across teams actually tracked anywhere? • If an auditor asked how AI systems are governed in your company, would you have a clear answer?

I’d be interested to hear how teams are currently handling this in practice.

View on HN

The proxy approach in the other comment handles the technical control side well. The harder part is the auditor question you slipped in at the end — that one trips up almost every team I've talked to. Most companies cannot produce a log showing which employee sent what data to which model, when it was authorized, and what classification level it had. The governance infrastructure for AI just isn't there yet, and auditors are starting to catch up.

SOC 2 and ISO 27001 auditors are now explicitly asking for evidence of data flow controls around AI integrations. "Policy says don't paste customer data into ChatGPT" gets zero credit as a control. What they want to see is technical enforcement with logging — something you can point to and say "here is the record of every outbound prompt from the last 90 days, here is what was flagged." If you can't produce that, it's a finding.

The other gap that's easy to miss: most teams don't know what's sensitive until it's already in a prompt. The classification problem comes before the proxy. What are your teams actually pulling into their prompts right now — internal docs, support tickets, code with credentials, database outputs? That's usually where the real exposure surfaces.

Yes, but most are doing it wrong.

The common approaches I've seen: 1. Policy-only ("don't paste sensitive data into ChatGPT") — doesn't work, people do it anyway 2. Network-level blocking (block api.openai.com) — kills legitimate use cases 3. DLP on the network layer — can't inspect the semantic content, just sees HTTPS traffic

What actually works is a proxy-based approach: all LLM API traffic routes through a governance layer that scans the content of every request. PII gets tokenized before reaching the model (SSN becomes [SSN_TOKEN_1], model processes it fine, token gets restored on the way back). Secrets get blocked. Data classification determines which model can be used — RESTRICTED data stays on-prem or goes to a private deployment, PUBLIC data can go to any provider.

The technical challenge is doing this without killing latency or breaking streaming. We got it down to ~250ms overhead with deterministic scanning (regex + normalization, not a second LLM). For streaming responses, you buffer the full response, scan it, then re-chunk — PII never leaks through stream chunks.

The org challenge is that engineering teams will route around any governance that adds friction. The proxy approach works because it's transparent — agents point at "proxy.server.com" instead of api.openai.com and everything else stays the same. Changing env vars, no code changes.

Reply on news.ycombinator.com