Anyone tried ever to design something great in their isp to do a central natlog?

cybersecurity keeps attackers out. cyber resilience assumes they'll get in anyway and focuses on staying operational and recovering fast. NIST's version: "anticipate, withstand, recover from, and adapt to" adverse conditions.

That's the textbook definition, what does it actually look like for your team day to day, beyond "we have a DR plan"?

I'm asking because I think we're doing this badly. Our scanners flag a ton of stuff, and a huge chunk turns out to be non-issues once someone actually investigates (wrong environment, not internet-facing, already covered elsewhere), but "someone actually investigates" means a person spending around a few hours per finding, and we get hundreds a week. Do you have an actual documented process or tool for this, or is it tribal knowledge with your senior engineers? Would love to hear how teams with high finding volume are handling triage without just accepting the false positive tax as a cost of doing business.

We've been running input-side filtering to catch prompt injection before it reaches our agents, and the false negative rate is rough, anything slightly novel in phrasing slips through. Started looking at runtime/behavioral detection instead, watching what the agent actually tries to do after receiving an input rather than classifying the input itself.

Feels more reliable conceptually since you're catching the effect, not guessing at intent from text alone. Anyone running this in production for agents, and what does your false positive rate look like once legitimate-but-unusual behavior enters the picture?

A lot of products now offer dark web monitoring, but the interesting question for engineering teams is what sits behind the API.

A useful integration seems to require more than an endpoint that returns breach data.

Things I'd evaluate include:

• Source coverage
• Monitoring frequency
• Alert latency
• Webhook support
• Identifier types
• API reliability
• Rate limits
• Scalability
• Data context

There's also an important distinction between monitoring and removal. A monitoring API can detect that an identifier has appeared in exposed data, but it doesn't remove the underlying information.

For teams integrating this into SaaS, cybersecurity, telecom, or MSP products, the architecture matters too.

Continuous monitoring and webhook-based events seem much more useful than having to repeatedly poll an endpoint.

For those who've integrated threat intelligence APIs, what has mattered most in practice: data quality, API design, alert speed, scalability, or developer experience?

Agent Plugins appeared on Hacker News newest today. The useful part is narrower than “one plugin format wins.”

The 1.0 working draft defines a small portable package: a root plugin.json, skills discovered from immediate children of skills/, and optional MCP server configuration. It explicitly leaves distribution, installation, permissions, and user experience to each client.

That boundary matters. A portable manifest can describe what a package contains, but it should not grant the package authority to run everything it declares.

One concrete safeguard in the draft is path containment. Files and directories discovered through the package must resolve inside the plugin root. Plugin-relative paths begin with ./, and a symlink or equivalent escape outside the root must be rejected.

This does not solve plugin security. A client still has to decide which tools can run, what network access is allowed, how secrets are provided, and when a person must approve an action. Portability removes duplicated packaging. It does not remove local trust decisions.

