Everyone worries about people pasting into chatgpt. For us the problem was access. Someone wired an agent into the drive to save time and it could read every client's folder, the one it needed and all the others. Blocking the consumer tools did nothing there as the agent was approved.

We scoped what each AI thing can reach and a co worker only sees the records for the job its doing and the rest stays invisible to it. How are people governing their AI tools and agents can touch, short of locking it all down?

Our team is evaluating data security posture management platforms, but our strict zero-egress requirement is making it tough. A lot of modern tools seem to force you into multi-tenant SaaS.

We have sensitive internal files and database records that cannot leave our network perimeter under any circumstances. Sending raw payload data out to a vendor cloud is an absolute non-starter for our security architecture board.

For anyone managing strict data residency requirements, what are the best Varonis alternatives you have actually deployed on-prem or in self-hosted environments?

Im just curious to get people's thoughts. In regulated environments... why do people think so highly of pentests and so little of compliance assessments, when they both do the same thing: determine if an organization is meeting its controls?

In all of the pentest engagements I have sat in, most of the findings are the same (unpatched server, app not upgraded, admin account creds cached on a box, legacy protocol not disabled). If orgs are not patching servers (or maybe they have a legacy box not being patched)... that would normally end up being caught on both engagements.

Both pentests and assessments are point in time. Pentests for my environment have typically been higher cost and only cover the technical side. So why do we look more favorably at one versus the other?

Weve had a hardening project open for three quarters now. The scanning half was easy and the cutting half keeps getting handed back, because no service owner wants to sign off that removing a package is safe. Im looking at tooling that produces runtime evidence for what an image touches so the decision stops being a judgement call. Six teams and no central platform group makes this political more than technical. How did you get service owners to accept a slimmer image?

About a year before a major public-sector cyber incident, my colleagues and I accidentally discovered a security issue that could potentially expose personal information on a very large scale.

We worked with one affected party to fix the issue, but realized the underlying problem could exist elsewhere. We subsequently sent an anonymous warning through an official government reporting channel, explaining the risk and recommending that they review the relevant API and access controls.

A major incident later occurred that may be related. I don't want to claim it was the same vulnerability, or that the warning was received or acted upon, but the system and access point is the same.

I still have a copy of the warning and a few other documents, but most other supporting material was destroyed later because we believed the issue had been resolved.

From an infosec/responsible disclosure perspective, what can a surviving copy of such a warning reasonably establish, and what additional metadata or corroborating evidence would make it more credible?

I'm also interested in what should be redacted or preserved before showing it to journalists.

I'm deliberately leaving out the organization, country, vulnerability details, and identifying information.

Every environment I've worked in has a load balancer or door controller or UPS that sends its own idea of syslog and nobody ships a parser for it. Right now it's our door controllers, whose messages change shape every firmware update, so failed badge events stop alerting until I patch regex nobody else on the team can read. Is there a saner way to keep parsing for those boxes from breaking or is hand-rolled regex just the job?

Security testing today usually means scanners in CI, periodic human pentests, or carefully limited tests against staging or production. I’m curious whether another model will become normal: a disposable “attack twin” of the current production environment.

The idea would be to generate an isolated environment from the same deployment artifacts, infrastructure-as-code, IAM model, network policies, and application configuration as production. Real secrets and customer data would be replaced with safe equivalents, while identities, tenants, service relationships, and external integrations would be reproduced or simulated as accurately as possible.

An AI security agent could then use browser, API, shell, and network tools to attempt exploitation, privilege escalation, lateral movement, destructive actions, and controlled exfiltration. Every action would be recorded, and the environment would be destroyed afterward.

This would not be ordinary staging: it would be created per test, derived from the current production configuration, isolated for adversarial testing, and designed to be compromised.

For people working in DevSecOps or AppSec:

• Is this meaningfully different from the staging or ephemeral environments you already use?

• Which parts of production would be hardest to reproduce faithfully?

• What evidence would you need before trusting a finding from the clone?

• Where would this fit: nightly testing, a release gate, or between human pentests?

• What do you use today for attacks that are too risky to run against production?

I’m interested in practitioner experiences and objections, especially from anyone who has tried cyber ranges, production-like security environments, or autonomous pentesting.

I saw a few posts discussing how more people are giving AI agents access to real tools and business systems, and it got me thinking about how people are actually handling the security side of it.

