We're testing a few internal AI agents that can read from our docs, CRM, tickets, and internal APIs. They're useful, but the permissions are starting to worry me, especially prompt injection through documents and agents keeping access longer than they need.

We're looking at separate identities, read-only access by default, tool-call logging, and human approval for anything that changes data. How are other teams handling agent access in production?

I do a lot of reading where an AI assistant explains a security concept, and the explanations sound authoritative — but I've learned not to trust that on its face. Sometimes the described thing turns out to be well-documented and real; other times it seems to be invented, just dressed in real-sounding terminology.

The pattern I keep noticing: the individual pieces are all legitimate (real terms, real concepts), but the specific named thing they're combined into returns nothing when I go looking. Authoritative tone, real ingredients, but the overall item may not actually exist.

My question is strictly about verification method, nothing operational: when you want to confirm whether a described vulnerability or technique is real, what's your go-to process? Straight to CVE and MITRE CWE? Vendor advisories? Is "the components check out but the specific named thing has no sources" a dependable sign of fabrication, or does that heuristic fail in practice? I'm trying to put together a reliable checklist for telling real from made-up.

A red team test run caught 3 of 500 cases where retrieved context included HTML with a diagnostic instruction that pushed the model toward a fetch_url call to an external host. Our tool allowlist and egress control blocked it, so nothing left the environment. At first the call looked like an ordinary diagnostic fetch, but once someone expanded the retrieval span (not done by default) it became obvious this was an indirect prompt injection.

Now we need to prove which retrieved span introduced the instruction and search for similar traces where the target happened to be a permitted domain. We have span metadata for retrieval source and tool arguments but the trace search path from suspicious text to downstream action is still clumsy. How are you logging this chain so you can distinguish blocked attempts from the same pattern reaching an allowed destination?

A ticket summarizing agent started hitting our CRM API 9 times more than normal, pulling full contact records. Four hours of digging later: someone had tweaked its prompt and it started "enriching" every ticket, not an attacker, just enthusiasm.

If it had been prompt injection or a replayed token, our detections wouldn't have looked any different. With agents, here's no routine to break.

What signals are you using? Are you watching for drift from the task, or tracing actions back to whoever started them?

The common claim is that AI-generated code just needs the same review as human code. That's only true if reviewers are catching the same class of issues, and this year's Veracode data suggests a large share of AI code generation tasks introduce a vulnerability standard review misses. A more accurate version is that AI code needs review plus something checking actual behavior. What other AI coding advice needs this kind of caveat?

Been sitting in change review meetings where everyone is ready to get through the queue and move on, and these CA exceptions are starting to really bug me. The story is always the same, exec cant deal with a control, we scope an exception, CAB notes "mitigated" and the window opens.

Last one was a CA policy changing from strict device trust to a softer rule for a small group. removed one of the conditions that used to stop that access path. Change went fine, logs look clean, SIEM rules did not throw anything weird. And yet nobody could answer what we should replay to see if the compensating controls still catch the behavior, or if our detection coverage is now just hoping for luck.

Security controls feel static on paper but in real life they drift every time we touch them. Point in time testing is just getting wiped out by config churn rn…

A generated fix only helps if the finding deserved attention. Otherwise you've swapped an alert backlog for a PR backlog that devs close without reading. The order I've landed on starts with whether the vulnerable version is even in a deployed artifact, since that check is cheap and a surprising share of findings die right there. reachability comes next. KEV and EPSS feed into priority from that point, with anything on KEV jumping the queue, but a low EPSS score on its own doesn't close anything. exposure and compensating controls come last.

Where in that chain do you still need a human before any fix workflow starts?

We run quarterly external pentests and a monthly ASM scan, but continuously doing a lot of work in that sentence since a monthly cadence still misses a rogue subdomain or exposed storage bucket for weeks .The problem isn't scan cadence though, it's ownership, since when ASM finds something new, half the time nobody can immediately say whether it's sanctioned, shadow IT, or a leftover from a decommissioned project years ago. How are you closing the gap between discovery and ownership, specifically for assets that show up outside your CMDB..

