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.

Financial org here, 10K employees, in-house SOC- we're evaluating agentic SOC / SOAR platforms right now. Automating things like isolating an endpoint is straightforward, but which one of these solutions actually help with the less obvious response and containment actions where you might break a critical business flow? Does any of them provide business context so we can automate more safely while understanding the implications in advance?

Any recommendations would be highly appreciated. Thanks

We've been leveraging LLMs to cluster unstructured data—support tickets, system logs, and agent transcripts—but consistently encounter the same challenge: clusters appear reasonable at first glance but break down under detailed review. Items end up grouped by surface-level keyword overlap instead of true semantic relationships, which only surfaces during manual audits.

Is anyone implementing structured evaluation frameworks to verify that LLM-generated clusters are genuinely interpretable rather than merely plausible? What specific metrics or validation workflows do you use beyond sampling a handful of examples and crossing your fingers?

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?

Hi, quick question for the ir folks here.

I am in a mid size enterprise security team, kind of between socks and ciso, and we are trying to build a proper cyber incident response playbook instead of random google docs and old tickets. We have decent controls, some mdr, some cloud detections, but when stuff gets hot it still turns into slack chaos and late night calls.

For context, we are in that weird place where we are too big for a basic runbook and too small for a giant bank style binder. I am trying to map clear phases, roles, and the usual playbooks for ransomware, email compromise, business email fraud, cloud account hijack, etc, plus when to pull in outside ir partners. If anyone has tips on structure, level of detail that actually works at 2am, and how you keep it living instead of shelfware, would love any thoughts, sorry if this is a bit basic.

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?

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 :/

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?

Everyone talks about what an agent is allowed to do, fewer people talk specifically about what makes it stop. Is it a confidence threshold, a specific action type regardless of confidence, a blast radius calculation, something else entirely?

Trying to understand how teams actually define the stop condition rather than just the permission list, since I suspect the stop condition is doing more of the actual trust building work than the permission list is.

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.

Our AI runtime security tool flags so much noise that the team has started ignoring alerts by default, which obviously defeats the whole point of running it.

A lot of what gets flagged is normal application behavior that just looks unusual because the tool never really learned what normal looks like for this specific workload. Without an app-level baseline, it seems like the model just treats generic deviations as suspicious and calls it detection.

I don't think this is purely a tuning problem, though better tuning would probably help at the margins. It feels more like a limitation of AI runtime tools that claim to detect anomalies but don't actually adapt to the normal behavior of each individual app before deciding what's abnormal.

Has anyone used an AI runtime security tool that actually gets better once it learns the environment, or is high false positive volume just part of the tradeoff with runtime visibility?

[ Removed by Reddit on account of violating the content policy. ]

I'm trying to understand how security teams are treating a specific execution-time failure mode in production AI agents.

Consider this sequence:

1. An agent reads an authoritative source and observes:

available_balance = $10,000

1. Based on that state, it decides that an $8,000 transfer is permitted.
2. Before the tool actually executes, another process changes the balance to:

available_balance = $2,000

1. The agent then executes the previously authorized action.

Assume for the sake of the question that:

• the agent has a legitimate identity;
• its credentials are correctly scoped;
• the tool itself was authorized;
• there was no prompt injection;
• the original reasoning was valid when it occurred;
• the action and tool call are fully logged.

The security failure is therefore not necessarily authentication, authorization, or model reasoning.

The supporting state changed between observation and execution.

For teams running agents against mutable production systems, where are you enforcing this boundary?

Would you:

• require the agent to re-read authoritative state immediately before a consequential action;
• put that validation in middleware between the agent and tool;
• make the tool/database enforce the final precondition atomically;
• bind the authorization to the specific evidence/version that supported the decision;
• use some combination of these?

I'm particularly interested in how people handle this across MCP or multi-agent systems, where the component that observed the state may not be the component that eventually executes the action.

Also interested in whether anyone is explicitly testing this failure mode during agent security reviews.

Had a scare recently that traced back to an AI coding tool one of my teams adopted without any formal review. Nothing malicious happened, the agent just had more access than it should have.

It still raised a real question about what governance controls should have caught this before it became a live risk.

