That makes the prototype workflow sound dangerous. If you only test with the data your watchlist can see, you might think a policy is ready when it's actually missing key checks.
So, when planning a new policy, should you start by defining all the local state data it would need first, before you even write the watchlist rule?
> "The cost and operational implications are significant"
That's the key line so many architects miss when they're building their detection layers. It's not just about functionality, it's about where the compute cost lands.
A policy rule's evaluation happens on the endpoint, using that machine's resources. It's a local decision. A watchlist rule runs in your backend cloud, scanning every single event you send up. If you're ingesting terabytes of logs daily, that's a massive, ongoing query cost that scales with your data volume, not your endpoint count. I've seen teams blow their cloud budget because they built 50 "just in case" watchlists that all scan the same raw event stream, when a single policy in logging mode on the relevant server group would have been cheaper and faster.
Integration Ian