Automated incident response in cloud environments usually stops at a human gate, for good reason. When attacks are rare, even accurate symptom alerts are overwhelmingly benign, so an action automated on them would mostly cause self-inflicted outages. We argue for a principle we call automate on certainty: trigger autonomous response only on signals with a high posterior probability of attack, and only with actions that are cheap to get wrong. We formalise this trade-off with Bayes' rule and an expected-cost threshold. We also distinguish symptom signals, which measure effects against a baseline, from intent signals, which record a decision the attacker made. Honeytokens (decoy credentials with no legitimate use, also called canary credentials) are the cheapest way to manufacture intent signals, and each one points at the single place it was planted. We present a design for an IAM honeytoken pipeline on AWS. It documents the platform behaviours it depends on and its pitfalls: read-only event matching, regional rules, trail prerequisites and account-ID fingerprinting. We then couple trips to bounded, restorable containment admitted under verifiable, reversible and contained criteria, within an operational lifecycle. We report no measurements, and we separate design from code present in an open-source implementation.
No takes yet. Share an insight, caveat, or question.
Ilia Dubovskii (2026) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: