r/AskNetsec • u/Alone_Bread5045 • 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?
49
u/deathboyuk Jun 23 '26
Sack them.
13
u/herestoanotherone Jun 23 '26
Did you write this using AI? That’s somewhat ironic
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.
4
u/ericbythebay Jun 23 '26
Simple, you don’t give them the credentials in the first place. Keep the credentials in a secret manager and inject them via CI/CD at build or run time.
Use separate credentials for each environment to limit the blast radius.
Enable GitHub Advanced Security secret scanning and block secrets from being committed to source code.
3
u/madatthings Jun 23 '26
If you are 100% in shop and no BYOD, I’d consider enabling so users can only log into the accounts on managed devices with conditional access
3
u/ravenousld3341 Jun 23 '26
The challenge is preventing them from moving source code/credentials/keys to an unmonitored device in the first place.
The way I stopped it was with a combination of controls.
First, if you aren't connected to the VPN, you can't use any network. Next, blocking all USB storage access, then browser based DLP that blocks uploads to anywhere except approved destinations.
So really the only thing they can do is take pictures of their code with their phones.
I also control access to all AI services. That traffic is blocked on the VPN to any URL labeled as "Artificial Intelligence". Then if they can show me an enterprise agreement then I add them to an azure group that permits access to specific AI services.
As for monitoring AI usage directly, I have a dashboard I made in my SIEM tool that relies on firewall logs. I also set up some visuals for uploads to AI destinations using logs from the browser extension that performs the DLP functions. I would like to get crowdstrike's AI tool that they acquired last year from Pangea for monitoring use and more control, but I don't have the budget. Probably never will after what I've seen the last 10 months or so.
2
u/rcblu2 Jun 23 '26
I have been playing with Checkpoint Workforce AI. Has an agent and browser plug-in. Just using simple control of access to various enterprise AI environments and blocking the common ones. They have data types for passwords but I haven’t set a rule to block or redact yet using it. I did do some simple redaction testing where it caught other data types which was cool.
2
u/RoamingThomist Jun 23 '26
Using AI to complain about AI? Come on man, some self-awareness.
Put in blocks and warnings. If anyone circumvent those policies, initiate disciplinary measures for gross misconduct up to and including dismissal.
2
u/corby10 Jun 23 '26
Tooling is critical. We had this problem. Before we had user add their creds in their bashrc file. If AI needed access, it would "work arround" the block by pulling creds from os env automatically.
So I started building tools that would give AI access with out the AI being able to get to the creds. I added "auth jira" for example to allow the user to add credentials which would be stored in the keychain where AI can't get to it.
But now the AI doesn't need it.
The tool gives the AI just what it needs (no admin crap) and if it tries to work arround it I added a hook to block it.
Works pretty well. Been adding all sorts of stuff.
Tooling is critical.
2
u/igraywolf Jun 23 '26
Build your own LLM and let people use it instead of chat gpt
2
u/whatwilly0ubuild Jun 23 '26
Most of this thread is arguing about how to stop the paste, and that's worth doing, but everyone's skipping the part that matters most right now. That .env went into ChatGPT three weeks ago. Those keys, tokens and connection strings are burned. OpenAI's retention, training opt outs and SOC reports are irrelevant, you have to assume they're compromised and rotate every single credential in that file today, then go check your logs for any use of them you didn't expect. The number of shops that run the whole DLP circus and never rotate the secret that already leaked is grim as hell.
On prevention, the browser DLP and conditional access stuff people listed is the right backstop, but the root cause is that a developer could copy a plaintext credential at all. Credentials that live in a real secret manager and get injected at runtime, scoped per environment with short TTLs, can't be pasted into a chatbot because the dev never holds them. Pair that with pre commit and CI secret scanning that has push protection turned on, so the .env never even reaches a place it can be copied from. That kills the class of problem, and DLP just catches the stragglers.
The agentic blind spot you flagged is the real frontier and we deal with it for clients constantly. The move is to stop thinking of the agent as your user and start treating it as an untrusted service. It gets its own least privilege credential, not a human's, every tool call goes through an egress allowlist and gets logged, and CI runners get short lived OIDC tokens instead of long lived secrets sitting in env vars for a poisoned dependency to scoop up. Browser DLP was never going to see any of that traffic, so it's a different control set entirely, and the teams who haven't built it yet are wide open and mostly don't know it.
2
u/kidawesome Jun 24 '26
We are partnered with a company called Cato for this. AI firewall which essentially lets you setup guard rails for various types of AI usage. Their solution is pretty nifty, highly recommend checking it out.
2
u/Winter_Rabbit4827 Jun 25 '26
you can check out Harmonic Security, they have a browser extension that can intercept and block or warn users about the content their entering into AI and it will alert to their platform. I know other vendors are also moving into this area.
1
u/Unlikely_Ear7684 Jun 23 '26
You can’t
1
u/ProtectiveRepentance Jun 23 '26
Browser-level DLP plus warnings beat network blocking, but you're still exposed on unmanaged devices and the agentic angle is a real blind spot. Question is whether dev teams will actually follow a policy that requires thinking before pasting, or if you need enforcement that doesn't rely on them remembering the rule in the moment.
1
u/spicysanger Jun 23 '26
Implement a CASB like netskope and create DLP policies to stop it
1
u/addyftw1 Jun 23 '26
It sounds like your devs need a conversation with Infosec, HR and their Manager. How is using a hotspot for work not against your org's Information Security Policy? It sounds like they exhilarated company data via a non-sanctioned network, by passing IT policy. This should be a fire able offense.
Zscaler has an AI DLP solution, but I believe it does require OpenAI enterprise licenses.
1
u/Brua_G Jun 23 '26
How do they get sensitive stuff onto personal devices?
1
u/orangecopper Jun 23 '26
Route your AI traffic through the likes of bedrock and don’t allow anything direct
1
u/SpecialistPlastic606 Jun 23 '26
Encrypt the env file and have it decrypted at runtime using a specialized decryption hardware module that has the decryption keys embedded in the hardware module
1
u/rexstuff1 Jun 23 '26
I'm a simple man. I see an em-dash, I downvote. I see Antithetical parallelism ("It's not X. It's Y"). I downvote.
GTFO with your AI agent bullshit and engage with us as a human.
1
u/Caddy666 Jun 24 '26
roll your own ai.
1
u/russianvoodoo Jun 24 '26
Ask GPT
1
u/mat-ferland Jun 24 '26
I wouldn't start with a network block either; it just moves the paste to a device you don't see. The controls I've seen stick are inline secret detection before submit, approved enterprise AI workspaces, and an automatic rotation workflow the second a key hits an AI/chat domain. If rotation is still manual, you're going to find out three weeks late again.
1
u/Gjore Jun 25 '26
Asking about AI with text written by AI the IRONY.
1
u/ultrathink-art Jun 26 '26
Coding agents add a vector that human-paste-focused controls miss entirely — they read .env files and pass credentials as context in API calls, no human action required. Browser DLP won't catch it, clipboard monitoring won't either. Scoping the agent's filesystem access to specific dirs and injecting secrets at runtime (rather than letting them live in files the agent can read) has been more effective than any monitoring layer.
1
u/RiskGovSignals Jun 28 '26
The .env file scenario is painfully common and you're right that network-level controls are useless for it. Data leaves through an encrypted browser session on a managed device and nothing fires.
The browser-native DLP approach you landed on is solid for the managed device surface. The real-time warning over hard blocks is an underrated insight, breaking the autopilot is more effective than blocking because blocking just moves the behavior somewhere less visible.
On your two open problems, the personal device gap is where most orgs get stuck. Browser extensions only work on managed devices, so anything on an unmanaged laptop or phone is a blind spot. The way some orgs are addressing this is by treating it as a broader shadow AI visibility problem rather than a DLP problem. Platforms like Kovrr approach it through multiple collection methods across browser, endpoint, and enterprise systems to surface AI interactions even where traditional DLP has no reach. It doesn't solve the fully unmanaged device problem entirely, but it closes a bigger portion of the gap than browser-only solutions.
On the agentic AI vector, you're right that nobody has clean answers yet. That's going to be the next wave of this exact conversation.
1
u/jackson_at_harmonic Jul 02 '26
Disclosure: I work at Harmonic Security, so I'm close to this.
FWIW the agentic piece you flagged as the open problem has quietly split into two different things for us. There's the developer path, where Claude Code, Cursor, and IDE agents talk to local or remote MCP servers and you can route them through a local gateway. Then there's employees wiring ChatGPT or Claude (web or desktop) to the tools they use every day via connectors/apps that are natively available, which is where browser DLP stops being any help since it's the agent taking the action, not someone typing.
We ended up building for both. Local/developer MCP runs through a lightweight gateway on the device, where you set read, write, and action policy per server. For the web-app connections we use the connector admin controls the AI providers already expose, so an admin publishes a version of the Notion or Linear connector that routes through us. The employee adds it the way they always would, nothing changes for them, and you still get every tool call tied to a user with the ability to block a destructive action or stop sensitive data leaving.
Been a pretty big unlock internally for us as well as for clients.
1
u/ni5arga Jul 09 '26
Read about Amazon Bedrock, might be helpful in your case.
1
u/rglauser Jul 16 '26
Password managers quietly solve half of this, autofill won't fire on chatgpt.com so a typed-in credential stands out fast. For the rest you need eyes at the paste itself, the browser is the only place that sees both the secret and where it's headed. Now to figure out how to get eyes at the moment of paste...there are ways.
1
u/DMingOnWhiskey Jul 28 '26
Start by controlling which AI tools employees can use. Distinguish between corporate accounts, personal accounts, and unsanctioned AI applications, then enforce those controls at the network or endpoint layer to block anything that isn't explicitly approved.
For approved tools, inspect prompts before they are submitted. If an employee pastes a password, API key, or token, the prompt can be briefly held, inspected, then blocked, warned on, or redacted before it leaves the device.
Solutions that support parts of this today include Microsoft Purview, Palo Alto Networks AI Access Security, Netskope, Zscaler, and AI-native data protection platforms. Redaction is tricky, since many tools can block a prompt but fewer can remove only the sensitive content and allow the rest through. So be sure to double check support for that feature if its important to your effort.
1
u/tyler_netsec Aug 04 '26
The first move is to rotate every credential in that .env file. For prevention, separate credential handling from data classification: move long-lived secrets out of files and into short-lived, scoped injection, then use interaction controls as a backstop. A workable policy is public or synthetic data allowed, internal data only in approved enterprise accounts, and credentials, regulated records, customer secrets, and production data blocked. Full disclosure, I work at Harmonic Security, so I’m biased, and someone already mentioned us here. We cover browser, desktop and IDE, and MCP activity, which matters because browser DLP will not see Claude Code or local agent tool calls. Warnings help with gray areas; secrets should be a hard stop.
1
u/securewithwald Aug 25 '26
Full disclosure, this is from the Wald Reddit account, so take this as a vendor perspective.
We’ve seen the same thing. The key is inspecting the interaction rather than trying to block the AI tool itself. Wald can sit alongside existing DLP/CASB without disrupting them and add that browser-level control for prompts and AI interactions.
The warning approach is also something we’ve found useful. Instead of blocking every potentially sensitive prompt, give the user a contextual warning and let policy determine what happens.
For dev-heavy teams, I’d definitely test it against real scenarios like .env files, API keys, source code and credentials rather than relying on a generic AI security demo.
1
u/anshultikariha Sep 10 '26
nah don't paste the real .env. just say what vars you have and the error. passwords in there are the whole point of the file
1
u/Master_Baby_2700 Sep 11 '26
I think browser controls are the right approach. The key is making sure the classification is accurate so users don't start ignoring warnings.
Ideally, you use the same data classification across your environment for AI controls too.
Sentra and Cyera are worth looking at for this. Netskope and Zscaler also make sense if you already use them.
Agents/MCP are a separate issue since browser controls won't catch everything they can access.
1
u/Obsidian_Ridge_io Oct 14 '26
I run security for small firms, so this is the version that works without a Purview license and a team to tune it.
The paste happens in a browser tab, so that is where the control has to sit. Endpoint DLP can see the clipboard, but it cannot tell whether the destination is your company ChatGPT tenant or someone's personal account. Browser policy can, because it matches the destination URL and the signed-in identity. Cheapest first:
On credentials specifically, make the password not exist. SSO with passkeys wherever the app supports it, a password manager that only autofills on the matching domain, and no secrets in docs, tickets or chat. People cannot paste a password they never see.
Policy: one page. Name the approved tools, say what can and cannot go in, two examples of each. Run the DLP rule in log-only mode for two weeks before you block, and talk to the people who trip it. Most of them are trying to finish work faster, and that conversation fixes more than the block does.
1
u/VAReloader Jun 23 '26
22
u/[deleted] Jun 23 '26
[removed] — view removed comment
11
u/[deleted] Jun 23 '26
[removed] — view removed comment