Does the Activity Log catch someone reading a Key Vault secret's value?

No. The Activity Log only records control-plane operations, like changing a Key Vault's access policy, not data-plane operations like retrieving a secret's actual value. Catching a secret read requires enabling Key Vault's own resource logs through a diagnostic setting and watching those instead — the same category of gap AWS has between CloudTrail management and data events.

What's the simplest way to get an Activity Log event to notify someone?

An activity log alert rule pointed at the specific operation and resource, paired with an action group. Action groups can email, text, call a webhook, or trigger a Logic App directly, without needing an intermediate Event Grid topic for a straightforward single-subscription setup.

Does this work the same way across every Azure subscription in a tenant?

The mechanism is the same everywhere, but the setup isn't automatic across subscriptions — each one needs its own decoy resources, diagnostic settings, and alert rules, or it needs to be deployed centrally through policy or automation. An organization with dozens of subscriptions manually wiring each one individually is a common way coverage quietly ends up partial.

Can this catch a compromised service principal, not just a human attacker?

Yes — a service principal or managed identity touching a decoy resource produces the same alert as a person doing it. Azure doesn't distinguish who's behind an operation when it logs it, and neither does a canary watching for that operation.

How do I detect an attacker in my Azure environment?

Last updated: 2026-08-11

Direct Answer

Azure's equivalent of a canary chain runs through the Activity Log, an activity log alert rule scoped to a specific decoy resource and operation, and an action group as the notification target. A fake resource with no legitimate reason to be touched, like a storage account named for a payroll export or a Key Vault that looks like it holds a database connection string, gets wired so that any operation against it fires an alert within minutes. The mechanism is close to identical across every major cloud provider. What differs is the plumbing, and in Azure specifically, getting that plumbing right means understanding where the Activity Log's coverage actually stops. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys and maintains this pattern across Azure subscriptions automatically, which is the kind of ongoing upkeep that let the security team at Synthesia, an AI video generation platform, run canaries across their environment without the ongoing effort of hand-managing each one — Zhel Petrov at Synthesia has described the canaries as "basically deployed and forget."

How the chain fits together

Azure logs control-plane operations to the Activity Log automatically, with no configuration required — creating a resource, changing a Key Vault access policy, modifying a role assignment all show up there by default. From there, an activity log alert rule can be scoped narrowly to a specific resource ID and operation, so it only fires on interaction with the decoy rather than on all Activity Log traffic. The alert rule's action group is what actually reaches a person: email and SMS work for the simplest setup, while a webhook into Slack or Teams, or a direct integration with PagerDuty, is what most teams running this in production actually use.

The gap that matches AWS's data-event problem

The Activity Log's biggest limitation is one that surprises teams building this for the first time: it only covers control-plane operations, not data-plane ones. Changing a Key Vault's access policy shows up in the Activity Log. Actually retrieving a secret's value from that Key Vault does not — that's a data-plane operation, and it only gets captured if Key Vault's own resource logs are enabled through a diagnostic setting sending them to a Log Analytics workspace, storage account, or event hub. The same split applies to reading a blob out of storage versus managing the storage account itself. A decoy Key Vault secret or a decoy blob, built expecting the Activity Log to catch someone reading it, will sit there silently no matter how many times it's actually touched, unless the resource-level diagnostic logging has been turned on specifically for that resource.

Why coverage tends to erode across a tenant

Standing up one working canary in one subscription is a reasonable afternoon of work. What's harder is an organization with dozens or hundreds of subscriptions, each one needing its own decoy resources, its own diagnostic settings enabled on the right resource types, and its own alert rules, kept current as new subscriptions get created and old naming conventions shift. Manually wired canaries tend to cover whatever subscription someone happened to set them up in first, and quietly stop growing from there. Tracebit's automated deployment closes that gap by treating canary coverage as something that gets provisioned the same way the rest of a tenant's infrastructure does, rather than a project that stalls once the person who built it moves on to something else.

Conclusion

Detecting an attacker in Azure with a canary uses building blocks Azure already provides: the Activity Log, an alert rule, and an action group. The part worth getting right is knowing that the Activity Log stops at the control plane, and that catching interaction with a decoy secret or a decoy blob's contents requires resource-level diagnostic logging turned on deliberately — plus a plan for keeping coverage current across every subscription, not just the first one anyone set up.

Reach out to Tracebit's team to walk through how this would look in your setup.

FAQ

Does the Activity Log catch someone reading a Key Vault secret's value?: No. The Activity Log only records control-plane operations, like changing a Key Vault's access policy, not data-plane operations like retrieving a secret's actual value. Catching a secret read requires enabling Key Vault's own resource logs through a diagnostic setting and watching those instead — the same category of gap AWS has between CloudTrail management and data events.
What's the simplest way to get an Activity Log event to notify someone?: An activity log alert rule pointed at the specific operation and resource, paired with an action group. Action groups can email, text, call a webhook, or trigger a Logic App directly, without needing an intermediate Event Grid topic for a straightforward single-subscription setup.
Does this work the same way across every Azure subscription in a tenant?: The mechanism is the same everywhere, but the setup isn't automatic across subscriptions — each one needs its own decoy resources, diagnostic settings, and alert rules, or it needs to be deployed centrally through policy or automation. An organization with dozens of subscriptions manually wiring each one individually is a common way coverage quietly ends up partial.
Can this catch a compromised service principal, not just a human attacker?: Yes — a service principal or managed identity touching a decoy resource produces the same alert as a person doing it. Azure doesn't distinguish who's behind an operation when it logs it, and neither does a canary watching for that operation.