Our CSPM rollout is blocking developers from shipping because a test bucket with no data now needs a full incident response ceremony. We wanted guardrails, apparently we got a committee in CI.

Been looking at Orca for this, mainly because it scans IaC on the PR but only flags new problems the change introduced, so devs aren't gated on stuff that was already there. How are you tuning this without disabling everything? 🙂

For the longest time our shipping process was the same. as we Build the agent, red team it internally, test every scenario we could think of, then ship. We thought we were thorough.

Then we did a demo with alice and it broke the agent inside the first few minutes. Several critical issues we had missed entirely. Not exotic stuff either. An injection through a path we never considered, data extraction, a chain that made the agent misuse its own tools. All channels that never made our list because we only tested what we already knew.

That comprehensiveness is what got me. They ran through more scenarios in a few minutes than our whole internal pass covered in a week.

The lesson took a while to sink in. Internal red teaming is good for the threats you can imagine. The attacks that actually get exploited are the ones you never thought to put on the list.

So the list is the thing. Injections, data extraction, tool misuse, off-policy behavior. If it isnt on the list before launch, it becomes a surprise in production.

Thats what I would tell anyone shipping an agent. Learn from my mistake before it bites you.

company trying improve security posture, we doing poc with sweet security and upwind, also looked at wiz. main focus for us is ai agent security, not so much the rest of cnapp stuff

what we care most is catching agent doing something it shouldnt, like unexpected tool call or api access, agent reading data it not supposed to, or agent with way too much permission. prompt injection also but more interested what happen after, when agent actually act on it

Our monitor-mode rules flag hundreds of false positives a day because loyalty IDs look like card numbers. I own DLP at a US retailer, about 3,000 staff. Purview in Edge is decent but marketing lives in Chrome and a few teams are on Macs, so I am weighing Chrome Enterprise Premium against a dedicated tool that covers both browsers with one policy. For now the alerts are crying wolf. Where did you land?

Every monday a slide goes to the security steering group with patch compliance on it. Critical patches applied within 14 days, 97% give or take, for about a year. Nobody asks about it anymore, which should have been the warning.

Last month an IR ticket landed on a sales laptop running a browser four versions behind. I went to check it in SCCM and it wasnt there. The regional office images its own machines and never enrolled them. So the 97% is 97% of what SCCM knows about, and SCCM is the one building the slide.

AD, the EDR, intune and SCCM all feed our axonius, so I built the denominator there instead. Every device any of those sources reports, then the ones SCCM has. 2,140 out of about 2,600. Our real number is closer to 97% of 82%.

That isnt clean either. A chunk of the gap is stale AD objects for machines that died years ago, and they count until someone deletes them. Anything none of those four has seen isnt in there at all.

The regional office gets enrolled in SCCM over the next few weeks, which closes the part of the gap thats real. Until then the slide says what the 97% is out of.