Run As — Workflow Identity

By default every workflow runs under the identity of the workflow owner — the user who last saved a promoted version. Run As lets an org admin pin a specific service account as the executing identity instead. Service accounts are non-human machine identities with a declared set of capability scopes and an optional linked OAuth credential per integration product.

Why Run As?

Personal vs service account credentials

When an integration block resolves a credential, the access model depends on the account type:

If you connect a personal OAuth account (e.g. your own Google Workspace account) and the workflow's Run As is set to Workflow owner, that account is immediately available in any workspace you are a member of — every block in the workflow follows the run, so there is nothing further to configure on the block itself.

Service accounts require the extra wallet step described below, giving org admins explicit control over which credentials are active in each workspace.

Service account credentials (the wallet)

Before a service account can substitute for an OAuth user session you must link the OAuth account to it. Only organization admins can manage the wallet.

The wallet has no size limit: the Run As picker and the service account sheet read every linked credential, however many service accounts and products the organization has.

Configuring Run As on a workflow

Every block follows the run

A block does not name an account. There is one answer for who it acts as: whoever the run executes as. Click Run and every block in the workflow acts as you. Switch to Run as ▾ (a service account) and every block acts as that service account. Promote the workflow to an environment with its own Run As identity, and every block acts as that environment's identity when the schedule, webhook, or API trigger fires it.

There is no per-block override and no way to pin a block to a different account than the one the run is executing as. Instead of an Account field, each block shows a read-only Identity readout — who it will act as, and whether that identity currently has a working connection for the product.

The tools on an Agent block follow the run in exactly the same way. Every tool the Agent calls acts as the identity the run executes as, the same identity a standalone block in that workflow uses. Before an Agent run starts, Scrydon checks that this identity has a working connection for every extension tool the Agent may call: your own connection when you press Run, the service account's linked identity when the run is bound to one. The check asks exactly what the tool call will ask, so a run that passes it does not then fail on a different account. Your personal connections are never consulted for a service-account run, in either direction: they cannot satisfy the check, and their absence cannot fail it.

Knowledge searches follow the run too. A knowledge search, from a block or from an Agent's tool, searches as the run's identity and sees only what the lower of that identity's clearance and the workflow owner's clearance covers. When you press Run, that is your clearance. When the run is bound to a service account, it is the account's clearance, even though you started the run. The account also needs Knowledge (Read), and membership of the workspace when the knowledge base belongs to one.

Memory, files and knowledge bases follow the run in the same way. When the run is bound to a service account, these act as the account:

• conversation memory;
• reading and writing files in storage;
• reading and writing memex knowledge bases;
• creating a document, reading a document, and asking a knowledge base a question.

They are not limited by what you can do yourself.

• Permissions. The account needs the matching scope: chat:read / chat:write for memory, storage:read / storage:write for files, and knowledge:read / knowledge:write for knowledge bases. It must also be a member of the workflow's workspace.
• One environment. The account works only in the environment the run executes in. It is refused memory and knowledge bases in another environment, and files in another workspace or environment. Organization-wide files and knowledge bases need the scope only.
• Clearance. Knowledge bases are read at the account's own clearance, and a question is answered only from what that clearance covers. A page the account writes is labelled no higher than its own clearance.
• Ownership. Memory the account saves belongs to the account.

When the run is not bound to a service account, all of these act as you, as before.

Connections follow the run the same way. When a block or an Agent's tool calls an extension, the connection it uses is chosen with the clearance of the identity the run executes as: yours when you press Run, the service account's when the run is bound to one, even though you started the run. A connection rated above that clearance is not used.

Model calls follow the run too. When a knowledge base answers a question during the run, the model it asks is chosen with the same identity's clearance, exactly as for an Agent block. A process flow's AI works the same way: recommendations, generated drafts, follow-up questions, HITL advice, and the summaries a step makes of its inputs are made for the identity the step acts for. That is the person working the step, or the Run As account of a step nobody staffs. A model connection that requires a higher clearance is not used. A service account needs the capabilities:write scope for this, as it does for an Agent block. Without it, the call is refused, and it is never made as you instead.

Two kinds of background work act for no one: an instance's closing summary, and the extraction that runs when a document is ingested. They use only model connections that need no clearance.

A service account with no clearance can do none of this. Its calls to extensions, memory, files and knowledge bases are all refused, and none of them falls back to your clearance. Give the account a clearance before you bind a run to it.

Connect to run

Press Run and if any block in the workflow needs a connection your account does not have yet, a Connect to run dialog opens listing exactly those products. Connect them one at a time — each is a normal OAuth redirect that returns you to the editor — and the run starts itself the moment the list is clear. You never have to leave the run to go find a settings page.

