What Your Automation Accounts Are Actually Running
September 14, 2026 · InfraScout Team
Azure Automation accounts tend to outlive the people who set them up. A runbook written to rotate a certificate three years ago still runs every night, under an identity nobody remembers granting, reading a variable that was never encrypted, triggered by a webhook whose URL has been pasted into who knows how many ticket comments. None of that shows up in a resource inventory. An inventory tells you the Automation account exists; it does not tell you what it does.
You can now ask. InfraScout reads the inside of an Automation account — runbooks and their source code, job history, job output and error streams, schedules, webhooks, variables, credentials and connections — so an assessment can answer what runs unattended in your subscriptions, as whom, and with which secrets.
The questions you can ask
An Automation review usually comes down to a handful of questions, and each one now has a direct answer.
What runs, and when? List every Automation account across a subscription, then the runbooks in each with their type, state and last change, and the schedules that start them. Runbooks nobody has touched in two years, on a schedule that still fires daily, are the first place to look.
With which credentials? The AI reads each runbook's published source, and its unpublished draft, and reports what it finds: the credential and connection assets it pulls in, the subscriptions and tenants it touches, and anything hardcoded — a password in a string literal, a storage key, a connection string.
Are the secrets stored safely? Automation variables can be encrypted or not. Every variable comes back with its encryption flag, so "which variables are stored in cleartext?" is one question instead of a portal click-through per account.
Who can start it from outside? Webhooks come back with their expiry dates. A webhook that never expires, or one on a runbook that no longer needs to be triggered externally, is a standing invitation to anyone who has seen the URL.
Is it working? Job history, filtered to failures, with each failed job's output and error stream. A runbook that has failed silently every night for a month is a finding too — especially when it is the one meant to clean something up.
"Audit every Automation account in the Production subscription: list the runbooks, flag hardcoded credentials in their source, list unencrypted variables, and show webhooks that never expire."
Secrets stay masked until you ask
Unencrypted Automation variables and connections hand their values back in cleartext, and a sweep across a dozen accounts would otherwise copy every one of them into your conversation history. So by default, variable values and connection field values come back as a placeholder. The encryption flag is kept, because for most reviews that is the finding — an unencrypted variable is worth reporting whether or not you ever look at its value.
When the value itself matters, the AI can ask for it on a single call. That output is kept out of the stored execution record, the same way LAPS passwords and BitLocker recovery keys are, while the fact that secrets were revealed is still audited.
Runbook source is the deliberate exception, and it is never masked. The script is the thing under review. A credential hardcoded in it is exactly what you want the review to surface, so InfraScout shows it to you, and the AI treats it as a finding to report rather than a value to repeat. Automation credential assets never expose their passwords at all — Azure returns the username only.
One reader, not a tool per resource type
None of this took new tools. The existing Azure resource reader, mscloud_platform_get_resource, now reads collections beneath a resource as well as single resources, pages through them, and returns plain-text bodies such as runbook source and job output alongside JSON. Long text is capped at 64 KB with a visible marker, so a clipped runbook never passes for a complete one.
That makes the reader useful well beyond Automation. Every Azure provider versions its API separately, and the AI does not need to know the right version in advance: a wrong guess comes back with the list of versions that resource type supports, and it retries with one of them. The reader also only ever talks to Azure Resource Manager — a resource ID cannot point it anywhere else.
What you need
Azure is governed by Azure role assignments, not by the Microsoft Graph permissions the onboarding script consents. The InfraScout app needs the Reader role on each subscription you want to assess. A connection without one still connects, but sees no subscriptions at all — so if the AI tells you a tenant has no Azure subscriptions and you know better, that is the missing grant. Granting Azure Access walks through assigning it.
Try it
Start broad with "list our Automation accounts and what each one runs", then pick the account that surprises you and ask for its runbook source, its webhooks, and its last month of failed jobs.
The paths, arguments and masking rules are in Microsoft Cloud — Platform Tools. Questions? info@infrascout.cloud.