Guardrails

Guardrails let you set the rules your entire team operates under. They govern what agents can run, what they can access, and where they can deploy. Set guardrails once at the org level, and every session and agent inherits them automatically. The dashboard’s Guardrails page has six tabs, each controlling a different enforcement layer:

​

Allowlists

Bash allowlists control what shell commands agents can execute. Each rule matches a command string with a shell-glob pattern and assigns one of three dispositions: Rules are evaluated in priority order: deny rules win first, then ask, then allow. Anything not matched by any rule falls through to the org-level default policy (which itself can be allow, ask, or deny).

​

Examples

​

How enforcement works

When a session boots, Runtime installs a Claude Code PreToolUse hook that intercepts every bash command before execution. The hook evaluates the command against the org’s allowlist rules and either permits, blocks, or pauses for approval. This works at the VM level, not the application layer, so agents cannot bypass it. Rules can be scoped to all repos or specific ones, and personal or team scope.

​

API endpoints

Allowlist rules use type=allowlist_rule_v0. See the Skills API reference.

​

Hooks

Hooks are event-driven scripts that fire at specific points in the agent lifecycle. They let you run custom logic before or after tool calls, when prompts are submitted, when sessions start or end, and more.

​

Supported events

​

Tool-scoped hooks

For PreToolUse and PostToolUse, you can narrow the hook to fire only for specific tools:

• Bash - shell commands
• Read / Write / Edit - file operations
• WebFetch - HTTP requests
• TodoWrite - task list operations

​

What hooks can do

Each hook defines a command (a bash script) that runs when the event fires. The script receives context about the event and can:

• Log the event for audit purposes
• Block the action (for PreToolUse hooks)
• Modify the environment before the action proceeds
• Notify external systems (post to Slack, update a dashboard, etc.)

Hooks can be synchronous (block until the script finishes) or asynchronous (fire-and-forget for events that support it).

​

Scoping

Hooks can be scoped to personal or team, and attached to all repos or specific ones. Like other directives, each hook has exactly one live version; lock it to freeze edits.

​

API endpoints

Hooks use type=hook_v0. See the Skills API reference.

​

Network

Network rules restrict which hosts and IP ranges the sandbox can reach on the network. This is enforced at the VM level, not the application layer, so agents cannot bypass it.

​

Rule types

​

Default behavior

By default, sandboxes have outbound access to the public internet (package registries, APIs, etc.). Network rules let you lock that down:

• Allowlist mode - only explicitly listed hosts and CIDRs are reachable
• Denylist mode - everything is reachable except explicitly blocked hosts

Use network rules when:

• Your org handles sensitive data and agents should only reach approved API hosts
• You want to prevent agents from contacting arbitrary external services
• Compliance requires restricting egress to a known set of endpoints

​

API endpoints

Network rules use type=network_rule_v0. See the Skills API reference.

​

Approvals

Approvals add human-in-the-loop gates for sensitive operations. When an action requires approval, the agent pauses and waits for a team member to review and approve before proceeding. Approval workflows can be configured for:

• Production deploys - require admin sign-off before shipping to production
• Sensitive commands - flag specific bash patterns for manual review (via allowlist ask rules)
• Plan mode - agents generate a plan first and wait for approval before executing

Approvals integrate with the dashboard’s notification system so reviewers are alerted when something needs their attention.

​

RBAC

Role-based access control defines what each role in the organization can do: RBAC applies across every surface: dashboard, CLI, and API. API keys cannot exceed their owner’s role ceiling, even if the scope is requested. See Scopes for the full matrix.

​

Per-user controls

Beyond roles, admins can set per-user limits:

• Maximum concurrent sessions
• Monthly spend budgets
• Model restrictions (which LLMs the user’s agents can call)
• Deploy target restrictions (staging only, specific apps only)

See Org Limits.

​

Audit

Audit trails record every action taken by agents and users in the organization. Every prompt, file change, command, deploy, and cost event is captured with:

• Who - user id, email, role
• What - prompt text, files changed, commands run, tools called
• When - UTC timestamp
• How much - tokens consumed, dollars spent, compute time
• Where - session id, template, agent type

​

What gets logged

• Every prompt submitted
• Every tool call (bash, file read/write, search, etc.)
• Every file created, modified, or deleted
• Every git operation (clone, commit, push, PR)
• Every deploy (start, success, failure)
• Every session lifecycle event (create, pause, resume, destroy)
• Every API key creation, revocation, and usage
• Every guardrail enforcement (blocked command, hook fired, network rule hit)

​

Accessing audit data

• Dashboard - the Activity tab shows a real-time stream of events
• API - Team Events returns structured event data for export
• Metrics - Team Summary aggregates events into time-series data

See Observability for the full picture.

​

Putting it all together

A typical org configuration:

1. Allowlists - prevent destructive commands, gate production pushes, allow package installs
2. Hooks - log every tool call to your SIEM, block writes to protected config files
3. Network - restrict to package registries plus approved API hosts
4. Approvals - require admin sign-off for production deploys
5. RBAC - members can create sessions and deploy to staging; admins manage templates and secrets
6. Audit - weekly review by the security team, events exported to your data warehouse

With these in place, agents can move fast on routine work while the org stays in control of cost, security, and risk.

​

Related guides