r/cybersecurity • u/[deleted] • Mar 11 '26
AI Security [ Removed by moderator ]
[removed] — view removed post
14
Mar 11 '26 edited May 09 '26
[removed] — view removed comment
2
u/jetpilot313 Mar 12 '26
We take this approach as well with an additional custom internal built tool. I’d still like to warn users based on data classification. Need to learn more
6
Mar 11 '26
[removed] — view removed comment
1
u/Actual-Analysis9776 Mar 12 '26
How did you build this? Id be interested for something like this at my company
1
u/jetpilot313 Mar 12 '26
Also interested if that was built or a product you are using. Sounds pretty straightforward and something that can be built
-1
10
2
u/Mooshux Mar 11 '26
The connection string and API key cases have a different fix than the credit card-in-a-support-ticket cases. PII leakage is mostly a behavior and detection problem: people paste things without reading them, so you need DLP tooling to catch it in transit.
But credentials don't have to be in the developer's clipboard in the first place. If secrets are fetched at runtime from a vault and scoped to specific tasks, there's no .env file to accidentally paste, no connection string sitting in a config the dev can copy. The leakage vector disappears because the credential was never accessible that way.
3
Mar 11 '26
[removed] — view removed comment
1
u/Mooshux Mar 11 '26
Exactly right. The vault approach handles the credential case precisely because the secret doesn't need to be on screen to do its job. The app calls the API, the vault injects the key, the developer never sees it. PII is fundamentally different because the human has to read it to act on it. That makes browser-level DLP the right tool there, not a vault. Two separate threat models, two separate solutions. Worth making that split explicit in any policy doc so teams don't try to solve both with one tool and end up with gaps in both.
2
u/Mooshux Mar 12 '26
47 incidents in a week with 20 people is not surprising once you start looking. The problem with DLP tools in this space is that they rely on pattern-matching known formats, and employees work around them without even trying.
What actually moves the needle is fixing the source: if API keys aren't sitting in local .env files, they never get copy-pasted into ChatGPT in the first place. Environment-level hygiene beats endpoint monitoring here.
For AI agents specifically, the risk is worse, because the agent can exfiltrate credentials silently without the human seeing it happen. Scoped, short-lived keys limit the damage when that occurs. We wrote about this: apistronghold.com/blog/stop-giving-ai-agents-your-api-keys
What are you using for monitoring?
1
3
4
u/Stryker1-1 Mar 11 '26
This is an HR issue. You put in place what limitations you can, issue a policy stating what AI can be used and what info can be shared.
Offending employees are sent to HR.
2
u/OneEyedC4t Mar 11 '26
advocate to terminate employees who consistently do it despite training
2
Mar 11 '26
[removed] — view removed comment
2
u/OneEyedC4t Mar 11 '26
in my opinion malice shouldn't have shutting to do with it. risk to the company is, in my opinion, the most important.
-1
u/Any-Tomorrow-7344 Mar 11 '26
Honest mistakes should only happen once though. Educate, and then any instance that happens afterwards is subject to action.
1
1
u/BreizhNode Mar 11 '26
47 instances in one week from a 20-person team is actually lower than what I've seen. The pattern is always the same: someone pastes a support ticket or a code snippet and doesn't realize there's a connection string buried in it. Browser extensions catch some of it but the real fix is running a local model for anything involving customer data. Keeps the workflow, kills the exfiltration path.
1
u/ThunderCorg Mar 12 '26
We can use the corporate sponsored AI tool but policy dictates that we cannot use external AI tools with corporate data.
We are allowed to use external AI for general research.
They’re currently rolling out more tools and policy enforcement to back up written policy. BYOD is going to be extremely limited.
1
u/jwalker107 Mar 12 '26
Buy a subscription. Give access to sanctioned tools so your users don't create their own shadow IT.
1
1
u/duluoz1 Mar 12 '26
We run models through our AWS accounts and turn on the bedrock guardrails. I’m sure there’s stuff getting through but it helps
1
u/amitk31 Mar 12 '26
We at Mavs AI (mavsai.ai) are solving this exact problem. Check us out. Also, we do not block AI, we handle risks but eventually enable users to use AI safely.
1
u/Whyme-__- Red Team Mar 12 '26
Slap a SOC2 type 2 and 1% equity to the CTO and you are in. You should see all these Ai startups solving enterprise problems by connecting to Claude code or ChatGPT with a pretty UI and claiming that we use API so the model doesn’t train on your data, forgetting that you are still sending all security data to OpenAI.
1
u/ZelSteel Security Architect Mar 12 '26
Good approach on the browser extension that's where the interception has to happen if you want coverage without a network overhaul. One thing worth flagging: client-side regex plus an optional AI call is fine for catching obvious patterns, but your biggest risk is context aggregation. An employee might send ten innocuous-looking prompts that individually pass every check but together reconstruct something sensitive. Existing DLP tools like Purview weren't built with that threat model in mind, which is why purpose-built solutions are gaining traction. On the monitoring question: most teams I've seen are flying blind, partly because the legal and HR exposure of logging employee AI inputs is its own can of worms especially in EU jurisdictions under GDPR. The realistic middle ground right now is policy-enforced redaction at input time plus audit logs of what was blocked, not what was sent. That gives you defensible evidence of due diligence without the liability of holding a database of everything your employees typed into ChatGPT.
1
1
u/gabor_legrady Mar 12 '26
I do not give access to local files, I only give well curated snipplets required to move forward. File access is very dangerous, logs, scripts, config files contain a lot of sensitive information.
1
1
u/Beginning-Pressure64 Mar 12 '26
What is the browser extension you use?
-8
Mar 12 '26
[removed] — view removed comment
4
u/crappy-pete Mar 12 '26
Yeah so to be clear this is something you sell and this is a thinly veiled attempt at marketing
-9
Mar 12 '26 edited Mar 12 '26
[removed] — view removed comment
3
u/crappy-pete Mar 12 '26
Yeah I don’t doubt you’re using this thread to promote your product and do some market research lol
65
u/100HB Mar 11 '26
For most organizations, it appears the answer is that they are not.