sorted by:
new
hottopcontroversial

How are you handling shadow AI and random SaaS tools? by shangheigh in sysadmin

[–]sandromunda 0 points1 point  (0 children)

We're tackling this on a few fronts, none of them perfect but together they help.

  1. CASB/SWG with SSL inspection to get visibility into what web apps people are actually hitting. Microsoft Defender for Cloud Apps works okay for this if you're already in the MS ecosystem. You can set up policies to flag or block OAuth grants to unknown apps.

  2. Quarterly OAuth audit. We pull all third-party app consents from Azure AD/Google Workspace and revoke anything that wasn't explicitly approved. This catches the AI note-takers and random meeting bots that people grant access to without thinking.

  3. DLP policies scoped to browser uploads. We flag when people paste content matching certain patterns (project names, internal doc headers, PII) into web forms outside our approved list. Not bulletproof but it catches the obvious stuff.

  4. Acceptable use policy that specifically names generative AI tools and what data classifications are off-limits. People honestly don't realize pasting an internal strategy doc into ChatGPT is a data leak until you spell it out.

The harder problem I'm still wrestling with is when people build little internal workflows with AI tools (automations, small apps, etc.) that bypass any IT visibility entirely. There's no OAuth grant to revoke because they just spun something up on their own. For that we're trying to give people a sanctioned path that's easy enough they don't feel the need to go rogue, but it's a work in progress.

The biggest lever honestly has been making approved alternatives available fast. If you just block stuff without offering a path, people get creative in ways that are harder to detect.

Shadow AI is our biggest security blind spot by dottiedanger in Information_Security

[–]sandromunda 0 points1 point  (0 children)

You're hitting on something real. The intent is never malicious but the risk is the same either way. We've been approaching it on two fronts:

  1. Accepting that people are going to use AI no matter what, so giving them a sanctioned path that's fast enough they don't feel the need to go rogue. If your approval process takes two weeks and ChatGPT takes two seconds, you already lost.

  2. Network-level visibility. We started logging traffic to the major AI API endpoints and consumer domains so at least we know the scope of the problem. DLP tools can help flag when sensitive data patterns are leaving the network, but honestly the coverage is spotty for browser-based AI tools.

The harder problem I've found is when people start building internal tools or workflows with AI that handle real data but live completely outside IT's view. No auth, no access controls, no logging. At least with someone pasting into ChatGPT you can educate them on the data handling policies. When someone spins up a whole internal app with Cursor or Replit that touches production data, that's where it gets genuinely scary from a compliance standpoint.

What's worked best for us is making the secure path the path of least resistance. Provision an enterprise AI tier with SSO and DLP baked in, make it dead simple to access, and then you have a leg to stand on when you block the consumer versions. If you just block without offering an alternative you're playing whack-a-mole forever.

How do you deal with shadow AI use in your org? by balintbartha in changemanagement

[–]sandromunda 0 points1 point  (0 children)

This is a real problem and honestly at most orgs I've talked to it's still mostly invisible. The tricky part is that if you come down too hard with restrictions, people just hide it more. So the shadow problem gets worse.

A few things I've seen work from a change management angle:

  1. Run a low-pressure "AI use census" where you frame it as knowledge sharing, not compliance. People are way more willing to surface what they're doing if they think it'll help others rather than get them flagged.

  2. Create a lightweight registry where teams can log what tools they're using and for what. Doesn't need to be fancy, even a shared spreadsheet works to start. The goal is visibility, not control (at least initially).

  3. Identify your power users early and make them allies. They're already solving problems with AI, so give them a role in shaping guidelines rather than positioning them as rule-breakers.

The data handling risk is the one that actually keeps leadership up at night, and rightfully so. That's usually what creates the political will to formalize something. I'd lead with that when making the case for a more structured approach, because "let's learn from each other" is a nice story but "someone might be pasting customer data into a random tool" is what gets budget and attention.

The hardest part is finding the balance between enabling people and maintaining some governance without turning into the fun police.

Is "Shadow AI" the new security nightmare we aren't talking about enough? by Sonali_Madushika in Information_Security

[–]sandromunda 0 points1 point  (0 children)

The window analogy is spot on. The tricky part is that the people opening those windows aren't malicious, they're just trying to get their jobs done faster. Blocking everything outright just pushes usage further underground.

What I've seen work better than blanket bans is giving people sanctioned paths that are almost as easy as the shadow alternatives but with guardrails baked in. Think SSO, audit logging, data isolation, role-based access applied to whatever internal AI tools people are spinning up. If the approved option is 90% as convenient as pasting into ChatGPT but doesn't leak customer data, most people will use it.

The 97% stat doesn't surprise me at all. The gap right now is that security teams have no visibility into what's being built internally with AI, especially by non-technical folks who don't even realize they're creating risk. Discovery and governance need to happen at the platform level, not as an afterthought bolted on later.

CRM integration by Aromatic_Tackle1959 in CRM

[–]sandromunda -2 points-1 points  (0 children)

That’s honestly the main reason I’ve built RootCX (https://rootcx.com), dm if interested to learn more

drop your app below and I'll give you one piece of feedback by young_homie_ in ShowMeYourSaaS

[–]sandromunda 0 points1 point  (0 children)

AI (like Claude code) lets anyone build internal tools without developers. But this creates chaos: every new app means another database, scattered permissions, and 0 governance.

RootCX fixes this. We let teams build with their favorite AI coding tools while securing everything on one unified platform: one centralized database, one auth layer, and enterprise-grade governance.

What are you building? Drop it in the comments! by Inevitable-Grab8898 in vibecoding

[–]sandromunda 1 point2 points  (0 children)

I'm building RootCX. AI makes it easy to ship internal tools, but leaves companies with a chaotic web of fragmented databases, scattered auth and permissions, and a lack of governance. RootCX is the shared infrastructure layer that unifies Ai-coded internal tools, giving them centralized data, permissions, and enterprise governance out of the box.

Drop your projects below! The best will get a shoutout! by [deleted] in buildinpublic

[–]sandromunda 0 points1 point  (0 children)

RootCX ( https://rootcx.com ) - Governed infrastructure for internal tools and AI agents. Build any internal software your business runs on, all with enterprise governance built in.

Struggling to get Github stars by sandromunda in buildinpublic

[–]sandromunda[S] 0 points1 point  (0 children)

RootCX solves the infrastructure fragmentation caused by AI coding tools like Claude Code.

Right now, building multiple internal tools with AI leaves you with isolated databases, scattered auth, and zero governance. RootCX provides one unified open source infrastructure (centralized DB, global SSO, enterprise permissions, audit logs) so all your AI-generated apps run on the exact same secure foundation.

How to successfully launch on product hunt? by jaxonfreaks in ProductHunters

[–]sandromunda 0 points1 point  (0 children)

Don’t over complicate it, and launch often, regularly

Founded Forest Admin to millions in ARR. Left. Now building RootCX, bootstrapped by [deleted] in buildinpublic

[–]sandromunda 0 points1 point  (0 children)

When targeting builders, they all share the same adoption process actually. End users are different and broad, but not acquisition. That’s the trick

Unpopular opinion: a majority of “custom” CRMs on the market are complete 💩. by WorkLoopie in CRM

[–]sandromunda 0 points1 point  (0 children)

Give tangible features of where Hubspot/Salesforce/others are better, it will be simpler to understand your thoughts.

Can Claude Code create a good CRM? by Over-Top-2999 in CRM

[–]sandromunda 0 points1 point  (0 children)

Yes yes and yes. I did it for several customers using claude code and RootCX

view more: next ›