Running as a service account

Consent is different when you are not the one being asked to grant it. Nobody can authorize an OAuth connection on a service account's behalf from the editor, so Run as ▾ a service account with a missing identity does not open a connect flow — it disables Run and points at the fix instead:

• An org admin sees Link identity, which opens the service account's identity panel directly.
• Anyone else sees Copy request (to hand to an admin) and Run as you instead, which switches the run back to your own identity.

There is no "run anyway." A service-account run with a missing identity does not start, and nothing silently falls back to a different account.

Workflows an extension installed

A workflow that an extension installs belongs to the extension, not to a person. When such a workflow creates a process-flow instance (the Drone Response ingest workflow does this for every new track), the instance's own steps, such as an Agent step that drafts an assessment, have nobody to act as of their own.

Those steps take the Run As of the workflow that created the instance. Set it once, on the installed workflow (Deploy → Execution settings). An instance copies the setting, and the clearance it was accredited at, when the instance is created:

• Instances created after you save the setting run as that account.
• Instances created before keep what they copied. Re-saving the setting does not reach them.
• Without a setting, the Agent step stops with "This run has no person to act as…" instead of calling Base Platform. Nothing falls back to another identity.

Updating or reinstalling the extension keeps the installed workflow's Run As.

The installed workflow's own steps run as that account too, and a service account acts with exactly the scopes it was given. Grant it what both workflows use: Tools (Write) for tool steps, such as Function, Table write, and Create process instance or task, and AI Capabilities (Write) for Agent steps.