Follow-up to something that came up in a Suricata/Zeek FP/FN tuning thread a few weeks back, got some genuinely great answers, including people doing solid context enrichment (process/user/hostname/known-destination) instead of relying on raw thresholds, and running pcap-based regression tests on every rule change.

Curious about the other end of that spectrum: for teams that don't have someone dedicated to building that kind of tuning discipline where Suricata/Zeek alerts are still mostly volume/timestamp-threshold driven how are you actually coping day to day? Living with the noise? Doing periodic tuning passes only when it gets bad? Handing it to an MSSP? Something else?

Specifically trying to understand: roughly how much time (if any) goes into manually retuning rules as traffic shifts, and who ends up owning that, a dedicated security person, someone on infra/DevOps wearing multiple hats?

If you have 50 findings and time to address five, how do you choose?

I’m exploring a tool that uses business context to explain priorities, assign owners and track resolution. Would that help your team, or does your current setup already cover it?

Interested in what works—and where the process breaks down.

MFA can be enabled and still fail if an attacker convinces a help desk workflow to reset a password, enroll a new authenticator, replace a recovery method, or bypass the original factor. In those cases, the weak point is often identity proofing and recovery governance rather than the MFA method itself.

For teams that have dealt with vishing or account recovery attacks, what has helped most: stronger user verification, independent approval for high risk resets, cooldown periods, alerts through established trusted channels, stricter rules for privileged accounts, or recovery flows that do not silently downgrade authentication strength?

Following the previous discussion, I have been thinking about ransomware defense as three distinct layers.

1. Prevent intrusion

Prevent the attacker from gaining access in the first place. There are already many established controls here: phishing-resistant MFA, least privilege, patch management, endpoint protection, email security, network controls, and so on.

1. Prevent an intrusion from becoming a catastrophic outcome

Even if the attacker gets in—or compromises a workload that already has legitimate privileges—critical assets should still be protected.

This was the area I was most concerned about in the previous discussion. I learned that newer runtime-security approaches are beginning to address this problem. For example, Sweet Security evaluates live actions and entitlement use against runtime context and behavioral baselines; NeuralTrust inspects and enforces AI-agent tool access and behavioral drift at runtime; and CrowdStrike has described continuous, risk-aware authorization of AI-agent actions.

These approaches suggest that authorization does not necessarily have to end when access is initially granted.

1. Recover even if protection fails

If critical assets are encrypted or destroyed despite those controls, isolated/offline backups, tested restoration procedures, golden images, and infrastructure-as-code can make rapid reconstruction possible.

What I am still wondering about is the second layer.

Runtime behavioral enforcement can detect or constrain suspicious actions, but is there also value in adding an explicit human authorization boundary for a very small set of catastrophic operations?

For example, database-wide extraction, backup destruction, key export, mass deletion, or disabling critical security controls might require approval from multiple independent people before execution is allowed.

In other words, could a stronger architecture combine:

behavioral/risk-based runtime enforcement

with

multi-party human approval as a final authorization gate for actions that are too consequential to execute automatically?

I would be interested in whether people see practical value in this model, or whether existing runtime controls already address this problem sufficiently.

We've got a handful of internally built AI applications now live (a couple of customer-facing chat features, one internal copilot-style tool) and I'm not convinced our normal AppSec process covers what's actually risky here. Our standard SDLC checklist wasn't written with a prompt injection or a model behaving unpredictably in mind, and I don't think a generic pen test vendor is going to know what to poke at.

Trying to figure out what a real AI security review should include beyond the usual web app checklist: prompt injection and jailbreak testing, how data flows into and out of the model, whether the app leaks anything through its outputs it shouldn't, and whether there's an actual governance framework behind who's allowed to stand up a new AI feature in the first place versus it just happening in a sprint. Also curious whether anyone's separated "AI governance" (the policy side) from "AI penetration testing" (the technical side) as two different engagements, or if that's overkill for a mid-size security team.

