Agentic Workflows ​

Agentic Workflows let the AI run assessments without a person in the loop. Instead of an admin or end user opening a Chat and steering the conversation, you define the assessment once — an instruction, the tools it may use, the identity it runs as — and let InfraScout fire it on demand, from a webhook, or on a schedule. The run executes headless, files its insights, and lands in the Runs view for review.

A workflow bundles everything a run needs to act on its own: an instruction (and optionally a playbook), a selection of tool groups, a service-account identity, an optional Entra connection pin, an execution mode, and concurrency and rate limits. Because there is no human to approve each step, the boundaries you set on the workflow are the boundaries the run lives inside.

Layout ​

Agentic Workflows is its own top-level section in the admin area. Inside it, three sub-tabs organize the work:

  • Workflows — the catalog of defined workflows, each with its triggers, status, and a running badge while a run is in flight.
  • Schedules — the cron schedules you can attach to workflows for unattended firing.
  • Runs — the execution history and live view of every run, across all triggers.

Service accounts ​

A workflow never runs as the admin who created it, and never as the end user who triggered it. It runs under a dedicated, non-admin service account that you create under Role Management → Service Accounts. The service account is a first-class identity with its own scoped visibility context — the set of agents and Entra groups it is allowed to see — so a workflow can only ever reach the targets that identity can reach.

Three properties make service accounts safe to leave running unattended:

  • Never admin. A service account cannot hold an admin role. It acts only within its visibility scope, so a runaway or misdirected run cannot escalate.
  • Fail-closed. Disable the service account and its runs stop acting immediately — there is no grace window. This is your fastest kill switch for a misbehaving workflow.
  • Reference-protected. You cannot delete a service account while a workflow still points at it. Reassign or remove the workflows first, then delete the identity.

TIP

Give each engagement or customer its own service account with a tightly scoped visibility list. That way a workflow can only ever touch the agents and groups that belong to that engagement, even if its instruction is broad.

Creating a workflow ​

Click Create Workflow on the Workflows sub-tab and fill in what the run needs to operate:

  • Name — a human-readable label that shows on the card and in every run's attribution.
  • Instruction — the standing task the AI carries out each run. This is the headless equivalent of the first message you would type in a chat.
  • Playbook — optionally attach a playbook to give the run a structured, repeatable review to follow instead of a free-form instruction.
  • Tool groups — the tool groups the run may call. The run can use nothing outside this selection.
  • Execution mode — sync or batch (see Execution modes below).
  • Limits — per-workflow concurrency and rate limits that cap how many runs execute at once and how often new runs may start, plus a turn budget (max_turns) that caps how many turns a single run may take before it stops itself. The budget accepts 0–200; leave it unset to use the server default of 20. Raise it for large sweeps that legitimately need more steps. Each run shows its turn progress against this cap in the Runs view.
  • Status — enabled or disabled. A disabled workflow keeps its definition and history but refuses every trigger.

Two optional fields tie the workflow to a Microsoft Cloud tenant: an Entra connection pin and an include tenant context toggle that seeds the run with the connected tenant's baseline context. Both are covered under Entra connection pin.

Triggers ​

A workflow can be fired three independent ways. A single workflow can carry all three at once — a schedule for the routine sweep, a webhook for event-driven runs, and Run now for ad-hoc checks.

Run now ​

The Run now button starts a run by hand, immediately. You can attach an optional JSON payload that the run receives as input — handy for passing a target, a date range, or any parameter the instruction knows how to read. Treat the payload as input to the assessment, not as configuration of the workflow itself.

Webhook ​

A workflow can expose a public inbound webhook URL that starts a run when something external calls it. The webhook is authenticated by a single secret token, transmitted as an industry-standard encrypted token and shown to you exactly once at creation. Copy it then; you cannot retrieve it afterward. You can rotate the secret to invalidate the old one, or remove the webhook entirely. The trigger button on the workflow reflects whether a webhook is currently configured.

The caller can present the token two ways: embedded in the webhook URL, or sent in an X-Webhook-Token header against the same endpoint. The header form keeps the secret out of request logs and URL history, so prefer it when the sender supports custom headers.

WARNING

Webhook payloads are untrusted input. A run treats anything that arrives over the webhook as customer data to be assessed, never as instructions to follow — but you should still scope the workflow's tool groups and service account tightly, because the webhook URL is reachable from outside.

Schedule ​

On the Schedules sub-tab you define cron schedules, each with an IANA timezone (for example Europe/Vienna), and attach them to workflows. A schedule fires the workflow on its cron cadence under the same service-account identity as any other trigger. Schedules accept a standard five-field cron expression (for example 0 2 * * *) or a named descriptor such as @daily or @hourly; seconds-level precision and the interval-style @every shorthand are not accepted.

