Service Accounts ​

The Service Accounts tab is where you create and manage the identities that agentic workflow runs act under. A service account is a headless identity: there is no person behind it and no one to sign in. When a workflow fires — by hand, from a webhook, or on a schedule — its run executes as the service account you attached to that workflow rather than as the admin who defined it or the caller who triggered it.

This makes a service account distinct from an Entra user. An Entra user signs in interactively through the dashboard or Chat; a service account never signs in at all. It exists only to give unattended runs a stable, scoped identity that you can audit and switch off.

What a service account can see ​

A service account carries one thing that matters for what its runs can reach: a list of Entra group memberships. A run acting under the account sees the resources visible to those groups, and nothing more. Attach no groups and the account can reach only the resources marked Everyone — which, with visibility closed by default, may be nothing at all.

You pick those groups from the security groups already synced through the connectors — the same groups listed on the Groups tab. This keeps a workflow's reach tied to your existing Entra access model: change the membership of a group in Entra and every service account scoped to it follows, without touching the workflow.

INFO

A service account is deliberately non-admin. It has no admin role and no way to acquire one, so a workflow running under it can only ever act inside its group-derived visibility scope. A broad or misdirected instruction cannot escalate past what the account is allowed to see.

Creating a service account ​

Select New Service Account to open the editor and fill in:

  • Name (required) — a human-readable label, up to 100 characters. It appears in the service-account picker when you attach the account to a workflow, and in every run's audit trail, so make it identify the account at a glance.
  • Description — optional free text, up to 500 characters, recording what the identity is for.
  • Entra group memberships — search the synced security groups and check the ones the account should inherit visibility from. Selected groups stay pinned to the top of the list while you search, and the editor shows how many you have chosen. Leaving this empty restricts the account to resources marked Everyone, so a workflow that needs to reach scoped agents will not see them.
  • Disabled — a toggle covered under Enabling and disabling below; leave it off to create the account active.

Names must be unique. If you try to save a name that another service account already uses, InfraScout rejects the change and asks you to pick a different one.

Viewing and editing ​

The tab lists every service account as a card showing its name, description, how many groups it belongs to, and a Disabled badge when it is switched off. Select Edit on a card to reopen the editor with the account's current details loaded, change any field, and save. Editing never changes who created the account or when — that attribution is fixed for the audit trail. Use Refresh to reload the list after a change made elsewhere.

Enabling and disabling ​

The Disabled toggle in the editor is your fastest kill switch for a workflow that is misbehaving. Disable a service account and its runs stop acting immediately — they fail closed, with no grace window. The account, its history, and its group memberships all stay intact, so re-enabling it later restores it exactly as it was. Disabling is reversible; reach for it before deleting when you only need to pause unattended work.

WARNING

Disabling a service account stops every workflow that runs under it, not just one. Check which workflows reference the account before you switch it off so you know what you are pausing.

Deleting a service account ​

Select the delete control on a card to remove an account permanently. Deletion is reference-protected: InfraScout refuses to delete a service account while any workflow still points at it, so you cannot orphan a workflow's identity by accident. Reassign or remove the dependent workflows first, then delete the account. Once deleted, the identity is gone — the action cannot be undone.

DANGER

Deleting a service account that workflows still depend on is blocked, but disabling one that they actively use stops their runs at once. Confirm the dependent workflows are handled before you disable or delete, so you do not silently halt scheduled or webhook-driven work.

How it fits the workflow ​

Service accounts have no purpose on their own — they exist to be attached to agentic workflows. When you define a workflow you choose the service account it runs as, and from that point every trigger for that workflow — Run now, webhook, or schedule — executes under that identity and inside its visibility scope. Give each engagement or customer its own service account with a tightly scoped group list, and a workflow can only ever touch the resources that belong to that engagement, however broad its instruction.