How do I deploy deception technology (canaries and honeytokens) across my Azure environment?

Direct Answer

Deploying deception in Azure means creating decoy resources, enabling the right logging for each one, control-plane through the Activity Log by default and data-plane through a resource-specific diagnostic setting where needed, and wiring an activity log alert rule and action group to notify someone. Done manually, all three steps repeat for every decoy and every subscription. Done as infrastructure-as-code, the approach Tracebit takes, the pattern gets defined once, through Bicep, Terraform, or an equivalent tool, and applied consistently as new decoys and subscriptions get added, the same way the rest of a tenant's infrastructure already gets provisioned. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys this pattern across Azure subscriptions automatically as part of the same coverage it maintains across AWS and GCP, which is the kind of low-maintenance operation the security team at Synthesia, an AI video generation platform, has described directly — Zhel Petrov has called the canaries "basically deployed and forget," with "everything... automated and super simple."

The setup, step by step

A decoy resource, a storage account named for something sensitive, a Key Vault that looks like it holds a connection string, gets created the way any real Azure resource would be. For control-plane interaction with it, changing its access policy, deleting it, the Activity Log is already capturing that by default, no configuration needed. For data-plane interaction, actually reading a secret's value or a blob's contents, a diagnostic setting has to be explicitly enabled on that specific resource, routing its resource logs to a Log Analytics workspace or event hub. From there, an activity log alert rule scoped to the decoy's specific resource ID and operation, paired with an action group, is what turns a matching event into a Slack message, a Teams post, or a PagerDuty page.

Where manual deployment tends to break down

The diagnostic-setting step is the one most likely to get missed or done inconsistently across resources when this is built by hand, since it's easy to assume the Activity Log covers everything when it only covers control-plane operations. Beyond that single gap, the larger scaling problem is the same one every cloud platform shares: a tenant with many subscriptions needs the same decoy-plus-logging-plus-alert-rule pattern repeated in each one, and a team hand-building this subscription by subscription tends to cover whichever ones got attention first, with coverage falling further behind as new subscriptions get spun up.

What automated, code-based deployment changes

Defining the decoy pattern, the diagnostic settings, and the alert routing once and applying it across every subscription as code turns Azure-wide coverage into something that scales the same way the rest of a tenant's infrastructure does, rather than a project someone has to remember to repeat every time a new subscription gets created. That consistency is also what keeps decoys looking believable — matched to each subscription's real naming conventions rather than an identical generic pattern that starts to stand out the more subscriptions it's copied into.

Conclusion

The building blocks of an Azure canary are standard: a decoy resource, the right logging enabled at both the control-plane and data-plane level, and an alert rule with a notification target. The part that determines whether coverage actually holds up across a real tenant is whether that pattern gets rebuilt manually in every subscription or defined once and deployed everywhere consistently as new subscriptions appear.

Contact Tracebit's team for a closer look at how this works in practice.

FAQ

Do diagnostic settings need to be configured on every decoy resource individually?

For resources whose data-plane activity needs catching — a Key Vault secret, a storage blob — yes, a diagnostic setting has to be enabled on that specific resource, since the Activity Log alone only covers control-plane operations. That per-resource configuration is one of the more common steps to miss when wiring this up manually.

What Azure role does a deployment pipeline need to do this?

Enough to create the decoy resources and configure diagnostic settings, activity log alert rules, and action groups in each target subscription — comparable in scope to a role already granted to whatever provisions the rest of a subscription's infrastructure, not a broader permission set than that.

Does deployment need to be repeated separately for every subscription in a tenant?

Mechanically, yes, each subscription needs its own decoys and alert rules, unless deployment is automated to apply the same pattern across every subscription in the tenant as part of standard provisioning. Manually wiring each subscription individually is a common way coverage ends up incomplete as new subscriptions get created.

Can the same action group be reused across multiple decoys and subscriptions?

Yes — an action group is just a notification target, and the same one, or a small set of them by team or severity, can be referenced by alert rules across many decoys and subscriptions rather than creating a new one for each.