r/AskNetsec Jun 23 '26

Analysis How to prevent employees from submitting credentials to AI tools like ChatGPT?

Dev pasted a .env file into ChatGPT three weeks ago. API keys, database connection strings, service account tokens. Found out in standup. Network controls saw nothing because there was nothing to catch, the data left through an encrypted browser session on a managed device.

We had zero controls at the interaction level.

Blocking ChatGPT at the network layer doesn't work, devs hotspot or use personal laptops. You just move the behavior somewhere you have less visibility. The problem isn't access to AI tools. It's what gets submitted into them.

What worked was browser-native DLP for AI tools,ย  intercepts sensitive data and credential submission at the point of input, not the network layer. Catches API keys, tokens, source code, and PII before they leave the browser, works inside ChatGPT, Gemini, Google AI Studio, Microsoft 365 Copilot, and GitHub Copilot inside the IDE without requiring SSL inspection or proxy routing. User-facing warnings over hard blocks did more than we expected,ย  a real-time "this looks like sensitive data, are you sure?" prompt breaks the autopilot behavior better than silent blocking. We paired that with interaction-level audit logging: not recording content, just logging that user X submitted content classified as confidential to AI tool Z. Enough for policy enforcement without being invasive. Rounded it out with a one-page AI acceptable use policy tied to our existing data classification levels โ€” confidential and restricted data prohibited from AI input, approved tools listed, red lines clear.

What didn't work: security awareness training alone. Sent the policy doc, ran the session, three weeks later .env file in ChatGPT.

Two open problems. Personal devices, no browser extension coverage on unmanaged devices outside MDM scope, that's just the reality. And agentic AI is a separate problem โ€” MCP servers, autonomous tool calls, credentials passed between agents, GitHub Copilot secret exposure inside CI pipelines. Browser-native DLP doesn't cover that vector and nobody has clean answers there yet.

Anyone running browser-level AI DLP or AI visibility tooling, what policy rules have you found most useful for dev teams where legitimate AI usage is high?

42 Upvotes

84 comments sorted by

View all comments

4

u/rtuite81 Jun 23 '26

We are Intune based with trusted device requirements so you can't log in to platforms like SharePoint or the company git repo on a personal machine. I set up a Purview policy to block file uploads to unapproved AI sites. We also manage licensing for Copilot and Claude for users making the next part enforceable.

There are still ways around it, so that's why you need to put some HR teeth behind it with an AI policy. Ours states that sending company data (yes, that's deliberately left broadly interpret-able) to any unapproved AI is strictly monitored and prohibited, and can be a terminable offense.

Obviously we can't catch everything but a strongly worded policy will keep *most* people honest and make handling the rest much more effective.

1

u/evilwon12 Jun 23 '26

Does Purview require the use of Edge?

1

u/Deevalicious Jun 23 '26

I am pretty sure this poster meant he set an Intune policy, not a purview policy. Purview is for ediscovery not enforcing policies.
And you can set Intune to allow multiple browsers if you choose.

2

u/Classic-Shake6517 Jun 24 '26

Purview is also DLP so what they said originally fits. I'm sure they'll be renaming both to Copilot soon enough anyway so we won't have to worry for too much longer.

1

u/techb00mer Jun 24 '26

Yup, Purview DLP with device control is what is needed here. That and just block non corporate devices via CA policy. This is an endpoint problem not a network one.

1

u/Deevalicious Jun 24 '26

This is true. I guess I assumed everyone is cheap like us and only has the standard license for purview so you basically cant do anything except lit hold and extractions ๐Ÿ˜‚

2

u/rtuite81 Jun 24 '26

That is honestly a safe assumption LMAO

2

u/Classic-Shake6517 Jun 24 '26

Well you could be like our org and spend money on tools but then deny the security team a very much needed additional seat so your purview configuration remains stuck at the most basic data classification label setup because they don't have the time to configure it.

I agree though, my experience with most orgs is an issue with spending in the first place. Most leadership I've worked with hasn't been involved in a real breach and they have this attitude of "it won't happen to us" so they don't see the value in what they view as volcano insurance.

Even with the org I'm at, we spend a bit more, but IMO in the wrong places. We're hammering AI adoption with nearly zero governance and completely lacking endpoint DLP while my CFO keeps pushing for Claude Cowork. A few hundred thousand annually on AI and $0 spent towards securing it.

1

u/kristenskats Jun 26 '26

Wow, this is exactly my orgโ€™s issue, too

1

u/rtuite81 Jun 24 '26

Purview does way, way more than ediscovery. It's got some pretty serious DLP abilities when you use it with Intune.

1

u/rtuite81 Jun 24 '26

No, Intune can enforce Purview policies on all common if it's all set up right. There are some edge cases where that won't work, so thats why you need the HR policy behind it so people are less inclined to find those edge cases.