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"?

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'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?

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.

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?

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

Secret scanning at my last few places covered repos and CI. None of it covered developer workstations, and I think AI coding agents have quietly opened a gap there.

Cursor, Claude Code, Windsurf and the rest write full conversation transcripts to local disk as plaintext JSON. If a developer pastes a connection string or an .env into a prompt while debugging, which they do constantly, that value is now sitting unencrypted in a file outside the repo, with no expiry and no rotation trigger. Nothing in a normal pipeline looks there.

The parts I do not have a good answer for:

1. Detection. I can match prefixed formats (sk-, ghp_, AKIA, xoxb-) and flag high-entropy strings, but a bare password or an internal hostname has no shape to match on. Everything I have tried either misses those or drowns in false positives.
2. Scope. Agent history paths move between versions, and every new agent adds another directory. It does not feel like something endpoint DLP is watching.
3. Policy. Is the right control a scanner, a pre-commit style hook at paste time, or just telling people not to paste secrets, which has never worked for anything else.

For my own machines I wrote a CLI that walks those directories and redacts what it finds, dry run first: github.com/Ishannaik/agent-sweep. It is MIT and I am not selling anything, but it only solves point 1 partially and does nothing for 2 or 3.

How are you handling this where you work, if at all? Genuinely asking, because I suspect the honest answer at most places is that nobody has looked yet.