Customizing Policy¶

Rampart ships with standard.yaml — a policy that blocks dangerous commands and watches suspicious ones. When you need to adjust what's allowed or blocked, you don't have to edit YAML by hand.

rampart allow and rampart block add rules from the command line. They write to separate override files, hot-reload the daemon, and stay out of the way of future policy upgrades.

There are two important buckets to keep in mind:

• Policy rules in standard.yaml, product profiles like openclaw.yaml, and project policy files describe the default security model
• Durable human overrides created by commands like rampart allow --global ... are personal carve-outs and are stored separately from the built-in policy profiles

Allow a blocked command¶

If Rampart blocks something it shouldn't, unblock it:

rampart allow "npm install *"

Output:

  Adding rule to global policy (~/.rampart/policies/user-overrides.yaml):

    Action:  allow
    Pattern: npm install *
    Tool:    exec

  Add this rule? [y/N] y

  ✓ Rule added to user-overrides.yaml

    Action:  allow
    Pattern: npm install *
    Tool:    exec

  Policy reloaded (26 rules active)

The rule takes effect immediately. No restart needed.

Skip the confirmation prompt¶

rampart allow "npm install *" --yes
# or
rampart allow "npm install *" -y

Useful examples¶

# Development package managers
rampart allow "npm install *"
rampart allow "yarn add *"
rampart allow "pip install *"
rampart allow "go get *"
rampart allow "cargo add *"

# Git operations
rampart allow "git push origin *"
rampart allow "git fetch *"

# Test runners
rampart allow "go test ./..."
rampart allow "pytest *"

# Build tools
rampart allow "make *"
rampart allow "docker build *"

# Read a specific directory
rampart allow "/tmp/**" --tool read

# Write to a build directory
rampart allow "$(pwd)/dist/**" --tool write

Block an additional command¶

rampart block "npm publish *"
rampart block "curl * | bash"
rampart block "pip install --index-url *"  # block custom PyPI mirrors

Block rules use the same flags as allow:

rampart block "npm publish *" --yes --message "Publishing requires human review"

Pattern auto-detection¶

Rampart automatically classifies patterns as path-based or command-based:

Override with --tool:

rampart allow "/var/log/**" --tool read    # read only
rampart allow "/tmp/build/**" --tool write # write only
rampart allow "docker exec *" --tool exec  # force exec (not path)

Valid --tool values: exec, read, write, edit

Rule scopes: global vs project¶

Rules live in one of two files:

Rampart auto-detects your scope by looking for a .git directory. Force it explicitly:

rampart allow "npm install *" --global   # always global
rampart allow "npm install *" --project  # always project (.rampart/policy.yaml)

Project-scoped rules (team sharing)¶

Project rules travel with the repo. Commit .rampart/policy.yaml to share allow/block rules with your team:

# In your project root
rampart allow "npm install *" --project
rampart allow "yarn build" --project
git add .rampart/policy.yaml
git commit -m "chore: add rampart project rules"

When a teammate clones the repo, rampart serve picks up the project rules automatically.

Global rules (personal overrides)¶

Global rules apply everywhere on your machine regardless of which project you're working in. Use them for personal workflow preferences:

rampart allow "gh pr create *" --global
rampart allow "brew install *" --global

List your override rules¶

rampart rules

  Custom Rules
  ──────────────────────────────────────────────────────────────

  Global  (~/.rampart/policies/user-overrides.yaml)

  #     ACTION   TOOL      PATTERN                              ADDED
     1  allow    exec      npm install *                        2 hours ago
     2  allow    exec      go test ./...                        1 day ago
     3  deny     exec      npm publish *                        3 days ago

  Project  (.rampart/policy.yaml)

  #     ACTION   TOOL      PATTERN                              ADDED
     4  allow    exec      make build                           1 week ago

  ──────────────────────────────────────────────────────────────
  Total: 30 rules (26 standard + 4 overrides)
  Manage: rampart rules remove <#>

Filter by scope:

rampart rules --global    # global rules only
rampart rules --project   # project rules only

JSON output for scripting:

rampart rules --json