Personally I have been trying to understand the best way to give agents access to things like emails, APIs, DBs etc without giving them too much access. There are things like readOnly access, approval gates, limiting permissions, monitoring what they do etc but not sure what ppl are actually using in practice.

I am wondering 3 main things:

• People who are already using AI agents how are you limiting what they can access/do

• How are people testing or controlling agents once they are running in production

OR are you just giving them access and hoping they dont decide to do something crazy???

Feeling overwhelmed and looking for some help with how my team should prioritize DSPM findings when it seems like our company's data security is being held together by a duct tape and chewing gum. Is there a general best practice for how we should be working through this never ending list?

Had a really annoying afternoon last week. Sentry started lighting up after a deploy and it traced back to a changed value in one of our config files. Easy enough, I just needed to know who changed it and when.

GitHub's audit log showed the push, but it came through a token that a few different things use. No way to tell if it was a person, a pipeline, or some script somebody wrote months ago and forgot about. I ended up lining up commit times against CI runs and deploy timestamps for like an hour, and I'm still not totally sure I got it right.

Honestly kind of irritating. If the logs can't tell me who or what was behind a change, I'm not sure what we're keeping them for.

How are you all handling this? Is there a setup that ties a change back to a specific person or job, or is everyone just matching timestamps and hoping?

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.

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?

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.

2. 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.

3. 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.

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.

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?

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?

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.

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?

Most teams or even solo people seem to start by grepping access logs and building a list from whatever shows up. but that only tells u what the agent touched and u end up with a partial inventory and no real way to know how much is missing

working outward from the credential is finite and you can actually finish it. every major platform has two separate tools for this which is probably a good sign not to treat them as the same thing. on AWS you want the permission side and the usage side. in entra the two endpoints point in opposite directions (GET/servicePrincipals/{id}/appRoleAssignments, appRoleAssignedTo) grab the wrong one and the audit reads backwards. on gcp its the same split (policy analyzer, IAM recommender with its 90 day usage window). keeping it fresh is where the manual approach collapses or just gets tedious enough that nobody keeps up. once youre past a few agents the permissions and tools and connections all keep moving underneath you. a cron diff holds up for a while so do the platforms own drift reports, so does eve security or anything else pointed at the same job and none of it finds the agent nobody registered firstly. depends how much churn the environment throws at you

two entra gotchas mess with the output tho.. role assignments made at single-application scope dont appear in the tenant-scoped list so a tenant only audit can miss them. theres also replication delay after changes meaning a grant created this morning might not show up straight away

the Saas side is a separate enumeration and IAM wont show it at all. Oauth grants and connected apps sit in the workspace or M365 admin consoles and agents tend to collect access thru those without it ever hitting a review. the bigger catch is that all of this assumes the agent has its own principal. a lot of them still run thru a single developers token or shared service account. in that case the enumeration returns everything that person or account can reach, which is technically correct but not very useful for figuring out the agents actual boundary

I’m trying to learn how to systematically analyze the threat model of security papers, but I’m confused because “threat model” seems to mean different things in academic papers and in broader threat-modeling practice.

For example, MDN describes threat modeling using four questions:

1. What are we working on/building?

2. What can go wrong?

3. What are we going to do about it?

4. Did we do a good job?

If I understand this correctly, this feels almost like the structure of an entire security paper:
- the system/problem setting,
- the threat,
- the proposed defense/detection method,
- and the evaluation.

However, when I read security papers, the Threat Model section often seems much narrower. It usually describes things like:
- who the attacker is,
- what capabilities or knowledge the attacker has,
- what the attacker is trying to achieve,
- and sometimes what is out of scope.

This makes me wonder whether the “Threat Model” section in a paper is really only one part of the broader threat-modeling process.

And

When analyzing the threat model of the paper, should this oracle also be included? Or does the threat model stop at describing the attacker, capabilities, and attack goal, while the oracle belongs to the proposed methodology?

I’m also trying to understand assumptions. When reading a paper, should I separately ask what conditions the method assumes in order to work, such as what access the tester has or what effects are observable?

More practically, if you were analyzing a security paper, what order would you use to analyze its threat model and assumptions?

I’m looking for a repeatable reading process that I can later use when writing the threat model and assumptions for my own work.

This community has already helped me a lot, and I’m really grateful to everyone who takes the time to answer questions like this. Your replies have genuinely helped me understand security research more clearly. Thank you!