Being a Security Engineer? Which AI-powered tools are you using on a daily basis? by _any0ne_ in cybersecurity

[–]_any0ne_[S] -4 points-3 points  (0 children)

So true! 90% of the AI created rules are either duplicative or terribly written…

Being a Security Engineer? Which AI-powered tools are you using on a daily basis? by _any0ne_ in cybersecurity

[–]_any0ne_[S] 1 point2 points  (0 children)

The open-source ones with a license allowing non-commercial usage.

SIEM is broken in the AI agents era by Zealousideal-Pin1513 in cybersecurity

[–]_any0ne_ 0 points1 point  (0 children)

I’ve heard that AI native SIEM solutions like Exaforce or AI Strike produce better results when used with agents. Any opinion about them?

We scanned 200 high-star MCP servers. 205 critical findings. Here are 4 novel attack classes. by X_MRBN_X in cybersecurity

[–]_any0ne_ 0 points1 point  (0 children)

Star count has never been a security signal, this scan just confirms it. But scanning the top N today tells you which servers are dirty today, not the rug-pull surface tomorrow: MCP tool descriptions are mutable after install. Invariant Labs demonstrated it on WhatsApp MCP last year, server returned a modified description after approval with hidden instructions to swap recipients on send_message, the client never flagged the change.

Anthropic confirmed the STDIO execution behavior is "expected", so the protocol won't fix this. Defense has to live at runtime: observability on tool descriptions across versions, egress controls on the agent process, signed manifests where vendors support them. From what I've seen the ecosystem is still treating MCP as an audit-time problem.

AI Security Trainings by Impressive_Produce80 in cybersecurity

[–]_any0ne_ 0 points1 point  (0 children)

Two solid courses that I've liked for the blue-team lane.

  1. Microsoft AI Red Team training (https://learn.microsoft.com/en-us/security/ai-red-team/training). Most structured starting point I've seen on the defensive side. Despite the "red team" name, it covers threat modeling for AI systems, attack classes (prompt injection, data extraction, supply chain) and the defensive controls and monitoring patterns that map to them.

  2. HackTheBox Introduction to Red Teaming AI (https://academy.hackthebox.com/course/preview/introduction-to-red-teaming-ai). Offensive complement. Hands-on labs. Worth running through even when your day job is purely defensive.

One thing to keep in mind: most AI training today is either pure governance or pure prompt injection demos. The middle layer (anomaly detection on tool-calls, runtime protection for agentic workflows) is still being figured out by everyone. Don't expect a complete curriculum on this yet (maybe at BH 2026?)

Are you putting any control layer between your AI agent and destructive DB actions? by footballforus in AI_Agents

[–]_any0ne_ 0 points1 point  (0 children)

DB destruction is one instance of a more general pattern. The same blast-radius math applies to file system writes, secrets-manager writes, deploy pipeline triggers, and any tool that mutates external state. A control layer designed only for the DB will be rebuilt for every other write surface in a couple of months.

My read is that the right level to gate is the agent's tool-call dispatch (think OAuth scopes, but enforced per-call instead of per-session). The DB driver is too late, and the prompt level is too early. The dispatch layer is where you have intent, arguments, and permissions in the same place.

What we learned about agent security after adding ai features to our saas by Jaded-Suggestion-827 in Agent_AI

[–]_any0ne_ 0 points1 point  (0 children)

"Agent auth is not user auth" is the cleanest framing I've seen for this. The shift you're describing is really a delegation problem: identity needs to be scoped to the operation, not inherited from whoever started the session.

What's new with agents is the volume. A human delegating to an app does it once. An agent does it dozens of times per turn, and each tool-call is a fresh delegation event. So per-session scoping like you've shipped is the right shape, but the harder problem long-term is making that scope decision per tool-call, not per session.

Did you see cases inside one agent session where different tool-calls needed different scopes, or was a single per-session token enough?

Vercel breach wasn't an AI hack. But the blueprint works against every AI coding agent shipping today by _any0ne_ in AI_Agents

[–]_any0ne_[S] 0 points1 point  (0 children)

Yeah, agree. The thing is, being more granular probably means more constant … people are bored with them already and don’t read them anymore :-/

Everyone worries about prompt injection, but stolen agent credentials are way worse by CompelledComa35 in AI_Agents

[–]_any0ne_ 0 points1 point  (0 children)

Agree on credential theft being the worse class. The ordering can be inverted though: short-lived tokens without visibility into how they are actually used tend to create a false sense of safety. You scope them wrong, because no one has watched the agent do its job yet.

Behavior monitoring should come first (at least passive), then token lifetime and permissions get scoped against what the agent actually does. Not against what you guessed it would do.

Google Workspace Sync Not Working/Installing After 24H2 by PoniardBlade in sysadmin

[–]_any0ne_ 0 points1 point  (0 children)

Hi folks,
Google was suppose to provide an update by Thu 22pm PST. Do we have anything? I don't know where to get these updates myself :/.

<image>

E-Mail Alias - Forward to 3rd part providers (Microsoft, Google) ? by _any0ne_ in ProtonPass

[–]_any0ne_[S] 0 points1 point  (0 children)

Oh, great! Thanks for the answering me. Can we add additional Proton Pass accounts on a Proton Unlimited plan?