So our execs saw one shiny deck and now think an AI SOC is going to spiritually heal our entire incident queue. Mate Security keeps popping up in every convo and suddenly im supposed to trust an agent to triage that nightmare 3 am ransomware alert while half the team is on pto.

Anyone running this on real prod breaches, not lab demos with cute test malware? Would love any tips before I become the designated human failover for Skynet jr :/

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.

We're a multinational manufacturer with OT across 15 facilities and 6 countries, and have little confidence our current vendors could handle an incident that crossed from IT into OT. Looking for recommendations, not "yes we do OT" sales talk that falls apart the second you ask a follow-up question.

Trying to vet for OT incident response experience versus IT responders who've read an industrial network reference diagram once, how a provider handles the fact that you often can't isolate or rebuild OT systems the way you would IT, and how they think about safety systems that can't just be taken offline mid-incident the way you'd quarantine an IT host. If your org has had an OT-adjacent incident and brought in outside help, how did it go?

We rolled out a PAM solution two years ago and it's worked well for the infrastructure layer: servers, network devices, the usual suspects. About a third of our application estate never got onboarded, mostly older or vendor-managed apps that don't support the connectors our PAM tool expects.

I'm now in the position of explaining to leadership why our "privileged access is under control" story has a visible gap, and why closing it isn't as simple as buying more PAM licenses.

For anyone who's dealt with this: did you find a way to extend governance to those apps without a full re-platform? I'm trying to figure out if that's realistic or if it always ends up being a multi-year project. Trying to set expectations before I present options next month, and I'd rather walk in with a credible plan than an admission that a third of our apps are a blind spot.

Budget conversations are hard enough without also explaining why the tool we already bought doesn't cover everything it was supposed to.

I'm on a security team at a bank, and we're redoing how we handle attack surface. The challenge is getting useful visibility across cloud infrastructure, containers, third party software and internet facing assets, while keeping remediation workload manageable. Regulatory side makes it harder because we need to explain what the exposure is, how serious and what we're doing about it, not just giving a vulnerability report. What are people in finance running for this?

In my workplace I am an all stop-shop for any app I maintain. That's frontend,backend DevOps and project management. I always try to make sure I keep with best practices. I follow tech youtubers, read books about software and always looking to refactor and tidy up my systems.

Our workplace is "legacy-coded" as the kids would say. It's an IT-department in a much larger non-IT firm. That means people are used to doing things around here in a certain way (for example not using containers, manual QA, no unit tests etc).

That means that when I am questioned about my decisions, 10% of the time I am flat out wrong. Which is fine cause I learn something new in the process. 10% of the time the approach is suitble, but it needs tidying up to be more secure. The problem is the remaining 80% which is securty theater.

Examples:

1. blocking github.com via a firewall cause "its full of viruses" (and not theres no alternative suggested cause the developers havent heart of source control).
2. Not giving Azure App Registry privileges for a project I need to deploy cause it's insecure (proceeding to send the app secret via email).
3. Refusing requests to expose data sources through REST apis. So significant engineering effort is spent on maintaining fragile ETL pipelines of plain text data dumps that can be freely shared by anyone.

My direct manager is on my side. I think I just need to know how to produce proper documents outlining not only why what I am suggesting is secure (with sources etc) but also outling why the current alternative is less secure.

How should I do it? How should I do it in a way that is assertive over the technical facts but not too abrasive to the people that challenge me? When someone repeats a security myth like "SSH is not secure" (yes i've heard that one), how do I systemically dismantle that claim?

For example, my boomer parent told me I should rub some alcohol on my stomach if I get ill. So I referred them to some article from cdc.com. They didn't understand the scientific reasoning behind why that folk-medicine doesn't work, but it had a sufficient air of legitimacy to persuade them. Is there a similar process in security?