Agentic Workflows: Assessments That Run Themselves

June 15, 2026 · InfraScout Team

Until now, every InfraScout assessment needed a person in the chat — someone to ask the question, watch the tools run, and read the result. Agentic Workflows change that. You define a workflow once: an instruction telling the AI what to assess, optionally one of your assessment playbooks to follow, the tool groups it may use, and a few limits to keep it bounded. From then on, InfraScout can run that assessment on its own — on a schedule, the moment an external system fires a webhook, or at the press of a button — with no one watching the conversation. Every run is recorded in full so you can review what happened after the fact. This is the biggest capability we've shipped since the last update, and it turns InfraScout from a tool you drive into one that also runs your routine reviews for you.

What a workflow is

A workflow is a reusable, headless assessment. Instead of typing a prompt into a live session, you capture that prompt once as a workflow instruction, then let InfraScout execute it whenever you need it. The instruction is the heart of it — plain-language direction like "review conditional access policies for gaps against our baseline and flag anything weaker than required." From there you can attach one of your assessment playbooks so the AI follows a structured review rather than improvising, narrow the tool groups it's allowed to call so it stays in scope, and set limits that cap how far a single run can go.

When the workflow runs, InfraScout carries out the instruction end to end — calling tools, reasoning over the results, and recording findings — without a human in the loop. The findings land as insights you can review on your own schedule, not in real time. A nightly tenant security sweep, a per-customer compliance check, a kick-the-tires investigation that fires on an alert: all of these become workflows you set up once and forget about.

Safe by identity, not by trust

Running an assessment unattended raises an obvious question: under whose identity does it act? The answer is what makes the whole feature safe to leave running. Every workflow executes under a dedicated service account you create in admin — never an interactive admin, never your own login. You define what each service account can see by giving it a scoped visibility context: which agents and which Entra groups fall within its reach. A workflow can only ever touch what its service account is allowed to touch, and it cannot escalate beyond that.

This identity is enforced live. If you disable a service account, any tool calls already in flight stop using it immediately — the system fails closed rather than letting an in-progress run coast on revoked access. That means revoking a service account is an instant, reliable kill switch, not a request that takes effect "eventually." Unattended runs are safe precisely because they are confined to a non-admin identity whose reach you define and whose access you can pull at any moment.

TIP

Give each workflow its own service account scoped to exactly the agents and groups that workflow needs. A tightly scoped identity is the cleanest way to guarantee a nightly run can't wander into systems it was never meant to assess.

Three ways to start a run

A workflow does nothing until something triggers it, and you have three ways to do that.

The simplest is Run now — kick off a run by hand from the admin UI whenever you want one, optionally passing in a small JSON payload that the run can use as context. This is the mode you'll live in while you're iterating on a workflow's instruction, watching how it behaves before you automate it.

For automation driven by other systems, each workflow can expose a public inbound webhook. The webhook has its own URL and is authenticated by a single secret token using industry-standard encryption — the secret is shown to you once when you create the webhook, and you can rotate or revoke it at any time. Anything that can make an authenticated HTTP request can now launch an assessment: a SIEM alert can fire an investigation the instant it detects something, a ticketing system can trigger a review when a case opens, or a CI job can run a compliance check as part of a pipeline. The external system supplies a payload; InfraScout treats that payload as untrusted input and never lets it expand what the run is allowed to do.

The third trigger is a schedule. You assign one or more cron schedules to a workflow — standard five-field cron expressions, each with an IANA timezone — so it runs nightly, weekly, or on whatever cadence you set, in the timezone you operate in. Scheduled firing is turned on by your InfraScout administrator in the server configuration and ships turned off by default, so if you want schedules to run, confirm with whoever operates your server that scheduling is enabled.

Sync and batch execution

Not every workflow has the same urgency, so runs come in two execution modes. Sync runs execute inline and finish in seconds — ideal for quick, interactive iteration when you're refining an instruction and want to see the result right away. Batch runs execute on a cheaper batch engine and finish in minutes to hours — the right choice for large or non-urgent sweeps where cost matters more than turnaround. A nightly tenant-wide review is a natural batch job; a quick "check this one policy" is a natural sync run.

Each workflow carries its own concurrency and rate limits, so even a busy webhook or an aggressive schedule can't spawn an unbounded pile of runs. The limits keep automated assessments predictable no matter how often something tries to trigger them.

Pinning a workflow to one tenant

Microsoft Cloud assessments raise a multi-tenant hazard: an AI asked to "check the tenant" could, in principle, reach for the wrong one. A workflow closes that door. You can pin a workflow to a single Entra connection, and once pinned, every Microsoft Cloud (mscloud_*) tool call in that workflow's runs is guaranteed to hit exactly that tenant — the AI cannot target another tenant even if its instruction or an incoming payload tries to steer it elsewhere.

This is built for managed service providers. Stand up one workflow per customer, pin each to that customer's connection, and run the same compliance assessment across your whole book of business on a schedule — with a hard guarantee that each run stays inside the customer it belongs to. The pin is an enforcement boundary, not a default the AI can talk its way past.

Memory and insights, scoped to the workflow

A workflow can keep its own memory files and insights, namespaced to that workflow and layered over the tenant-global pool. That keeps a recurring assessment coherent across runs — it can build on what earlier runs of the same workflow learned — without bleeding into unrelated work. When a workflow needs broader awareness, you can opt it in to include the wider tenant context as well, so it sees the global picture on top of its own.

Findings stay attributed to their source: insights produced by a workflow's runs are tagged to that workflow, so when you review results you always know which assessment surfaced them. For an MSP running per-customer workflows, that attribution is the difference between a clean per-customer record and an undifferentiated pile of findings.

Watching and reviewing runs

Because runs happen without you, visibility into them matters. A new top-level Agentic Workflows section in admin organizes everything into workflows, schedules, and runs. Every run is recorded with its full transcript, so you can read exactly what the AI did and why, long after it finished. While a run is active you can watch it move through its phases in real time — queued, submitting, waiting, executing tools — with a turn counter that shows how far along it is, and each workflow shows a clear indicator when a run is in progress.

Each run carries its trigger, duration, and status, so the run history doubles as an audit trail: you can see at a glance that last night's scheduled sweep completed, that a webhook-launched investigation ran when the alert fired, and how long each took. If a run is queued or still going and you no longer want it, you can cancel it. Nothing about an unattended run is opaque — you can always see what ran, what it did, and stop it if you need to.

Try it

Start with a workflow you'd otherwise run by hand every week. Write the instruction, attach a playbook if you have one that fits, scope it to a service account with just the reach it needs, and use Run now a few times to watch it behave. Once you trust it, pin it to the right tenant, add a schedule or wire up a webhook, and let it run on its own. The admin guide walks through service accounts, triggers, and run review step by step — see the admin guide to set your first workflow up.

For more on what InfraScout can assess from chat, browse the blog. Questions or feedback? Reach us at info@infrascout.cloud.