Skip to content
Gee-Code

Guardrails

Guardrails are immutable safety constraints that bound what a Gee can do. They’re the primary safety mechanism for autonomous modes — the hard fence that autonomous Gees cannot cross.

Structure

Section titled “Structure”

A guardrails configuration has four components:

Never/Always Rules

Section titled “Never/Always Rules”
{
  "never_do": [
    "Delete production databases",
    "Push to main without tests passing",
    "Send emails to external addresses"
  ],
  "always_do": [
    "Run tests before committing",
    "Log all file modifications",
    "Notify team channel on deployment"
  ]
}

These are injected directly into the AI’s system prompt as hard constraints.

Resource Limits

Section titled “Resource Limits”
{
  "resource_limits": {
    "max_api_calls_per_activation": 50,
    "max_files_written_per_activation": 10,
    "max_emails_per_activation": 3,
    "max_cost_usd_per_activation": 2.0,
    "max_cost_usd_per_day": 20.0,
    "max_activations_per_hour": 6,
    "skill_creation": {
      "max_per_activation": 2,
      "max_per_day": 10,
      "require_approval": true
    }
  }
}

Usage is tracked against these limits during execution. When a limit is hit, the action is blocked.

Permissions

Section titled “Permissions”

Control which components are available:

{
  "permissions": {
    "skills": { "mode": "exclude", "items": ["deploy"] },
    "tools": { "mode": "only", "items": ["Read", "Grep", "Glob", "Edit", "Write"] },
    "agents": { "mode": "only", "items": ["coder", "reviewer"] },
    "mcp_servers": { "mode": "none" }
  }
}
ModeBehavior
allEverything allowed
noneNothing allowed
onlyOnly listed items allowed
excludeEverything except listed items

Hash Integrity

Section titled “Hash Integrity”

Every guardrail file is protected by a SHA-256 hash:

~/.gee-code/modes/{mode-name}/guardrails.json
~/.gee-code/modes/{mode-name}/guardrails.hash

If the hash doesn’t match, the guardrails are considered tampered and the mode won’t activate autonomously.

Scope & Aggregation

Section titled “Scope & Aggregation”

Guardrails can be set at three levels:

Gee (mode-level)  ->  Team  ->  Endeavor

When a Gee activates, guardrails are aggregated:

  • never_do / always_do — merged. All rules from all scopes apply.
  • Resource limits — most restrictive value wins.
  • Permissions — intersected. Tightest allowed set wins.

Adding constraints at a higher scope only tightens, never loosens.

Enforcement

Section titled “Enforcement”

Before any tool call, the engine checks:

  1. Is this tool in the allowed permissions?
  2. Has a resource limit been hit?
  3. Does the action violate a never_do rule?

Protected Files

Section titled “Protected Files”

Certain files cannot be modified by autonomous Gees:

  • guardrails.json / guardrails.hash
  • mission.md / mission.hash

This prevents a Gee from weakening its own constraints.

Enforcement by Autonomy Level

Section titled “Enforcement by Autonomy Level”
LevelEnforcement
autonomousFull guardrail enforcement, no human override
semi-autonomousRead tools pass, write tools checked + need approval
supervisedSame as semi, in invoker’s context
noneNo guardrail enforcement (human is in control)

Managing Guardrails

Section titled “Managing Guardrails”
/guardrails              # View and edit guardrails
/guardrails edit         # Edit interactively

Design Philosophy

Section titled “Design Philosophy”
  1. User-controlled — only the human sets guardrails, never the AI
  2. Immutable during execution — cannot be modified mid-activation
  3. Tamper-evident — hash verification catches unauthorized changes
  4. Additive safety — higher scopes only tighten constraints
  5. Transparent — the AI sees exactly what constraints apply

Next Steps

Section titled “Next Steps”