Core Engine

AI that respects
your boundaries.

Four layers of guardrails with locked rules and exemptions. Global security policies that cannot be overridden. Group-level inheritance for teams. Project-level customization. Per-job fine-tuning.

Request Access

Four layers of safety

ALL SCOPES

naming/branch: ai/*

Branch names must start with ai/

LOCKED

max_file_changes: 10

Overridable at lower scopes

content-pattern: no-console

Block console.log in all repos

LOCKED
TEAM GROUP

max_file_changes: 15

← overrides global (10)

no-public-rds: critical

New rule added at group scope

naming/branch

✕ cannot override — LOCKED

PROJECT SCOPE

max_file_changes: 20

← overrides group (15)

testing/min-coverage: 80%

Specific to this project

Effective rules this project

max_files:20 · no-console · ai/* branch

① Global rules defined — locked rules (branch naming, no-console) cannot be overridden anywhere
② Group overrides allowed — overridable rules (max file changes) can be relaxed per team
③ Project resolves effective set — most specific scope wins; locked rules always enforce

What guardrails can enforce

File Limits

Set maximum files an expert agent can change per job. Prevent sprawling, unreviewed modifications.

Line Limits

Cap the number of lines changed. Keep changes focused and reviewable.

Directory Restrictions

Block expert agents from specific directories entirely. Protect infrastructure, config, and sensitive paths.

Allowed Directories

Restrict expert agents to specific directories only. Ensure changes stay within scope.

Pattern Enforcement

Detect and reject forbidden code patterns using regex. Catch security anti-patterns automatically.

Naming Conventions

Enforce branch, commit, and merge request naming standards. Consistency without manual review.

Locked Rules

Mark critical global rules as locked. No group or project can exempt them. Security policies that cannot be overridden.

Explicit Exemptions

Groups and projects can exempt non-locked parent rules. Full audit trail of what was exempted and why.

How a rule fires

  Agent wants to edit `src/infra/terraform.tf`
                     │
                     ▼
             ┌───────────────┐
             │ Global rules  │  locked: "no hardcoded secrets"
             └───────┬───────┘
                     ▼
             ┌───────────────┐
             │ Group rules   │  "infra changes require approval"
             └───────┬───────┘
                     ▼
             ┌───────────────┐
             │ Project rules │  "block /infra/ in feature jobs"
             └───────┬───────┘
                     ▼
               ◆ DENY → notify author + dashboard banner
  1. 01

    Stack rules from four scopes

    Global, group, project, and per-job. Locked rules at the global level cannot be exempted, so a compliance policy survives every downstream customisation.

  2. 02

    Evaluate before the write

    Every tool call that would modify state passes through the engine first. Pattern checks, path restrictions, file/line limits, and naming rules all fire synchronously — nothing executes if a locked rule denies.

  3. 03

    Surface the denial, not a crash

    Denials become dashboard notifications with the rule, the scope, and an exemption link if the rule is non-locked. The audit trail records who exempted what and why.

Related features

Job PipelineProject GenomeSecurity

Test your guardrails before deploying

The Play Workbench lets you validate guardrail rules against real changes — before they go live.

Request Early Access