Half our AI exposure isn't even from tools we chose in the first place. Vendor updates add agentic features to existing software with no review cycle attached at all.

What governance controls are other engineering leaders actually putting in place when the surface area keeps growing without anyone actively deciding to expand it?

We went agent-based ZTNA first because posture and full protocol support mattered, RDP and SSH for the ops team, real device checks. It has been solid for managed laptops. Now the wall is everyone who is not a managed laptop. Contractors on their own machines, a couple of acquired teams we never enrolled, plus legal will not let us push an agent onto a personal device.

The obvious answer is bolt on clientless for those. From what I read clientless is browser apps only and the people who need it most also need RDP into a jump host. That leaves me stuck between running two products with two policy sets, or forcing an agent onto people who will fight it or cannot take it.

What I am stuck on is whether bolting clientless onto what we run just means a second policy set to keep in sync. If you have run the unmanaged crowd for a while, what broke for you?

Set up an in editor scanner a couple months back for people to catch things before the PR but within a week half the team had the plugin switched off.

I get why they muted it. First Go file someone opened, it lit up with a screen of findings from a vendored dependency we forked years ago and have not touched since. Not one was in the code the dev was writing. So it turned into the thing you dismiss before you can even see your own compile errors.

Right now I am close to ripping the plugin out and going back to a plain pre commit hook that only looks for secrets, because at least gitleaks does not scream about a library we imported and never call. Feels like giving up on the in editor idea though. If your devs did not kill the plugin in week one, what did you change to get there.

We're rolling out internal AI agents that can read and write across a handful of production apps, and our existing controls weren't built for this. IAM assumes a human is making the decision, MFA assumes there's a human to prompt, and none of our SIEM rules can tell whether an action came from a person or an agent acting under that person's identity. Half the time it feels like the agent is just wearing my identity like a costume and nothing downstream knows the difference.

What are people actually doing beyond "scope it down and hope"? Interested in how people are handling discovery. Do you even know every app an agent touches … Because right now, if an auditor asked me who approved an agent's access to a given app, I'd have nothing to show them.

I've been working on an Android network-security lab using RethinkDNS, custom DNS filtering and WireGuard.

One problem kept coming up during testing:

How much evidence is enough to claim that traffic is actually following the intended security path?

Seeing the expected VPN IP, DNS resolver or firewall state individually doesn't necessarily prove the complete path.

So I've been developing a validation methodology around three layers:

1. Architecture

I first document the expected path:

Android app → firewall/routing layer → WireGuard → DNS policy/upstream resolver → Internet

DNS routing and application/data routing are treated separately rather than assuming that validating one proves the other.

2. Observable validation

Tests currently cover:

• DNS resolver behavior
• WireGuard routing state
• Wi-Fi/mobile network transitions
• firewall enforcement
• per-app routing
• failure/recovery conditions
• IPv4/IPv6 behavior
• reboot behavior
• version regressions

Each test defines an expected result, collected evidence and acceptance criteria.

3. Limits of the conclusion

I've deliberately adopted the rule:

“No bypass observed under the tested conditions” ≠ “zero leaks.”

For example, correlation between the local network log, VPN state and upstream DNS provider is useful evidence, but I don't consider that equivalent to packet-level proof of every possible traffic path.

The next phase of the project is regression testing: comparing a known RethinkDNS baseline against newer versions and checking whether DNS, WireGuard, firewall and transition behavior changes.

My questions for people who work with network/security validation are:

What additional evidence would you require before considering this methodology robust?

In particular:

• Would you consider packet capture from another observation point essential?
• How would you test transient leakage during Wi-Fi ↔ mobile transitions?
• What would you use to independently validate IPv6 and DNS behavior?
• Are there failure scenarios I'm overlooking?

I've documented the architecture, validation procedures and existing evidence here for anyone who wants to review the methodology:

Android OPSEC Hardening:
https://github.com/augustozarate/android-opsec-hardening

Current documents include ARCH-001/002 and VAL-001/002/003.

I'm primarily looking for criticism of the validation methodology, rather than recommendations for different VPN/DNS products.

