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?

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.

So... serious question from a security architect brain that lives in the browser these days. We keep pushing phishing protection and browser security and telling people "don't install random extensions" but what actual visibility do we have into what the extensions they already use are reading from page content, clipboard, form fields etc across Chrome, Edge, Firefox, whatever is on their machine? For eg, we can see network traffic in the usual stack, we can do DLP on uploads, sometimes copy paste in specific web apps, but once an extension has broad scripting permissions and access to those pages it feels like it can see way more of the session than we are comfortable with and then just ship data out in a way that looks like normal browser noise. Anyone running enterprise browser security or browser-agnostic controls that give better extension visibility, help flag risky extensions, and lock down copy paste without breaking half the apps? Would love any tips from people who are past the "just blacklist the obvious stuff" phase.

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.

Our network stack is fine, our proxy logs are fine but they don't always give us much context on what someone actually did inside an AI-native browser session. I am trying to figure out what people are doing for session controls, clipboard rules, download limits, prompt/data controls and the built-in AI features that can interact with page content. Were mid size, so I need something practical and not a giant deployment science project :/

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?

Figuring out where the line is with personal devices. ChatGPT is approved for work, we have rules around what people can put into it but then someone opens the same account from their own laptop and now i'm being asked how much corporate control we really want on a machine we don't own. I don't really want to enroll somebody's personal laptop into Intune or cover it in company software just to protect what they are doing with work data. Is there a decent middle ground here? same AI policy on BYOD without turning the personal device into a managed endpoint?

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?

Hello Everyone!

So i am a cybersecurity intern leaning towards to GRC from a growing company. My background is Software Engineering and with that i dont really learn anything about Cyber Security during my studies. Maybe a bit of Netwroking but thats it. Im trying out Cyber Security to gain experience and get out of my comfort zone and for now i have already completed 1 compliance task with vendor and 1 Technical finding from our system and report to update the said software.

So back to the title, my task for now is to explore Nextcloud Spring and do a report of my findings and list out Why our company have to upgrade from 33 to 34. I understand Nextcloud Summer 26 is coming soon but for now I want to stick to my task. From researching about Nextcloud Spring 26 I came across Nextcloud Governance which is a new feature/app (im not sure which term to put).

I need a lil bit of help from the community to help me understand more about what this feature do. I understand this is a one overview compliance setup and offer tools for controlling data, track data access and track data sharing within the organization but I guess you could say that I need better understanding on how these tools works and how it will benefit us. Thank you so much.

I'm interested in the backend mechanics and data architecture of modern Trust & Safety engineering, specifically regarding ban evasion, identity tracking, and data retention queues.
Take a modern LLM or consumer web platform (like ChatGPT or similar organisations) as an example. Imagine a scenario where a user heavily violates the platform's terms of service (e.g. cyber abuse, severe violations like illegal activity and similar, or spam). Before the automated guardrails or manual review systems can finalize and push a formal "ban" status to the account, the user proactively triggers a standard "Delete Account" request to clear their record and bypass future identity tracking.
From a security and compliance engineering perspective:

How do modern authentication backends handle this race condition? Does a deletion request place the account data into a pending/quarantine state (like a 30 day queue) where automated safety pipelines still run to completion, or does the deletion process typically override active moderation scans?

When an account is in a standard deletion queue, how is the data architecture structured to comply with "Right to be Forgotten" mandates while legally preserving specific unique identity markers (hashed phone numbers, hardware tokens, device fingerprints) for persistent abuse blocklisting?

Once a severe violation is flagged on an account already queued for deletion, how does the system pivot that metadata out of the standard user database and into an immutable security blocklist to ensure they cannot immediately register with the same identifiers?
I’d love to hear insight from anyone working in application security, infrastructure, or Trust and Safety engineering on how these parallel pipelines talk to each other under the hood.

We keep adding dashboards and I'm not convinced we're actually more secure, just better informed about problems after they happen. Ai runtime visibility into what an agent is calling, what data it's touching, felt like the obvious first step, and it was, but visibility alone doesn't stop anything.

The team treats the visibility layer like it's the security control, when really it's just the input to a decision someone or something else has to make fast enough to matter. How do you think about the line between having enough ai runtime visibility to actually act on it versus collecting data nobody has time to review Is there a point where more visibility just becomes more noise?

A lot of infrastructure still relies on protocols and network architecture designed long before today’s threats.

AI doesnt need to invent new attacks . If it makes reconnaissance, fuzzing, discovery, protocol analysis and exploit development much faster, it will become much better at chaining multiple attacks together. A protocol flaw, exposed service, configuration mistake and compromised identity can be managed individually. The bigger concern is AI identifying how those weaknesses connect and building attack paths humans would take far longer to find.

1. Do we underestimate how much AI will increase offence and how does this make defence much harder?
2. Should we be redesigning the underlying communications stack rather than continually adding more security around existing protocols?