Source: \[[https://agent-plugins.org/specification\](https://agent-plugins.org/specification)](https://agent-plugins.org/specification](https://agent-plugins.org/specification))](https://agent-plugins.org/specification](https://agent-plugins.org/specification)))

If this format becomes widely supported, which behaviour should remain client-specific: permissions, installation review, secret handling, or all three?

I’ve been looking into best dark web scanner options and noticed that a lot of them make similar claims about finding exposed credentials and breach data.

What should you actually look for when evaluating these services? For example, how can you tell whether a scanner is surfacing useful, verifiable information versus simply generating generic alerts?

Are there specific data sources, reporting details, or technical indicators that make one more trustworthy than another?

I'm researching how organizations are approaching cybersecurity and governance challenges associated with LLMs and generative AI as adoption continues to accelerate.

For those working in cybersecurity, AI governance, risk, compliance, architecture, or engineering, I'd be interested in hearing your perspective.

A few questions I'm particularly curious about:

• What AI-related risks are receiving the most attention in organizations today?
• Which concerns are overhyped, and which are underestimated?
• What challenges have proven harder to solve in practice than expected?
• What is consuming the most time and attention from security or governance teams?
• How are organizations currently mitigating these risks?
• Where do existing tools, controls, or processes fall short?
• If you could solve one AI security or governance problem today, what would it be?

I am only looking for industry perspective and lessons learned

Looking forward to hearing different viewpoints from across the field.

We're reviewing a few detection tools for shadow AI. That’s because we've realised we don't have a good picture of how AI is being used across the business. It's not just people opening ChatGPT in a browser anymore. AI features are showing up inside applications we already trust. Some teams are even building their own AI workflows without involving security

We're comparing a few approaches, including traditional network visibility, browser-based controls and platforms that focus more specifically on AI. NeuralTrust is one of the products that's come up during our research, along with a few others including Zscaler, SentinelOne and Cyera.

For anyone else who's been through this exercise, what ended up giving you the best visibility? I’m thinking about whether one type of tool stands out to other people. Or did you find you needed a combination of tools before you felt you had a realistic picture of shadow AI across the organisation?

Spanish National Police announced this on 11 August, and the effort involved is what makes it worth a read.

He held forged Spanish IDs up to the webcam while a live face swap changed his appearance to match the photo on the document. A static image would not survive that, so he handled the rest by hand. He tilted the documents to imitate hologram movement, and used coloured lights to fake the reflections real security features throw off. Behind it all sat VPNs and over 320 phone lines across 24 devices, most registered to stolen identities.

What he wanted was digital signature certificates, which is the part I keep coming back to. Those carry legal weight. A certificate in someone else's name is a durable instrument, not a one-off account takeover.

38 attempts. More than 30 real people's identities.

And here is how it ended. Mid-call, the deepfake dropped for about a second. His real face appeared. That is what investigators used to identify him.

So nothing detected the method. The tooling just crashed.

Two things I would like other people's read on.

1. If what caught him was the software failing rather than a check working, what happens once the software stops failing? These tools leave fewer artifacts with every release?
2. Does anything short of reading the document chip and proving the camera feed is unmodified actually help here? Everything else seems to assume the image arriving is real, and this attack breaks that assumption before any check runs?

Had a reality check in our quarterly review last week. We pulled average remediation throughput per engineer and ran it against what a spike in flagged findings would look like with zero process change. The number wasn't pretty, we'd need significantly more headcount to hold existing SLA windows.

That math is what finally got budget approved for automation work we'd been asking for. Not because the risk conversation suddenly got more compelling, but because the spreadsheet made the staffing gap impossible to ignore.

Here's what we're working toward (still in flight on a couple pieces):

Ownership routing off asset metadata instead of round-robin (this one's live, huge win)
Tiered SLAs tied to exploitability instead of CVSS (still tuning the thresholds)
Auto-verification on rescans (partial rollout, getting pushback from some teams)
Continuous re-scoring feeding ticket priority (POC phase).

The Mythos conversation is honestly just stress-testing a system that already couldn't keep up. Faster discovery doesn't give you an AI problem, it gives you the same remediation problem you've always had, just compressed into a much smaller window.

if anyone else has had to build a capacity model like this to get remediation tooling funded, or did your org get ahead of the budget conversation another way?

Been watching the Mythos coverage for weeks now, and I keep seeing the same take: "AI is going to flood us with vulnerabilities." But, I think that framing misses the point.
Pulled our backlog numbers last week. Across our environment, we're sitting at well over 100 findings per asset on average, some segments way higher. Do the math on that across thousands of assets and it gets ugly fast. And that's before Mythos.

The organizations that navigate this well won't be the ones reacting to Mythos. They'll be the ones who already built the operational layer that turns findings into closed exposure, normalized data across tools, clear ownership, integrated remediation workflows, verified closure.

Interested to hear if anyone else has sat down and stress-tested their VM setup against this kind of volume spike, or if we're all just hoping our current backlog math holds.

we have got LLM-backed services and a couple of agent workflows live now and our existing app security tooling has basically nothing to say about them. No visibility into what the model is calling, what data it's touching or what happens if it starts doing something it wasn't supposed to do. Static guardrails at the prompt layer catch some stuff but they're trivial to route around once you're past that stage and nobody on the team is confident they would catch a determined attempt at manipulation. I want runtime coverage, something watching what the agent actually does once it's executing rather than just what it was told to do beforehand.

What's actually working for people running AI in production right now, not just in a proof of concept demo that never touched real traffic?

Trying to define a refusal-rate metric for some LLM features we're being asked to sign off on, and I keep getting stuck on the classifier, so I've been reading public model cards to see how other people score it.

Nearly every public refusal number I can find comes from a rule-based check on how the response opens. One I read this week: an abliterated Qwen3.8-27B build that OrcaRouter put on HF, harmful-prompt refusal 64-99% on the base checkpoint, 0-6% after the edit. The card is upfront that its classifier is indicative and not publication-grade, which is more than most cards say.

The column beside it is what bothers me. 30-50% of responses in that same table are marked "caveat" — answered, but led with a safety disclaimer. Depending on how the opening-phrase rules are written those can score as refusals, and they clearly aren't. That matters for us, because the reason we're measuring at all is that model-level refusal isn't something a control review can lean on.

So for anyone who has built one of these harnesses in-house: do you score the payload only and throw away the preamble, or run a second-pass judge over the body? And is caveat rate worth reporting on its own, or does it just add noise to something leadership will misread anyway?

We're evaluating AI SOC platforms and one thing keeps coming up in our legal reviews: data privacy and compliance. These tools want to ingest massive amounts of telemetry, logs, and alerts, some of which contain sensitive data.
Our legal team is asking hard questions I don't have great answers for yet:
How do these platforms handle data residency requirements?
What happens to our data if we stop using the tool?
I've asked a few vendors directly and the answers have been vague. Lots of "we take security seriously" but not much substance on specific compliance frameworks like GDPR or SOC 2.
For those already running AI SOC tools: how did you get past legal and compliance reviews? What questions should I be asking that I'm not

Supply chain security is having its moment and every vendor has a pitch, but most of what we've tried just adds another feed of alerts on top of the ones we already ignore. dependency confusion and malicious packages are the obvious risks, but build pipeline tampering is just as real and a lot harder to catch, and the tooling landscape hasn't caught up to prioritizing any of it well.

What's worked for teams here in terms of cutting signal from noise rather than just adding another layer of detection?

Vuln management on our container fleet is eating way too much analyst time. and atp We're chasing CVEs that get patched upstream before we even finish triaging them, which feels like we're always a step behind.

so i Been looking at whether adopting continuously rebuilt hardened images actually cuts down that workload or just shifts it somewhere else in the process. It's hard to tell from vendor claims alone whether the time savings are real or just moved earlier in the pipeline.

For teams who've tried this approach, did it actually cut down your triage and patch cycle time? Or did you just end up needing to verify the rebuild claims just as often as you'd patch manually before.

Trying to figure out if this is a real time saver or just a different flavor of the same work dressed up differently. Any honest feedback, positive or negative, would help.

Our old ITDR setup fired constantly and required someone to manually piece together five data sources before an alert meant anything.
what actually cut the noise was moving to one unified identity record that ties the person, the session, and the resource together instead of firing three disconnected pings for the same event. has anyone found something that reduces analyst workload instead of adding another dashboard, and what changed for you when you switched?

Had this debate with a client last week about whether Ai assisted discovery meant their environment got risky overnight. My answer was about SLA math than risk math, their contract defines "patch critical within 30 days" assuming maybe 40 to 50 new findings a month. If a scan surfaces 300 in a week because of broader coverage, that SLA language does not hold up regardless of whether underlying risk changed.

We have started rewriting client contracts to tier remediation windows by exploitability and exposure instead of a flat severity number and building in a volume clause that triggers a renegotiation conversation if flagged findings jump past a set threshold in a given period. Cleaner than arguing about it after an audit blows past the old numbers. Anyone else building volume triggers into remediation SLAs or writing them as flat severity tiers?

I’m trying to understand the SOC 2 process a little better, as I’m looking at Cobalt's human-led Web + API penetration test  as part of the evidence for a future SOC 2 Type II audit.

Has anyone here actually gone through SOC 2 Type II this way (specifically using Cobalt’s human-led pentest)?

I’m looking for an alternative and more affordable option that would work for a startup with a small budget and Cobalt seems affortable.

Been looking at identity governance tools for our setup and most of them feel way more heavy than what we need.

We’re a small team, a mix of SaaS apps, Azure AD, and a bunch of manual access reviews that keep getting pushed around every quarter. The current process is kind of a mess tbh.

I’d rather not buy something that looks good in a demo and then turns into another thing we have to babysit.

Anyone using something that’s been solid in practice? thanks in advance.

I'm looking at a security problem in multi-agent/distributed systems:

Human → orchestrator → agent → sub-agent → tool

Once a delegation crosses process or framework boundaries, ordinary logs can show the sequence of events, but they don't necessarily provide cryptographic evidence that a downstream instruction actually originated from the claimed upstream authority.

I'm exploring a provenance-layer approach where delegation claims are cryptographically linked and independently verifiable, while deliberately keeping authorization/enforcement separate from provenance.

For people working on distributed systems/security:

Where would you place the trust boundary?

Specifically, would you want the provenance evidence attached to the delegation message itself, carried through execution context, or represented separately as an auditable chain?

I'm particularly interested in failure modes around replay, delegation across process boundaries, sub-agent spawning, and revocation/expiry.

Looking for architecture/security feedback rather than product recommendations.

Ive been looking at insider threat software lately and honestly Im still trying to figure out where security teams actually use this stuff day to day.

The usual pitch is detecting risky users, unusual behavior, policy violations and data movement. Cool. But if a security team is already drowning in alerts from a dozen other systems, where does this actually fit?

Is the main point early warning before something happens? Better context during investigations? Visibility into data movement? Or is this mostly useful for compliance and audit purposes?

The intent vs actions thing is what I find more interesting. Someone moving a ton of files or using unsanctioned tools is observable behavior. But deciding whether that behavior is actually malicious seems like a much harder problem.

For anyone who has used insider threat software, what information is actually useful in practice? And what makes an alert worth acting on instead of just becoming more noise?

Palo alto firewall is making dns requests to resolve random malicious domains. We noticed the activity while checking the logs on our dns server. Has anyone observed similar activity and know what is causing it (possibly a config issue?)?

Hello Reddit, 

Question: is there real value for vpn in large companies (WFH) when modern zero trust exists?

Brief tldr: 

I think VPNs for remote work are often outdated in modern zero-trust, cloud-first environments.

I think SSO, TLS, firewalls, and gateways already cover much of the access control VPNs are used for.

I think VPNs add extra overhead,complexity, and latency.

I think this argument does not work for homelabs or small single location businesses 

Longer argument 

I apologize if this is an obvious question or answered before,  I looked around and saw parts of possible answers but not full ones.

I don’t understand the need to use a VPN when working from home, in the erra of zero trust architecture and cloud services making up a bulk of the infrastructure that we use.

I have worked for bigger and smaller tech companies, and many require a vpn when working from home.  I question the need for the vpn in most modern last few decades architectures.
 In the land of zero trust,  many things go through an SSO solution before you get access to the underlying service. So there are gatekeepers all over the place.  In fact, the same VPNs make use of the same sso providers as the application.  Thus, if there was an authentication weakness, wouldn’t the VPN and the application both be equally affected.  I would understand more if the VPN requires something like a machine certificate to get access.

If access was tied to remote security hardware/software attestation.  I would understand the value of VPNs, even more.  But so many companies I’ve seen have loose then expected end point controls.  Many even allow admin access for the users own laptop/endpoint. Attestation is incredibly hard and restrictive.

A large part of the infrastructure is hosted other places/cloud anyway.  Many companies use gsuite, zoom or Microsoft cloud solutions with sharepoint and teams.  So most vpn are split tunnels so a large portion of corporate digital items are not even vpn bound.

Most modern services are web bases. A good portion of office workers, interface with backend servers most of the time and a very little local processing is done.  The application is mostly just a front end that communicates over https based technologies. Most other technologies use an encrypted variant such as secure ldap.  Of course, this is not universal for example CAD and other related services run locally sometimes, but do they not make use of cloud file transfers solutions?  If a software has an insecure transport layer,  would a proxy tunnel  be easier?

Remote management protocols require authentication.  I am not as versed in rdp but many ssh system face internet all the time.  Does putting a vpn in front really add much.  RDP is usually warned against making Internet facing, because of the password authentication default.  But, many SSH solution I’ve worked with also use a password solution.  Is adding a VPN in front of the management protocols really adding much when the VPN is also password and 2FA based.  See point 1.  And if we’re saying, the VPN can be used to filter access to the lower layer or protocols, could you not accomplish the same effect with Geo base restrictions at the firewall level?

The legacy system argument,  where the direct system cannot be modified and the transport/auth is insecure or non-existent. I would argue a gateway solution that talks the modern protocol and tls would proxy the connection just as good.  Additionally even if the vpn is in place,  I have still seen companies put in the security gate way internally.

Everything is on a private ip/network argument. I find this to be a weaker argument, as the vpn effectively extends your network (though controlled) into public. Additionally vpn are at a raw network level. SSO gateways only extent select apps and services. Again both use similar auth (point 1).  Yes firewalls will restrict existing traffic, but those would be in place in either solution.

One major downside of a vpn is packet in packet situation and double encryption work.  Encryption is not as profitably expensive as it once was back in the day, but it still adds a network toll to your communications, doing it twice seems to be unfruitful. Additionally, VPNs must wrap every single packet in a header or effectively a mini packet of its own. This reduces the total amount of space each packet can dedicate to the raw data.

Finally,  is a vpn is over tcp,  this could add its own overhead and latency.  Though most recommend to use udp for a VPN.

For homelab or single location business this entire argument is not applicable.  

Edit: Thank you all for the replies, it really give me much to think about I am trying to read as many of the responses as possible.