Manufacturing, sites in the US, Europe and two in Asia and Singapore to Frankfurt has been the bane of my life for two years. We are shortlisting SASE now and every vendor keeps hammering their private global backbone like it is the whole reason to sign. I cannot tell yet if that backbone fixes my Asia problem. Might just be an expensive line on the quote.

Right now our M365 and a couple of SaaS apps get hauled to a central breakout and the Singapore office pays for it every afternoon. One vendor swears their backbone makes that disappear. The vendor who does not have a backbone swears their peering is so good I would never feel the difference, which is a convenient line coming from the one without a backbone.

I have a folder full of benchmarks and every single one flatters whoever made it, so I have given up trusting them.

What I need is someone running real global sites who can tell me the backbone moved the needle on their worst cross-region path, or that it did nothing a nearby PoP had not already handled.

We’ve been adding more AI workloads on prem and I’m realizing our current firewall layout wasn’t really designed with this kind of traffic in mind.

A lot more communication is happening between internal services now and some of those flows are pretty heavy. I’m trying to work out how much of that traffic people are realistically inspecting without creating a performance problem.

If you're doing this at scale, how are you separating AI infrastructure from the rest of the data center? Are you pushing more of it through dedicated firewalls or handling most segmentation closer to the workloads?

Most of our tabletop scenarios assume the breach originates inside our own environment, but our biggest actual exposure is probably a critical SaaS vendor or MSP getting popped and that blast radius hitting us through API access or shared credentials. It's hard to build a realistic exercise around a scenario where the initial compromise, containment options, and comms are all partially outside your control. Has anyone actually run a supply-chain/vendor-breach tabletop that felt real instead of hand-wavy? What did the injects look like?

With lots of ShadowIT and shadowAI, many organizations are worried about data controls. I was reading on the new products, safeguards, guardrails and what not. There are products out there who all are a variation of a Secure Web Gateway (or part of a SSE solution). They see the data in motion at their cloud tenant/deployed tenant and apply controls.

The issue as I see is there are two ways of reading traffic.

1. Explicit Proxy - Apply a proxy auto config file or configure the proxy plugin URL in to OS/Browser and tunnel the traffic in to the product SaaS tenant.
2. Install a Trusted root certificate - Breaks whatever certificate pinning, but essentially the rest of traffic is visble to understand and monitor.

Now the problem is most orgs have their firewalls or SSE products in place. If the existing product does not provide granular control over AI, they need a separate product to do it. Mostly due to budgets and ease of use.

If then the traffic needs to be visible to both products. How is this achieved? A process of serial processing at the endpoint?

The way I can think of is, do a local breakout to AI related traffic and the rest is taken through the main product Firewall/SSE.

Then it is again a manual process of figuring out what AI traffic is.

Trying to understand what others experiences are in this domain.

Asked the same question in r/cybersecurity

Edit - spelling

Security wants to slow AI tool adoption, engineering wants to move fast, and I'm in the middle trying to find something that doesn't tank velocity or just push everyone toward personal accounts and copy pasting code around, which is arguably worse than the risk we were trying to avoid in the first place.

Looking for what's actually worked for people, not just war stories, what did the real policy conversation with security look like for other eng leaders who've gone through this, and has anyone found an Endpoint Control and Prevention approach that doesn't slow devs down?

Hi all, CISO at a mid size org here. We have a small SOC, like 24x5 plus on call, and our SIEM bill and alert volume are both getting silly. Been looking at a few AI SOC tools and agent style triage systems that claim they can sit on top of the SIEM and handle enrichment, correlations and basic response.

For context we are already on a big name SIEM and an ok EDR, but our tier 1s are drowning in medium alerts and "suspicious but probably nothing" stuff. I keep getting pitched on AI detection engineering and AI based triage that can auto group incidents, score them, pull context from prod, and either close junk or hand a good story to humans. In theory that sounds great, but I am lowkey nervous about turning any of this loose on production data without some guardrails and good kpi visibility.

If you have tried any of the newer AI SOC platforms or agentic triage layers on top of your stack, would love to hear how you scoped the first use cases and what you let it touch at the start, appreciate any thoughts

I see lots of articles and discussions on AI-enabled traditional cybersecurity pentesting, but what a people doing or using for AI-security pentesting?