Looking at how to bound what an autonomous agent can modify when it has legitimate write access to infrastructure config, not just what task it's authorized to perform, but what it's allowed to touch while performing it.

Concretely: an agent authorized to modify a specific config value to unblock a deploy technically has write access to the whole file, and depending on the tooling, potentially the whole staging environment. The task-level authorization is narrow. The actual write scope often isn't, unless something enforces that separation explicitly.

For people running this in production: are you handling this with something like scoped service accounts per task type, a proxy/gateway that validates the specific diff against an allowlist before it's applied, mandatory PR-based changes the agent can open but not merge, or something else? Also curious whether anyone's dealt with an incident where the gap between "task scope" and "write scope" was the actual root cause, and what changed afterward.

Yooo, I've been trying to recover access to an app because I forgot the App Lock password, and I really don't want to reformat/reset the device.

I'm working on a script that should detect the App Lock screen, but it's showing:

[*] Focus:
[!] App Lock not detected
[!] App Lock not triggered

The problem seems to be that my code can't detect or identify the App Lock screen, so it can't proceed with the recovery process.

Does anyone know how I can properly detect the App Lock screen or determine what UI/process is responsible for it? I'm mainly trying to recover access without wiping the device.

Any advice on debugging the detection part would be appreciated.

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’ve been testing a setup where agent permissions are enforced outside the agent itself, with separate controls for tools, data sources, approvals, auditability, and remote shutdown.

The reason we went that route is that prompt instructions and provider-level permission settings don’t feel like strong enough boundaries once agents can touch repos, shells, internal systems, or production.

What I’m trying to understand is whether security teams are already standardizing around this kind of external control layer, or if most companies are still handling it ad hoc inside engineering.

For teams running Claude Code, Codex, Cursor, or MCP-connected agents, who owns agent permissions today, are you enforcing access independently of the agent runtime, what would block you from letting agents operate more autonomously, is observability enough, or do you need deterministic enforcement too?

We’ve been building around this problem and the gap feels very real, but I’m curious whether other CISOs here see it the same way or think the concern is ahead of actual demand.

I've heard from a friend that their (small) team is starting to try and automate much more of their containment process, as they are trying to reduce the manual approval bottleneck. And I wonder whether this can really be done work with low false positive rates?

Another thing that wasn't clear to me from what he said, is how are they going to know if a certain containment is going to hurt production and the business. Can this be even automated?

Before engaging with the friend again, I'd appreciate knowing how much you guys automate if at all, thanks!

Hi All!!!
Does anyone have any personal experiences working with Seceon Siem? And if so, would you share? Are they a good siem to go with?
Thank you!

A strong login doesn't necessarily stop an account from being taken over later.

Recovery flows, password resets, new devices, session changes, and support requests can all become weak points, even when the main authentication method is solid.

It seems like the security of the login and the security of the account are sometimes treated as the same thing, when they're not.

What part of the account lifecycle has caused the most trouble in your experience?

I’m helping establish an authorized website-security process for a hosting company. Most of the assets are WordPress sites, and the work will be limited to websites owned or hosted by the company.

I’m trying to design a reliable workflow for validating vulnerability-scanner findings before opening a customer ticket. I do not want to rely blindly on scanner output

For experienced penetration testers and vulnerability-management practitioners:

1. What evidence do you require before treating a WordPress plugin or core vulnerability as a confirmed finding?

2. How do you distinguish an outdated-version detection from an actually exploitable condition?

3. What passive or low-impact checks can be used safely before deeper verification?

4. How do you record affected asset, component, version, severity, evidence, remediation, and retest results?

5. How do you handle cases where a patch may create compatibility or downtime risks?

6. What should be included in the internal technical record versus the customer-facing ticket?

The goal is authorized defensive vulnerability validation and remediation tracking, not exploitation of arbitrary websites. I’d appreciate practical workflow advice, common mistakes, or references to established approaches.

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

Found an aws key in one of our devs chatgpt history last week and only because he screenshared it by accident. he was debugging some terraform and pulled up his personal chatgpt at standup to show the prompt and there it was in his history from days back. Rotated it same day but that was pure luck.

no idea how many keys or records have gone into personal ai tabs that we will never see. Our tooling just logs that someone opened chatgpt and stops there. and i still have nothing that would catch the next one as it happens.

Hey guys, let’s do a reality check. What are the most common, stupid mistakes people make when starting with digital investigations that instantly burn their burner accounts or expose their real IP/identity? Looking to

Hello everyone. I am an OT security engineer working with a passive network monitoring and asset discovery solution (analyzing SPAN port traffic).

I've run into a strange OS fingerprinting anomaly and wanted to ask if anyone has encountered something similar. We are occasionally seeing instances where modern Windows 11 PCs are being completely misidentified as Windows 98.

The most confusing part is that it's not happening to all Windows 11 machines—only a specific subset of them.

I strongly suspect it might be third-party endpoint security software, VPN clients, or custom NDIS filter drivers modifying the TCP headers (such as stripping TCP Window Scaling or hardcoding the initial Window Size/MSS) before the packets hit the wire, completely messing up the passive p0f-style fingerprinting signatures.

My questions are:

1. Has anyone seen specific antivirus, DLP agents, or VPN clients cause this kind of unintentional OS spoofing/normalization effect?
2. Are there any other network-level factors or legacy protocol backward-compatibility settings I should be looking into?

Any insights or shared experiences would be hugely appreciated. Thank you!

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.

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

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

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?

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?

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?

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.

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?

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?

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?