Guardrails and Safety Controls

Every automation runs inside a layered set of safety controls. This page describes each guardrail, what it protects against, and exactly how it behaves — so you can reason about what an automation can…

Written By Christopher Scaminaci

Last updated 3 days ago

Automations are generally enabled by default. StackJack can turn Automations off for a workspace; when off, automation pages and launches are unavailable. See Automation Availability.

An automation cannot run until someone in your tenant has explicitly accepted the consent acknowledgment for it. Attempting to run an unconsented automation is rejected with a clear reason. Consent can be granted at any time but not withdrawn — if you no longer want an automation to be runnable, archive it.

Tool policy and execution identity

Every automation receives a dedicated MCP client identity (MCP — Model Context Protocol, the standard through which the agent calls connectors). Its callable connector tools come from one of two explicit policies:

Allow-list (the default) exposes only the concrete tools you select.
Deny-list exposes the tenant's currently entitled, credentialed tools except the concrete tools you block. Because that set expands with entitlements, it is broader and more expensive; use it only when that behavior is intentional.

The policy is revalidated against the live catalog on create and update. A native-only automation receives a concrete empty connector-tool list, never an unrestricted null list. Required tools and advisory chains do not grant access.

Tool authorization and credential selection are separate. Run as selects a member identity (or owner fallback), while an enrolled per-automation connector credential takes priority for its connector. An active dedicated binding remains authoritative: a missing or disabled binding cannot fall through to a person's credential, while a binding marked invalid is still used, because that badge reports health rather than eligibility. See Execution Identity and Credentials.

Native AI capabilities

Web search, web fetch, and code execution are Anthropic-native capabilities configured per automation. They run on Anthropic's side, never pass through your connectors, and are not plan-gated.

Dry-run mode

Dry-run mode prevents an automation from changing your stack while still showing you what it would have done. There is exactly one exception, and you need to know it before you test: if the automation also has Live approval in test runs switched on, a destructive call pauses for your decision — and approving it runs the tool for real against your live systems. See Live approval below. With live approval off, no write a dry run proposes ever reaches your connectors.

Write and destructive tools are blocked at execution, not hidden. The agent still discovers its full tool list and is explicitly instructed to call write tools as it normally would. The call is refused before it reaches your connector, and the attempt — tool name and arguments — is recorded in the run's transcript as a “would have called” entry for you to review. The single exception is a destructive call you personally approve in a supervised test run, which executes.
Read-only tools execute for real, so the agent works from your live data and its reasoning is representative.
A "this is a DRY RUN" instruction is injected into every kickoff message, telling the agent not to avoid a write tool just because dry-run mode is on — otherwise you would only ever see the calls it was willing to make.
When you're satisfied with its behavior, click Promote to Production on the automation's page to switch dry-run off (a confirmation is shown). Promoting lets the already-visible write tools execute normally, with no per-call pause. Promotion is refused while a test run of the automation is still in progress — running, waiting for an approval, queued, or still stopping after a cancel — so let it finish or cancel it first. Restoring an earlier version that is not in dry-run mode onto an automation that is follows the same rule. A test run keeps its dry-run behavior until it ends.

Template-installed automations default to dry-run so you always evaluate before granting write access. A Curated template — one StackJack publishes — is allowed to set its own starting value, so its install step can open with dry run already off and tells you when it does; every other template starts in dry-run mode whatever its author chose. See Using Automation Templates.

The current Guardrails & Deploy section showing runtime and credit caps, consent controls, and the configuration sidecar

The current element-only Guardrails & Deploy view shows caps and consent before deployment; promotion happens later from the saved automation's detail page.

Runtime and spend caps

Two per-automation ceilings bound every run:

Cap	Range	Default	Behavior at the cap
Max runtime	30 – 3,600 seconds	300 s	The run is stopped at once and ends as `TimedOut`, and its agent session is shut down; the agent is not asked to wrap up first. A hard wall-clock backstop also stops the run even if the agent stops responding, and the platform enforces its own absolute ceiling on any single run.
Max credits per run	0.01 – 500 credits	50	On managed-key runs, the run is stopped at once and ends as `CreditExhausted`, with no wrap-up turn. The credits the run used are charged, including the model turn that crossed the cap. If the platform restarts while a run is in progress, the run can go further past the cap before the check resumes, and it is charged for the credits it used. BYOK runs skip credit metering, so this cap does not apply there.

Both are validated server-side, so no client can create an automation outside these bounds.

An optional Max tool result size adds a per-automation ceiling of 10,000–5,000,000 characters for a single result. A larger result is refused as a tool error the automation can handle; StackJack never silently truncates it and lets the model reason over an incomplete payload. Blank uses the platform ceiling.