An Agent step that nobody staffs also reads the documents it declares as inputs (for example, the operator's classification an assessment step works from) as that account. That read needs Knowledge (Read), and the account must be a member of the instance's workspace. It sees exactly the pages the account's own clearance covers, never more than the step's classification ceiling. Without either, the step still runs but reports its inputs as unreadable.

Promotion behavior

When you promote a workflow to a new environment:

• First promotion into that environment — Run As is seeded from the source workflow's setting. If you are not accredited for the source service account, the target is created with Workflow owner and a warning is shown in the Promote view.
• Accreditation is checked for the environment you are promoting into, not the one you are promoting from. An account scoped to prd is offered when you promote to Production, even though it is refused in Development.
• Subsequent promotions — the target environment's Run As binding is preserved unchanged. Promotion never overwrites it.

Every block automatically resolves against the target environment's Run As binding at execution time — since a block never stores an account, nothing needs rewriting on promote.

• A missing identity warns, it does not block. Promotion checks that each block's product is available in the target environment, not that the Run As identity has an account for it there — the admin who links that identity is often not the person promoting. The Promote view shows a readiness warning for the target environment and the button reads Promote with warning. The run itself fails closed: the first run in the target environment stops at the block whose identity is missing, and nothing falls back to another account.
• Legacy account pins are still checked. A block saved before blocks followed the run may still pin one specific account. Promotion checks that account against the target workspace's execution credentials and refuses when it is not assigned. The Promote view lists these blocks as a legacy pin; switch the block to run-as to follow the run's identity instead.
• A refused promotion names where to fix it. The Promote view names the target workspace and environment, and for a credential refusal links to that workspace's Execution credentials. Rollbacks from the version history report refusals the same way.

Execution attribution

The Runs table in the Monitor tab shows a Run As column for every execution. Possible values:

Audit logs record the actor type (user or service_account) and the service account ID on every run so compliance teams can identify non-human executions.

Troubleshooting

Workflow fails with RUN_AS_CREDENTIAL_MISSING — the service account's wallet does not contain a credential for the integration product the workflow tried to use. Open the SA detail sheet, add the missing linked credential, and re-run.

Agent block fails with AGENT_TOOL_CATALOG_UNAVAILABLE — an extension tool on the Agent block cannot run as the identity the run executes as, so the run is refused before the model is called. The message names each tool and the fix:

• "Link a <product> identity to this workflow's Run As service account…" — the service account has no identity on that product's connection for this environment. An org admin links one under Settings → Organization → Members → Service accounts. Connecting your own account does not help: a service-account run never uses it.
• "This workflow's Run As service account is not allowed to act in this workspace and environment…" — the account signed in, but its access policy does not cover where this workflow runs, so no product was ever checked. The reason in brackets says which half: environment_mismatch means the account is scoped to a different environment (an account scoped to prd cannot run a workflow in dev), and workspace_access_required means its workspace list leaves this workspace out. Linking a credential does not help. An org admin changes the account's workspace and environment access under Settings → Organization → Members → Service accounts, or you choose a different Run As identity.
• "Scrydon could not sign in as this workflow's Run As service account…" — no token could be issued for the service account, so no product was ever checked. Check that the account is enabled, and that it was created with a security clearance: only then does Scrydon hold the secret it signs in with. An account whose secret was rotated before 2026-09-21 is in this state too: rotate it once more under Settings → Organization → Service accounts to repair it, then give the new secret to anything else that uses the account, such as a CI/CD pipeline.
• "Base Platform could not confirm the Run As service account's <product> identity…" — the account signed in, but the check for that product did not get an answer. Retry in a moment.
• "Connect <product> before running the Agent." — the run executes as you, and you have no connection for that product. Use Connect on the tool's Identity readout.

Run fails with "This workflow's Run As service account now holds a wider clearance…" — the account's clearance was raised after it was bound to this workflow, so nobody has accredited the wider reach. Whoever may accredit the account at its current clearance re-saves the workflow's Run As setting under Deploy (or Versions, once deployed) → Execution settings; that re-accredits it and the runs resume. Lowering the account's clearance back also resolves it.

A knowledge base refuses to answer on a service-account run (llm_synthesis_refused) — the model calls behind the answer are made as the service account, and API Platform refused one. The response carries API Platform's status. Its platformCode says why:

• FORBIDDEN usually means the account lacks the capabilities:write scope. Grant it under Settings → Organization → Service accounts.
• POLICY_BLOCKED means a DLP or moderation policy blocked the request. reason names the policy.
• CAPABILITY_NOT_CONFIGURED means no model connection is available at the account's clearance.

Retrying does not help. llm_synthesis_unavailable (503) means only an outage, which a retry may outlast.

A process flow's AI says the AI service refused the request (llm_refused) — recommendations, generation, follow-up questions and HITL advice report API Platform's refusal with its status (403 or 422), platformCode and reason. The panel shows the refusal and offers no Try again, because a retry is refused the same way. Fix what platformCode names:

• FORBIDDEN: the identity the step acts for lacks the scope or clearance. A Run As account needs AI Capabilities (Write).
• POLICY_BLOCKED: a DLP or moderation policy blocked the request.

The same applies when the knowledge read behind recommendations was refused.

Selector shows "not accredited" — the service account's BLP clearance rank is lower than the knowledge base or document the workflow accesses. Increase the SA's clearance in Settings → Organization → Service accounts or reduce the document classification.

Selector shows the account is not allowed in this environment — the account's workspace and environment access does not cover the environment this workflow runs in. Change the account's access, or choose another identity. Linking credentials does not help: Scrydon refuses the account before any credential is looked up.

Agent step in a process flow fails with "This run has no person to act as…" — the instance was created by a workflow an extension installed, and that workflow has no Run As. Set one on the installed workflow (Deploy → Execution settings). It applies to instances created after you save it. See Workflows an extension installed.

A step fails with "The caller is not authorized for this platform operation" — the run executes as a service account that does not hold the scope that step needs. Tool steps need Tools (Write) and Agent steps need AI Capabilities (Write). An org admin adds them under Settings → Organization → Members → Service accounts, then re-runs.

An Agent step in a process flow reports its inputs as unreadable — nobody staffs the step, so it reads its declared inputs, and the context it picks up from the instance's knowledge base, as the Run As account, and that account cannot read them. Give the account Knowledge (Read), add it to the instance's workspace, and check that its clearance covers the documents. An account whose clearance belongs to a classification scheme your organization no longer uses reads nothing.

An unstaffed process-flow step runs without its Company Context briefing — the step reads its Company Context briefing as the Run As account too. The account needs Knowledge (Read), membership of the instance's workspace, and a clearance in your organization's active classification scheme at or above the action's context ceiling. Without any of these the action still runs, without the briefing, and the Prompt & Context panel shows the briefing as unavailable.

A knowledge search in a service-account run is refused, or finds less than you expect — the search runs as the service account, not as the person who started the run. The account needs Knowledge (Read), membership of the knowledge base's workspace, and a clearance in your organization's active classification scheme; without that clearance the search is refused. It then finds only documents within the lower of the account's clearance and the workflow owner's.

Save returns 403 — your own clearance level is below the service account's BLP rank. You can only bind a service account whose clearance is at or below your own. If nobody has set a clearance for you, you hold your organization's member baseline (INTERNAL unless your organization changed it), so you can bind an account at or below that. Contact your org admin to adjust the SA's clearance or your own.

Per-run override returns 403 — your account is not accredited to run this workflow as the chosen service account (same clearance rule as above).

OAuth token expired — an organization admin must reconnect the extension account under Settings → Platform → Extensions and re-link it in the SA credentials wallet.