Skip to main content
Build and run

Execution Identity and Credentials

An automation needs two independent permissions before a connector call can succeed:

Written By Christopher Scaminaci

Last updated 6 days ago

An automation needs two independent permissions before a connector call can succeed:

  1. Its dedicated MCP client must be allowed to call that concrete tool.
  2. StackJack must resolve a valid connector credential whose vendor-side account is allowed to perform the operation.

Selecting a tool does not create a credential, and enrolling a credential does not grant a tool. Plan entitlement, the automation's allow/deny policy, dry-run/destructive-consent gates, and the connector account's own permissions all continue to apply.

Who can configure automations

Tenant owners and administrators can create, edit, bind, and enroll credentials for automations. An owner or administrator can grant an ordinary member Automation builder access from Team settings; that member can then configure automations and enroll service-account credentials but cannot grant the same permission to someone else.

Run-as binding has an additional anti-escalation check:

  • Anyone who can configure automations may bind an automation to their own identity.
  • Binding it to someone else requires Owner or Administrator.
  • An explicit member binding cannot target an identity with a higher role. For example, an administrator is not offered the primary owner as a member identity. The separate privileged This tenant (owner credential) fallback remains available to owners and administrators.
  • An ordinary granted member is therefore locked to self rather than inheriting the owner fallback.

Revoking a member's builder grant prevents future configuration changes; it does not pause or rewrite existing automations. Dedicated credentials enrolled earlier belong to the automation, not to the enroller's future membership state.

Choose the run-as identity

In the advanced builder, open Capabilities → Run as:

  • This tenant (owner credential) is the primary owner's create-flow default and remains an option for privileged builders. Tool calls resolve and are attributed under the workspace owner's connector identity. Co-owners and administrators default to self in the builder until they deliberately choose otherwise.
  • Selecting a member makes that member the execution identity. StackJack uses their live identity context for connector resolution and attribution.

When a member is selected, choose the missing-credential posture:

  • Strict (default and recommended) — if the member has no personal credential for a connector, that connector fails closed.
  • Mirror this member's connectors — if no personal credential exists, StackJack may use an eligible shared/owner credential. Eligibility still depends on the connector's authentication method and the member's effective role; enabling mirror is not a promise that every shared OAuth connection can be used.

Changing run-as identity affects subsequent launches after the configuration is saved. It does not copy another person's secret into the automation.

Enroll a credential for one automation

After the automation has been deployed once, Capabilities → Agent credentials lets an authorized builder enroll a service-account connection for a specific connector. Depending on the connector, this is either an OAuth service-account sign-in or a credential form.

An enrolled credential is bound to that automation and connector only:

  • Secret material is stored through Azure Key Vault; StackJack stores references, binding metadata, and health state rather than showing the secret again.
  • The Portal validates a new enrollment and shows negative health states such as Credential disabled or Credential invalid. The two are not the same: disabled stops the credential being used, while invalid is a health warning that does not stop it being tried.
  • Revoking it affects only this automation. Re-enrolling is the safe repair for an invalid or disabled service-account credential.
  • The person enrolling OAuth must sign in as the service account the automation should use. That vendor account's permissions become the automation's permissions.

This connector credential is not the same as the automation's dedicated MCP identity, and it is not the separate read-only execution credential used for fixed start/finish steps. It is also unrelated to Anthropic BYOK: BYOK selects the key/workspace for model execution, while connector credentials authorize calls into your MSP systems.

Credential resolution order

StackJack resolves a credential independently for each connector:

PrioritySourceBehavior
1Active credential bound to this automation and connectorAuthoritative. A binding that is missing or disabled cannot execute, and the run does not fall through to another credential. A binding marked invalid is still used: that badge reports health and never redirects the run.
2Personal credential of the selected run-as memberUsed only when no active automation binding claims that connector.
3Eligible shared/owner credentialConsidered only when the run-as posture permits fallback. Strict mode suppresses this tier.

The authoritative first tier is deliberate. Quietly falling back after a dedicated service account breaks least privilege and can make a failed credential appear healthy while writes execute as a more powerful person.

Allowed tools are evaluated separately

On every create or update, StackJack revalidates the automation's tool policy against the live catalog, plan entitlement, connector subscriptions, and feature gates. The resulting concrete names are stamped onto the automation's dedicated MCP client. A native-only automation receives an explicit empty connector-tool list, not unrestricted access.

Dry-run blocked attempts can appear under Proposed tool grants. Review the attempted arguments before applying anything. The server re-derives the current catalog when you apply, ignores stale/unknown/not-entitled requests, and requires the destructive-action acknowledgment when a proposed grant is destructive. A proposal never changes the credential resolution order above.

Inspect and audit the current posture

Tenant operators can inspect the execution posture without exposing secrets:

  • The builder's Run as summary names the selected identity and whether missing credentials fail closed or may fall back.
  • Agent credentials lists active per-connector enrollments, enrollment method/date, invalid or disabled health, and a revoke action.
  • Team settings show who has Automation builder access and flag active dedicated enrollments whose original enroller is no longer an active tenant member. The credential is retained for review; it is not automatically deleted.
  • Run details and support-coded errors distinguish tool-policy refusals, missing connector configuration, transient connector unavailability, and upstream authorization failures. Quote the code and run ID to support.
  • Run-as changes, access grants, credential bindings, and automation versions retain actor/time attribution. Secret values are not displayed in those records.

The optional full support-diagnostic consent is broader than this operator view: it can attach identity IDs, emails, credential validation errors, and recent tool errors containing payload or PII. Leave it off unless StackJack support needs that data for a specific incident.

Safe recovery

Use the narrowest repair that matches the failure:

  1. Tool not allowed or not entitled: correct the allow/deny policy or subscription. Do not change credentials to bypass a policy refusal.
  2. Dedicated credential invalid, disabled, or missing: an invalid-but-enabled row is still attempted, while a disabled or missing row fails closed. Re-enroll it, or explicitly revoke the binding if you intend to return that connector to run-as resolution. Enabling shared fallback does not bypass an active binding.
  3. Selected member lacks a credential: keep strict mode and add that member's credential, select a different eligible run-as identity, or deliberately opt into shared fallback after reviewing its privilege impact.
  4. Vendor returns 401/403: repair the credential or the service account's vendor-side permissions. Repeatedly retrying the run does not turn a stable authorization refusal into success.
  5. Transient secret/connector read failure: retry after the support-coded connector_unavailable condition clears; do not replace a healthy credential solely because Key Vault or the connector was temporarily unreachable.
  6. Fixed steps report a missing execution credential: re-sync the automation so StackJack can mint its separate read-only execution identity. Do not enroll a broader connector credential as a substitute.
  7. Run-as member left the tenant: an owner or administrator should bind the automation to an active eligible identity and review every dedicated enrollment from Team settings before the next production run.

Archive or pause the automation while repairing an identity issue that could otherwise write under the wrong account. Credential cleanup is manual and explicit; StackJack does not silently delete an automation's service-account credential because its original enroller left.