For an existing automation, Return raw tool responses opts out of organization-level response shaping. Off follows the organization's shaping rules; on returns the connector's raw response. It cannot enable shaping for an organization that has none configured.

Outbound network access

Every automation runs in its own hosted execution environment, and Outbound network access in the builder's Guardrails & Deploy section decides what that environment may reach on the internet. Four choices:

Choice	What the run may reach
Platform default	StackJack's MCP server only. This is what an automation gets when nobody has changed the setting.
No network access	Nothing on the open internet, unless you also switch on package managers below.
Only the hosts I list	The hostnames you list, plus package managers if you switch them on. At least one host is required.
Unrestricted	Any address the environment can route to. Choose it only when you cannot list the hosts.

The automation's StackJack tools keep working in every choice, including No network access. Connector calls travel through StackJack's MCP server rather than out of the environment, so narrowing this setting does not remove the automation's tools.

Allow package managers is a separate switch, offered under No network access and Only the hosts I list. On, the run may also reach the public package registries (npm, PyPI and similar). It only helps an automation that runs code; leave it off otherwise.

Listing hosts

Enter one hostname per line, the name only: hooks.slack.com, not https://hooks.slack.com/services/.... StackJack refuses the entry and names it in the save error if it carries a scheme, a path, a query string, a fragment, credentials, a port, a wildcard, an IP address, or a space. A refused host is never silently dropped from the list. Up to 50 hosts.

Anthropic matches an allowed host exactly, so list each hostname the automation needs rather than a pattern. Names that only resolve inside a private network — .local, .internal, .lan, .corp, .private, home.arpa, localhost and similar — are refused at save time, because a hosted run cannot reach an address inside your own network. Duplicate entries collapse to one.

What this setting is not

This controls the execution environment's own outbound reach. It is separate from:

Native AI capabilities. Web search, web fetch, and code execution run on Anthropic's side and are enabled per automation in their own control. They are not governed by this setting.
Connector tools. What your automation may call in your MSP stack is decided by its tool policy and its credentials, not by this setting.

When a change takes effect

Saving a new network choice replaces the automation's execution environment and applies to sessions that start after the save. A run already under way keeps the environment it started in. Tightening the setting while a run is in flight does not narrow what that run can reach; stop the run if you need the change to apply immediately.

If the stored setting ever becomes unreadable, the builder says so and shows the platform default rather than the stored value — and warns that saving from that state resets the setting to whatever is selected. Choose the option you want before you save.

Live approval

The approval flow is a supervised test run: an automation with Live approval in test runs enabled and dry-run mode on will pause on each destructive tool call, moving the run to AwaitingInput until you approve or deny it from the run detail page. Read and ordinary write tools are not paused, so a test run stays quick.

Approving a supervised test call

Approving runs the tool for real, against your live systems. This is the one place where dry-run mode does not protect you. A supervised test run is still a test run, but an approved call is not simulated — StackJack releases a destructive call of that tool through to your connector, and it counts against your plan's connector usage like any other call. Read the four points below before you approve one.

Check the target before you approve, not after. The run detail page shows you the tool and the arguments the agent proposed. Your approval releases exactly that call: the same tool with the same arguments, on that automation, while the run you approved is still running, within five minutes. A call of that tool with any other arguments stays simulated. Review what the call would do to which system, and approve only when you are willing for that change to happen.
Avoid overlapping runs of the same automation while an approval is open. If two runs of one automation are live at the same time, both use the same identity. If the other run sends the identical call — the same tool with the same arguments — before the approved run does, that call runs once and the approved run's own call is simulated. The effect is still the one you approved, once. Leave Allow this automation to run more than once at a time off on any automation you supervise, and wait for one run to finish before you start another.
Check the resulting change in the target system. The transcript records what StackJack released and what the connector answered. It is your evidence that the write landed, or that it did not — confirm the change in the system itself when it matters.
Approving one call does not promote the automation. The automation stays in dry-run mode, and the next destructive call pauses again. Promotion is a separate, deliberate action from the automation's detail page.

A destructive tool additionally requires this automation's destructive-action acknowledgment, so if that is missing the call is still blocked after you approve it. Denying it — or leaving it undecided until the deadline — keeps it unexecuted, and it is recorded as “would have called.” The Anthropic test run itself uses normal billing either way.

Production runs do not pause for approval. The Ask for approval again on production runs setting is saved with the automation, but production pausing is not available yet. For supervised test runs:

An eligible pause applies only to destructive calls; read and ordinary write calls continue.
Any run that hits a tool approval it is not eligible to pause for ends as Failed rather than waiting indefinitely.
After an unanswered approval reaches 60 minutes, cleanup stop-confirms the provider session. A confirmed stop lets the run end as Failed, bills usage already incurred, and refunds the unused reservation. If confirmation is uncertain, the run remains AwaitingInput and cleanup retries.

See Run lifecycle and statuses for the full pause-and-resume flow.

Concurrency and duplicate work

By default, one live run at a time is admitted for each automation. A second eligible asynchronous trigger waits in the durable queue rather than overlapping. Allow this automation to run more than once at a time deliberately opts out for workloads whose runs are independent.

Only one combination is refused at save time: an automation that allows concurrent runs cannot also declare an ordered tool chain or a duplicate-call-refusal (idempotent) step. Both read their state from the one live run behind the automation's MCP client, so with two runs live that state is read against the wrong one; the save is rejected with guidance to narrow the chain to required, which is evaluated after the run from the transcript. Postconditions are not part of that refusal.

Every other feature that wants one exact run is your judgment call, not a blocked configuration — the platform will let you save the combination:

Live approval still pauses, but with two runs live, an approval can apply to either run.
Fixture recording and chain enforcement need one run at a time. An automation that allows concurrent runs normally records nothing, and ordered/duplicate-call enforcement declines rather than enforcing against unreliable state.
Deny-list mode materializes its callable set from the live catalog per run, which two overlapping runs can resolve differently as entitlements change.

Leave concurrency off for any automation using those. One run at a time is the normal behavior, not a guarantee, so connector writes that must happen once still need their own idempotency or deduplication.

Stored data and test fixtures

Anthropic preserves the full session transcript, and StackJack fetches the complete conversation when you open the transcript viewer. StackJack does not copy that full transcript or full tool-result bodies into its database in your region. That statement is not a blanket promise that no run or customer data is retained: StackJack durably stores the filtered trigger payload, Anthropic session id and key provenance, final summary and error text, usage and cost, pending tool input while approval is required, transcript-derived tool names, bounded arguments, order and status, and safety outcomes. Treat those durable projections as run data even when you have not opened the full transcript. Other opt-in or authored surfaces intentionally retain content:

Knowledge: pasted text, fetched URL snapshots, extracted document text, metadata, and original uploaded files are stored for reuse on every run.
Memory: when enabled, model-written notes live in the automation's Anthropic memory store. StackJack stores the workspace/store mapping and mutation audit; the Portal can retrieve the notes for review, redaction, clearing, or hard deletion. The three removal actions are not equivalent — see Automation memory.
Fixture recording: when enabled from the detail page, StackJack records real tool calls for replay. Read responses are scrubbed, write responses are reduced to structural skeletons, and sensitive-response tools retain only a refused/signature form, but recordings can still contain customer data, and a non-JSON body is not field-scrubbed at all. The setting is read when a run starts, so turning recording off does not stop a run already under way; it applies to runs that start afterwards. A run that pauses for approval stops recording and does not resume it, and an automation that allows concurrent runs normally records nothing. Recordings have no automatic expiry. Contact support to delete them. See Creating an Automation with the Advanced Builder.
Support diagnostics: the optional full diagnostic bundle may include member/invite emails, identity IDs, credential validation errors, and recent error text containing payload or PII. The separate consent is off unless you enable it.

Treat knowledge, memory, fixtures, and full support diagnostics as explicit data-retention/egress decisions. They are not erased merely because transcript viewing is on demand.

Auditability

A normal save through the versioned configuration path creates an immutable, actor-attributed version snapshot. A dedicated consent-only fixture-recording update is the exception and does not create a version. Knowledge, consent, fixture recording, failure notifications, active state, and several other operational settings are outside that partial snapshot.
Every run records an AgentVersionId for partial attribution, who or what triggered it, and its cost accounting. That id covers the version snapshot's captured subset, not every input that shaped execution; queued and recovered runs can retain the original id while loading the current automation definition.
StackJack attempts a best-effort entry in the webhook receipt log for application-level deliveries. Receipt persistence failure does not replace the webhook response, so a missing receipt is not proof no request or run existed.
Runs started by StackJack staff on your behalf never charge your credits; the run detail page displays an information notice, and StackJack retains the staff attribution on the run.
Owners and administrators can manage Automation builder access for ordinary members from Team settings and review active agent-credential enrollments whose original enroller is no longer an active member. Revoking a member's builder grant does not stop existing automations.

Still need help? Ask the team

Consent