Controls & Policy

Automations do real work — send messages, change records, spend money. Helix gives you three layers of control so they do exactly what you intend and nothing more: HITL approvals, guardrails, and budget caps.

Human-in-the-loop (HITL) & autonomy

You decide how much an automation can do on its own versus when it needs a person.

Mark any step HITL — before sending a reply, charging a card, or changing a record. When a run reaches that step, it pauses and shows as awaiting approval; a person reviews the context and approves or rejects from the product UI. Approve and the run continues past that step; reject and it stops there. See Human-in-the-loop for the step-level mechanics.
Set autonomy per action class, not just globally — Helix tracks a trust and autonomy level for each class of action (read-only lookups vs. consequential writes, for example), so you can let an automation run end-to-end for the low-stakes parts of its job while still requiring sign-off on the parts that matter. Higher autonomy means fewer pauses; lower autonomy inserts more human checkpoints.

HITL pauses are durable — a run can wait for sign-off for as long as it takes without losing its place.

Guardrails

Guardrails are rules that watch what an automation is about to do and can block it before it happens. Each guardrail is a plain-language rule with a scope — for example, “no merge or delete actions of any kind” scoped to your source-control connector — checked against every step’s action, regardless of what the step itself was configured to do. A guardrail that fires overrides the step, not the other way around.

Guardrails apply across the whole automation, so you can set a rule once and have every step in the pipeline respect it, without having to configure it on each one individually.

Scope a guardrail by outcome, not by a single tool. When you’re blocking a capability — “don’t read customer records”, “don’t post to Slack” — scope the rule to the connector or connector category rather than one specific tool. A connected integration usually exposes several tools that can reach the same result, so a rule pinned to just one of them can be sidestepped by another. Match the whole connector (or category) to reliably block the outcome; reserve single-tool rules for the cases where exactly one action is the thing you’re guarding against.

Budget caps

Every automation runs under a budget:

A cost cap, in dollars — as steps run, especially agent and action steps, Helix tracks the run’s real spend against this cap. When it’s reached, the run stops rather than continuing to spend.
A wall-clock cap — the maximum real-world time a run is allowed to take before it’s stopped, independent of cost. This is your backstop against a run that’s stuck waiting, looping, or otherwise not converging.

Both caps are enforced, not advisory: a run that would exceed either one stops rather than continuing. Set caps that match the value of the job, and raise them deliberately when you need to — this is what makes the cost and duration of a run predictable.

For workspace-wide cost visibility and controls, see Cost Controls.