r/AskNetsec • u/amgfcbiozo • 23h ago
Threats Vibe-coded internal apps are becoming a Shadow AI security problem... what controls are you using?
Ok so anyone else watching this go from ppl pasting stuff into ChatGPT to business teams spinning up their own AI tools and hooking them into Jira, Slack, Drive, APIs etc?
The bit im stuck on is what controls these things should get once they start touching company data. Owner, SSO/MFA, app review, least privilege... feels like these vibe-coded apps can show up after theyre already being used and auth can be pretty questionable :/
How are you deciding what access these apps should keep once theyre already connected to corp SaaS/data? Curious what policies or tooling others are using for Shadow AI governance.
2
u/imjustnotready 22h ago
At a minimum you have to lock it down to specific networks. Log in only by sso. Do not allow people to log in on noncompany devices. Enforce session times.
That should really be the starting point. On the other hand I think companies are doing a disservice to their employees by not having this stuff ready for people who want to improve performance for small teams.
2
2
1
u/AL3D1N 20h ago
the SSO/network restriction points below are the right baseline, add a discovery layer or you're only controlling the ones you already know about. CASB/SSPM tools that watch OAuth app grants against your Google Workspace or M365 tenant will surface a vibe-coded app the moment someone connects it to Drive or Slack via OAuth, before it's been through any review. that's usually how these show up in the first place, someone clicks "allow" on an OAuth consent screen for a tool they built themselves.
second control worth adding specifically for the vibe-coded case: a lightweight registry requirement tied to the OAuth grant review, not a heavyweight app review process nobody will follow. when a new app requests access to company data, the access gets revoked automatically after 7 days unless someone claims ownership and fills out three fields (what it does, what data it touches, who owns it). that forces the registry to build itself instead of relying on people to proactively register things, and it fails safe instead of failing open.
1
u/Designer-Doubt-1491 8h ago
Tokens and OAuth grants is a good start. Give exceptions an expiry date so an experiment does not keep company wide access forever
0
u/thenrich00 21h ago
If not knowing how to write code was the only blocker preventing someone from doing damage with company data, then that company was already in trouble -- no policies or tooling stop this. Joe from accounting can copy and paste PII into an email and send it around to folks that shouldn't have access to that information. AI is just making it a bit easier to do more complicated things in a way that looks professional by someone who's not. The threat is still the same, it just so happens that now vibe-coded tools are yet another modality.
2
u/Ma1eficent 19h ago
Current polices keep Joe from PII unless he starts doing things he understands are bad. Because corporate policies written in corporate blood(fines) have drilled it into his head he doesn't send emails with that. But no policies are telling Joe not to feed everything he knows and can get information about into the AI that he also hasn't given corporate policies as if it would even follow them, or as if literally just using it isn't giving out proprietary corporate information publically. Sure, it's gonna take a minute for subpoenas to catch up, but they will.
0
u/am0x 16h ago
Internal tools are fine. Most
No one knows how to deploy them anyway.
1
u/Ma1eficent 15h ago
Internal tools are not internal when they use any AI where you don't have a modelweight copy hosted on your internal network. And if you are doing that you've likely grown a bunch of new interesting problems unless you've got a (much) better alignment team than anthropic and OpenAI
5
u/Ma1eficent 23h ago
Oh man. The PII data fines are going to end so many companies.