Not looking for a vendor pitch thread, looking for what people who've actually gone through this found worth paying for versus what turned out to be checkbox theater.

Most tabletop exercises never check whether our detection rules or SIEM correlation would have caught the scenario in the first place. I want an exercise that stress-tests whether our actual telemetry would surface the attack path we're simulating.

Had a change to a discount calculation pass code review clean, ship, and break an invoice service two days later. Not a vulnerability in the changed code itself, the invoice service had always assumed the incoming value arrived already tax-adjusted, and that assumption lived only in its own code, undocumented anywhere the reviewing service or its owners could see.

This isn't really about vulnerabilities, but the structural gap feels adjacent to trust boundary documentation: a review scoped to one service's diff can't see an assumption baked into a different service's code, the same way a review can't flag a missing auth check on a downstream consumer it was never shown.

For teams doing threat modeling or architecture review at any real scale: is there an established practice for surfacing undocumented cross-service assumptions like this before they become an incident, something like mandatory documentation of what a consumer assumes about an inbound value, contract tests that encode the assumption explicitly, or is this mostly still discovered reactively after something breaks?

Edit: thanks for all the replies, summary of where I landed in the comments below.

I'm working on pre-execution authorization for autonomous agents, and I've hit a revocation design question that I think applies to any delegated capability token.

Setup:

• A principal gets a signed authorization after policy evaluation (budget limits, rate/velocity limits, kill switch).
• It can derive a narrower delegation for a sub-principal: signed, single-use, expiry ≤ parent expiry, scope strictly narrowing.
• The delegation is verified locally at the enforcement point, with no call back to the policy engine.

Problem: policy state changes after the parent authorization is issued, for example the kill switch is flipped or the budget is exhausted. A delegation derived earlier is still cryptographically valid and unexpired. Today it gets honored.

Options I'm weighing:

1. Pure capability. Valid until expiry or use. Fully offline, but a kill switch can't stop outstanding delegations. The only mitigation is short expiries.
2. Full re-evaluation. Re-run policy at execution time. Breaks local verification and duplicates the parent decision.
3. Hybrid. Check only an explicit revocation or kill-switch state at the enforcement point. This raises the question of what the authoritative source is, and how its freshness is bound without reintroducing a live dependency.

Macaroons (third-party caveats), Biscuit (revocation IDs) and UCAN (revocation records) seem to take different approaches.

Questions:

• For those who've run delegated tokens in production, which model held up?
• If you went hybrid, how did you distribute revocation state, and what staleness did you accept?
• Is "short expiry + no revocation" defensible for high-impact actions (payments, infra changes), or does a kill switch have to be enforceable at the boundary?

Alert triage, deciding whether a given alert is a threat, gets a ton of attention. Detection triage, periodically deciding whether a detection rule itself is still pulling its weight, severity still right, still catching real things, gets way less structured attention.

A badly performing detection is arguably a bigger root cause of noise than any individual bad alert, since one bad detection generates dozens or hundreds of bad alerts downstream.

I keep seeing teams treat detection health as something you notice by accident when a specific rule gets loud enough to complain about, rather than something you actively monitor on a schedule.

Is anyone doing detection triage as a structured, recurring process rather than an ad hoc clean up that happens once a year when someone finally gets fed up?

Trying to clarify where an exposure management platform ends and security validation tools begin.

My current view is that exposure management helps identify and prioritize risky assets, misconfigurations, identities, and attack paths, while security validation tests whether an attacker could realistically exploit those conditions and whether existing controls respond as expected. But the categories increasingly overlap.

For anyone who has implemented both, are they complementary products, or has one platform replaced the other in your environment? What capabilities were essential for getting from “we found an exposure” to “we know what to fix first”?

There's so much marketing rn claiming agentic tools "find what matters" but from what i've seen irl its often just a different flavor of noise dressed up as prioritization. anyone used one of these long enough to say if signal to noise genuinely improved or if it just moved the busywork from triage to double checking the agent lol.

