Guardrails

In beta, on request. Guardrails are off by default and there is no setting to turn them on yourself. Ask us to enable them for your workspace.

A guardrail is a rule your workspace runs against a tool call. The rule is a script: it reads the call and returns a verdict, and a blocking rule refuses the call when the verdict is no.

Skilder enforces it, not the agent. An agent working under the rules never sees their coverage, script or publish state, so it cannot plan around them. It meets the effect: a refused call and the reason the rule wrote.

Two other agents do see guardrails. An admin's agent can read, write and test rules through the manage tool: see Author rules from your agent. Any member's agent can report decisions through analytics, within the calls that member can read: the rule's name, whether it was blocking or observing, and its reason.

Before you start

You have the admin role in this workspace. Members see every guardrail screen, read-only.
You know which calls you want to watch. Coverage is expressed in MCP servers, tool names, read or write, and roles.

Create the rule

Go to Guardrails, under Governance in the sidebar, and click New guardrail. Name it after what it protects, pick a language (Python, JavaScript, TypeScript or Bash) and click Create guardrail.

A new rule is switched off, set to Observing, and covers nothing. It decides nothing until you say otherwise.

Write the script

On the Rule tab, the script reads one JSON object on standard input and prints one back: {"ruling":"GO"} to let the call through, or {"ruling":"NO_GO","reason":"..."} to refuse it. The reason reaches the agent, so write one it can act on.

A TypeScript or JavaScript rule can import the helpers instead of writing the contract by hand. See Script SDK.

The runtime installs no dependencies in any language. Standard library only.

Say what it covers

On the Coverage tab, either choose Everything in this workspace, or pick Only calls that match conditions and fill in MCP servers, Tool name, Tool kind and Roles. Values inside one condition are alternatives; conditions are combined. Anything left as Any imposes nothing.

The preview lists the tools the rule reaches today, using the same evaluator the runtime runs. Coverage is an expression, not a list, so a tool added tomorrow is covered without an edit.

A rule with no coverage cannot be switched on. The Coverage column of the Guardrails list shows each rule's published reach: Not configured, Everything, or how many of the workspace's tools it covers.

Test it

Below the editor on the Rule tab, run the rule against a sample call and read the verdict, the raw output, the exit code and the duration. Nothing is recorded, and the tool itself is never called.

Publish, then switch it on

The script, the coverage, the mode and the phase are versioned. Your edits sit in a draft until you click Publish, exactly like a skill. The switch on the rule header is separate and takes effect at once.

Watch, then promote

Leave the rule Observing while you read what it decides on the rule's Activity tab, and across the workspace in Activity > Guardrails. When the numbers look right, click Make blocking. That is a publish, so it lands in the version history and you can Return to observing the same way.

On a rule's own Activity tab, each outcome figure counts only the calls that rule decided, while Evaluated counts every call it judged. In either feed, the rule that decided a call is set in bold. A note under the figures counts the calls no single rule can be credited with: calls recorded before decisions were credited per rule, and calls whose deciding rule has since been deleted.

Check it worked

A call a blocking rule turned down carries the Refused status in the Call Log, naming the rule and its reason. An observing rule records the same verdict and lets the call through.

Author rules from your agent

An admin's agent can write, test and switch rules through manage, which only workspace admins see. Publishing stays with you. Ask in plain language and the agent picks the operation.

Create a guardrail on write calls to zendesk that refuses any call deleting a ticket, then test it on a sample call.

Create. A new rule is published at once, switched off, Observing unless you ask otherwise, and covers nothing until you give it coverage.
Edit. Changes to the script, coverage, mode or phase go into the draft. manage cannot publish: you publish the draft in the app, or on the version card your agent displays when MCP Apps is enabled for your workspace.
Test. The agent runs the published rule or the draft against a sample call. Nothing is recorded and the tool is never called. The run does not check coverage, the switch, the configured phase or whether guardrails are on for the workspace, so it tells you what the rule would do to a call it covers.
Switch on or off. This acts on the published rule at once. Switching on is refused while the published version covers nothing.
Delete. Permanent, with the draft and the version history. Switch the rule off to stop it for a while.

Limits

Every rule covering one call shares a 3 second budget per phase. A rule that inspects arguments has no reason to run for seconds.
A blocking rule that fails to produce a verdict refuses the call. An empty script, a crash and a timeout all count.
Where several rules cover the same call, any refusal wins.

Read Activity, to see the calls a rule judged alongside everything else agents did.
Insights, to turn what you observe into better capabilities.