Runtime — Guardrails

Your agent decides.
It does not execute.

Guardrails check every action your agent tries to call — before it executes. Verb risk level, your policy, and any conditions you define. If it violates policy, it never runs. No configuration required to start. Guardrails are always on.

100%

Actions checked before execution

3-tier

LOW · MEDIUM · HIGH risk

0-config

Required — guardrails fire from first call

API Docs → Get API Access

Execution flow

Every call goes through
the same check.

When your agent calls POST /v1/runtime/actions/run, guardrails fire before anything else. The verb is checked, the risk level is evaluated, your policy is applied. Only then does execution proceed.

01 — Agent calls an action

Your agent POSTs to /v1/runtime/actions/run with the verb and arguments. Nothing has executed yet.

02 — Risk level is checked

The verb is looked up in the catalog. Its risk level (LOW, MEDIUM, HIGH) is retrieved. HIGH-risk verbs are blocked unless an approval gate is configured.

03 — Policy is applied

Your tenant-level policies are evaluated. Match on verb name, risk level, provider, or conditions like argument values (e.g. refund amount > $100).

04 — Approved, blocked, or escalated

Approved actions execute. Blocked actions return a policy violation. Escalated actions wait for human approval before the execution path resumes.

pre-flight governance check

# Pre-flight before execution

POST /v1/runtime/governance/evaluate

X-API-Key: sk_live_...

{

"verb": "stripe:create_refund",

"args": {

"amount": 250,

"charge_id": "ch_abc123"

}

# Response

{

"decision": "require_approval",

"risk_level": "HIGH",

"reason": "Refund exceeds $100 threshold",

"policy_matched": "large-refund-gate"

}

Use /governance/evaluate for pre-flight

Call the evaluate endpoint before your agent commits to an action. Know whether it will be approved, blocked, or escalated — before the execution path begins.

Policy examples

Write the rule once.
It enforces on every call.

Policies match on verb, risk level, provider, or argument conditions. When a match fires, the action is approved, blocked, or escalated to a human. Your agent doesn't need to know the rules — the runtime enforces them.

example policy — large refund gate

// Block large refunds pending human approval

{

"verbMatchers": [{

"type": "verb",

"value": "stripe:create_refund"

}],

"conditions": [{

"field": "args.amount",

"operator": "greater",

"value": 100

}],

"action": {

"type": "require_approval"

}

Block all HIGH-risk verbs

"riskLevel": "HIGH" → "action": "block"

Require approval for order cancellations

"verb": "shopify:cancel_order" → "require_approval"

Notify on all writes to a specific provider

"provider": "stripe", "riskLevel": "MEDIUM" → "notify"

Allow all LOW-risk reads, no approval needed

"riskLevel": "LOW" → "action": "allow" (default)

Your agent decides.It does not execute.

Every call goes throughthe same check.

Write the rule once.It enforces on every call.

Policy enforced.From the first call.

Your agent decides.
It does not execute.

Every call goes through
the same check.

Write the rule once.
It enforces on every call.

Policy enforced.
From the first call.