Each schedule has its own enabled toggle, separate from the workflow's status and from the server-wide scheduler. Disable the toggle to pause firing for that schedule without deleting it — its cadence clock keeps advancing while paused, so re-enabling resumes on the next due tick rather than replaying the runs missed while it was off. Only an explicit pause disables a schedule; a newly created schedule is enabled by default.

Scheduled firing is off until an operator turns it on. The server ships with the scheduler disabled and the operator enables it with the WORKFLOW_SCHED_ENABLED setting; until that switch is on, schedules can be defined but will not fire.

INFO

A scheduled run fires only when all three gates are on: the server-wide scheduler (the operator's WORKFLOW_SCHED_ENABLED switch), the schedule's own enabled toggle, and the attached workflow's enabled status. A schedule that does not fire is almost always one of these — start with the server-side switch, since defining a schedule in the portal does not enable scheduled firing on its own.

Execution modes ​

Every workflow runs in one of two modes, and each run records the mode it actually ran in.

Sync mode runs inline and returns in seconds. It is the right choice while you iterate on an instruction or playbook, or for small, time-sensitive checks where you want the result back right away. A sync run may take up to twenty minutes before it hits its execution deadline, so a workflow that reaches across a handful of agents or does a few rounds of analysis has room to finish inline. Batch mode runs on the batch engine and can take minutes to hours. It is built for large or non-urgent sweeps — a full tenant review, a fleet-wide inventory pass — where throughput matters more than latency.

Choose the mode on the workflow, but read it back from the run: a workflow that normally runs sync may have an individual run recorded under a different mode, and the run's record is the source of truth for what happened.

Entra connection pin ​

When a workflow targets a specific Microsoft tenant, pin its Entra connection. With a pin set, every mscloud_* call made by the workflow's runs is forced to that connection. The model cannot redirect a call to another tenant, and the run's audit records the connection that was actually used.

This is the right control for managed-service runs, where one InfraScout server assesses many customer tenants. Pin each customer's workflow to that customer's connection and a misfired run physically cannot read another customer's data. Pair the pin with the include tenant context toggle to seed the run with that tenant's baseline so the AI starts with the right footing.

Workflow-scoped memory and insights ​

Headless runs benefit from the same persistent context as interactive chats, but you usually want that context isolated per workflow rather than mixed into the tenant-wide pool. Both memory and insights can be namespaced to a workflow: the run reads and writes its own scoped layer, laid over the tenant-global pool, so one workflow's working notes never bleed into another's.

Deleting a workflow cascades its scoped memory and insights, so retiring a workflow cleans up after itself. From the admin views you can group and filter memory and insights by workflow to see exactly what a given workflow has accumulated.

Monitoring runs ​

The Runs sub-tab is the operational view of everything the workflows have done and are doing. Each run row shows its status, which trigger started it, who or what triggered it, how long it took, and the reason it ended. While a run is in flight you see live phase and turn progress, and each workflow card carries a running badge so you can spot active work from the catalog.

Click any run to open its full transcript — the same turn-by-turn record you would see for an interactive chat, captured for the headless run. You can cancel a run that is pending or already running from this view. A separate tenant-wide active-runs view rolls up everything currently executing across all workflows, which is where you look first when you need to know what the server is doing right now.

Every run carries one of five outcomes. Two are in-flight — pending (accepted, waiting to start) and running (actively working) — and three are terminal: succeeded, failed, and cancelled. Two cases look like a missing run rather than a status, and both are by design. A trigger that is turned away by the workflow's rate limit is reported to the caller but never recorded as a run, so a fire that you know was sent but cannot find in the history was rate-limited during a burst. And a run still in flight when the server restarts is marked failed with the reason abandoned once it has been stranded past a short grace window — the grace window keeps a run that is merely mid-handoff from being failed prematurely.

TIP

The transcript is your audit trail for unattended work. Before you widen a workflow's tool groups or loosen its limits, open a recent run and confirm it only reached the targets and tools you expect.

Security model ​

Agentic Workflows are designed to be safe to leave running without a human watching each step. The guarantees stack:

  • Fail-closed identity. Every run acts as a non-admin service account scoped to a fixed visibility context; disabling the account stops its runs from acting at once.
  • Authenticated webhooks. Inbound triggers require the secret token and are rejected uniformly when it is wrong, so an attacker learns nothing from a failed call.
  • Pinned-connection guarantee. A pinned Entra connection forces every Microsoft Cloud call to one tenant, and the audit shows the connection used.
  • Untrusted payloads. Webhook and Run now payloads are treated as data to assess, never as instructions to obey.
  • Bounded throughput. Per-workflow concurrency and rate limits cap how much a single workflow can run at once and how often it starts.

DANGER

A scheduled or webhook-triggered workflow acts on its own, repeatedly, with no per-run approval. Scope its service account and tool groups to the minimum the task needs, pin the Entra connection when it touches a tenant, and disable the workflow — or its service account — the moment it behaves unexpectedly.