[
  {
    "index": 1,
    "source": "global",
    "action": "allow",
    "tool": "exec",
    "pattern": "npm install *",
    "added_at": "2026-02-24T06:00:00Z"
  }
]

Remove a rule¶

rampart rules remove 3    # remove rule #3 from the list

Use --force to skip the confirmation prompt:

rampart rules remove 3 --force

Reset all override rules¶

rampart rules reset

This removes every rule added via rampart allow and rampart block — both global and project — and leaves the standard policy untouched.

rampart rules reset --force   # skip confirmation

Add a reason for a rule¶

The --message flag sets the text displayed when the rule matches or fires a denial:

rampart allow "npm install *" --message "Allowed: frontend dependencies during dev"
rampart block "npm publish *" --message "Publishing to npm requires manual review"

Messages appear in rampart watch and the audit log.

Manually editing override files¶

Both scope files are plain Rampart policy YAML. Open them in an editor to batch-add rules or fine-tune conditions:

# ~/.rampart/policies/user-overrides.yaml
# Rampart user overrides — managed by `rampart allow` / `rampart block`.
# You can edit this file manually. Changes take effect on reload.

version: "1"
policies:
  - name: custom-allow-commands
    match:
      tool: [exec]
    rules:
      - action: allow
        when:
          command_matches:
            - "npm install *"
            - "yarn add *"
            - "go test ./..."
        message: "User-allowed dev tools"
        added: 2026-02-24T06:00:00Z

  - name: custom-allow-paths
    match:
      tool: [read, write, edit]
    rules:
      - action: allow
        when:
          path_matches:
            - "/tmp/**"
            - "~/projects/**"
        message: "User-allowed project paths"
        added: 2026-02-24T06:00:00Z

Changes hot-reload automatically. Or trigger a reload manually:

curl -X POST http://localhost:9090/v1/policy/reload \
  -H "Authorization: Bearer $(rampart token)" \
  -H "Content-Type: application/json" \
  -d '{}'

Denial hints¶

When Rampart blocks a tool call, the error message includes a ready-to-run rampart allow command:

Rampart: denied — command_matches "curl * | bash" (block-exfil)

To allow this command, run:
  rampart allow "curl https://api.example.com/data"
  rampart allow "curl *"   # allows any curl command

The agent sees this message and can surface it to you. Copy-paste the command to unblock.

Safe wildcard suggestions are generated automatically. Wildcards are not suggested for:

• Destructive commands (rm, shred, dd, mkfs, etc.)
• Sensitive paths (/etc/, ~/.ssh/, *.pem, etc.)

Self-modification protection¶

rampart allow, rampart block, and rampart rules are blocked when run by an AI agent. The standard policy includes:

- name: block-self-modification
  description: "Prevent AI agents from modifying their own Rampart policy"
  match:
    tool: ["exec"]
  rules:
    # Substring matching catches ALL wrapper bypasses (bash -c, sh -c, etc.)
    - action: deny
      when:
        command_contains:
          - "rampart allow"
          - "rampart block"
          - "rampart rules"
          - "rampart policy generate"
          - "rampart init"
      message: "Policy modification commands must be run by a human, not an agent"

The command_contains approach is robust against shell wrapper bypasses — bash -c 'rampart allow ...' is caught because the substring "rampart allow" appears in the command.

This means:

• ✅ You can run rampart allow "npm install *" in your terminal
• ❌ Your agent cannot run rampart allow "npm install *" to unblock itself
• ✅ When your agent is denied and shows you the rampart allow hint, you run it

This keeps the security boundary intact. Agents can request permission by surfacing the denial hint; you decide whether to grant it.

Flags reference¶

rampart allow <pattern> / rampart block <pattern>¶

rampart rules¶

rampart rules remove <index>¶

rampart rules reset¶

Workflow: agent denied, you unblock it¶

1. Agent tries to run npm install typescript
2. Rampart denies it (matches block-npm-registry or similar)
3. Agent shows you: "Rampart denied. To allow: rampart allow "npm install *""
4. You run rampart allow "npm install *" in your terminal
5. Rampart hot-reloads. Agent retries — it goes through.

No restarts. No YAML editing. The rule is saved for future sessions.