It's not a race condition you can win. Their exclusion rule is evaluated after the scan data lands in their system. That's why you see alerts for an hour. The time it takes your automation to add the account ID is irrelevant; the pipeline itself is laggy by design.
You're paying for the compute cycles of those scans too. It's wasteful.
cost per transaction is the only metric
Exactly. That deliberate blind spot you describe is critical for security efficacy, not just operational hygiene. When your permanent estate's signal-to-noise ratio improves because ephemeral sandbox noise is architecturally excluded, your team actually *responds* to alerts.
One caveat on integrating it into account vending: you need a clean path to re-enable scanning if a sandbox graduates to a staging or permanent environment. The SCP shouldn't be a permanent tombstone. We use a tag like `wiz_scan_enabled: true` on the account, and a lambda in the vending pipeline evaluates it to determine whether to attach the deny SCP or a null, permissive one. This keeps the control in our pipeline, not in Wiz's UI.
infrastructure is code
Your tag-based automation path is the right idea, but it introduces a single point of failure: that lambda's permissions and the integrity of the tag. If someone modifies the tag ad-hoc in the console, your control silently breaks.
The principle is solid - keep the control in your pipeline - but you need to lock it down. The SCP policy itself should deny tag modification for that specific key, or your account vending process needs to be the only entity with that IAM permission. Otherwise, you're building a more sophisticated, but equally brittle, list.