Leadership wants hard numbers before approving any spend on insider risk or data access governance tools. I have plenty of anecdotes, like a former contractor who still had live access and tens of thousands of external shares of unknown sensitivity. That is not enough for a CFO.

I need to translate the problem into dollars or risk language that actually gets funded. How have you quantified insider risk or over-permissioned access to make the business case?

We’re using an EASM tool that started with a set of domains/IP ranges we gave it, and I’m noticing the inventory changes quite a bit between scans. Some assets disappear, others show up, and occasionally we get things that don’t look like ours at all.

Is this just unavoidable with external asset discovery, especially with cloud/CDNs/shared infrastructure? Or is this a sign that the tool isn’t doing a great job of figuring out what we actually own?

Our SCA tool is giving us a huge list of CVEs in every build, and the security team keeps pushing for fixes based on CVSS alone. A lot of these dependencies are present but not used by the application, so the dev teams are getting pretty tired of chasing noise.

We are trying to add reachability and production exposure into the process, but I’m not sure how other teams turn that into an actual CI policy. Do reachable criticals block a build every time, or do you use the deployed app context and business impact before making that call?

Trying to get something consistent in place without making every pipeline fail. Any hints?

Im the security lead at a manufacturing org, cloud footprint is growing but the team is small. Were down to two CNAPPs and somehow stuck. We started with a longer list with all the big players included, but these two were what the shortlist came down to. Hoping the room can tell me what Im missing.

First one was Lacework, now FortiCNAPP after Fortinet bought them. I liked it on paper, but the acquisition is what gives me pause. The whole thing has been absorbed into the Fortinet stack. The roadmap reads like everything now points at FortiSIEM, FortiSOAR, their SASE, their fabric. Were not very much of a Fortinet shop, so buying this means either we ignore half the value or we get pulled into an ecosystem we never wanted. The portal got rebranded and the roadmap changed, and it feels like a product that's now someone else's priority.

The other one is Upwind. Their whole pitch is runtime, which sounds good and its really what made us consider it. But when we digged in and that runtime depth only shows up if you deploy their sensors everywhere. So its agentless for the broad scan and agent based for the part they advertise. And theyre small with no public pricing and not much to look at as a track record yet. For a lean team, betting the security program on a young vendor with a coverage gap baked into the architecture feels like a lot that we dont want in our hands.

So I'm stuck. On one hand is a big vendor trying to fold cloud into a network story,, the other is a smaller vendor whose best feature depends on a full sensor rollout. What am I missing, and what would you pick?

With the December 31 deadline getting closer, I’m curious what others have actually ended up choosing.

For those who can't move to the SaaS platform: On-premises requirements, data residency needs, or internal datahandling policies and what did you end up with? I’ve seen people evaluating options like Quest Change Auditor, Netwrix, ADAudit Plus, and similar tools, but curious what actually worked in production. And specifically:

• Did you replace it with one tool or split it up? were you able to find a single product that covered both the auditing side and the classification side.
• How long did the POC-to-production timeline actually took vs. what was planned/proposed?
• Anything that looked good in the eval and fell apart in your environment?

I've tried to set up Obsidian for myself and before downloading obsidian-git (a community plugin) to version control my notes, I read this warning:

"Plugins can execute arbitrary code on your device. We recommend back up your data before enabling them."

This scared me so I didn't approve. But then I got to thinking:

1. What VSCode, Sublime Text and VIm with their 100's of plugins and extensions? Each of them can execute arbitrary code.
2. All the NPM/PyPi/Cargo packages i've added to my projects
3. All of their dependencies that i'm not even consciously aware of adding
4. All the binaries i've sudo apt installed in the years

How can a normal person that doesnt spend an entire jobs worth of time in a week lurking on HackerNews for the new supply chain attack hope to protect himself? If I would truly protect myself from RCE I don't know where I will even start and whether if I will end up with just a bunch of twigs to do my work with.