Skip to main content
Utilities for managing, testing, and syncing Rampart security policies.

Usage

rampart policy <subcommand> [flags]

Subcommands

init

rampart init [flags]
Initialize a policy file from a built-in profile. Flags:
--profile
string
default:"standard"
Profile to use: standard, paranoid, ci, yolo, research-agent, or mcp-server
--project
boolean
default:"false"
Create .rampart/policy.yaml in current directory (project-specific rules)
--defaults
boolean
default:"false"
Reset to defaults (alias for --force)
Examples:
# Initialize with standard profile
rampart init --profile standard

# Paranoid mode (deny by default)
rampart init --profile paranoid

# CI mode (all approvals become denies)
rampart init --profile ci

# Create project policy
rampart init --project
Output:
✓ Policy written to ~/.rampart/policies/standard.yaml
  3 policies loaded, default action: allow
  Run 'rampart test' to verify

lint

rampart policy lint [file]
Validate policy YAML for syntax errors and warnings. Examples:
# Lint default policy
rampart policy lint

# Lint specific file
rampart policy lint custom.yaml
Output:
✓ Policy valid: 3 policies loaded

explain

rampart policy explain <command> [flags]
Explain how a command is evaluated against the loaded policy. Shows which rules match and why. Flags:
--tool
string
default:"exec"
Tool type: exec, read, write, fetch
--agent
string
default:"*"
Agent identity to evaluate
Examples:
# Explain command evaluation
rampart policy explain "rm -rf /"

# Explain with specific tool
rampart policy explain --tool read "/etc/shadow"

# Explain for specific agent
rampart policy explain --agent claude-code "git push"
Output:
Evaluating: exec "rm -rf /"
  Agent: * | Tool: exec

Matching policies:
  1. block-destructive (priority 1)
     -> Rule 1: DENY "Destructive command blocked"
        Matched: command_matches "rm -rf *"

Final decision: DENY
  Policy: block-destructive
  Message: Destructive command blocked

test

Alias for rampart test. See rampart test for details.

list

rampart policy list
Browse community policy registry. Shows available policies with descriptions and installation commands. Output:
Community Policies:

  python-dev
    Python development workflow (pytest, pip, venv)
    💻  rampart policy fetch python-dev

  docker
    Docker build and deployment rules
    💻  rampart policy fetch docker

  kubernetes
    Kubernetes operations (kubectl, helm)
    💻  rampart policy fetch kubernetes

fetch

rampart policy fetch <name>
Download and install a community policy from the registry. Examples:
# Install Python development policy
rampart policy fetch python-dev

# Install Docker policy
rampart policy fetch docker
Output:
Fetching policy: python-dev
  Downloading from registry...
  Verifying SHA256...
✓ Installed to ~/.rampart/policies/community-python-dev.yaml
  3 new rules loaded

remove

rampart policy remove <name>
Remove an installed community policy. Examples:
rampart policy remove python-dev
Output:
✓ Removed ~/.rampart/policies/community-python-dev.yaml

sync

rampart policy sync <git-url> [flags]
Sync policies from a git repository (team policy management). Flags:
--watch
boolean
default:"false"
Foreground polling mode (checks for updates every 5 minutes)
Examples:
# One-shot sync
rampart policy sync https://github.com/org/rampart-policies

# Continuous sync (foreground)
rampart policy sync https://github.com/org/rampart-policies --watch
Sync status:
# Check sync state
rampart policy sync status

# Stop watch process
rampart policy sync stop
Output:
✓ Cloned policies to ~/.rampart/policies/synced/
  5 policy files synced
  Last update: 2026-03-03 14:23:01 UTC

generate

rampart policy generate [flags]
Generate policy templates from common patterns. Flags:
--from-audit
string
Generate allowlist from audit trail
--deny-by-default
boolean
default:"false"
Generate deny-by-default policy
Examples:
# Generate allowlist from last 7 days of audit
rampart policy generate --from-audit ~/.rampart/audit

# Generate deny-by-default template
rampart policy generate --deny-by-default

Policy profiles

standard

Default profile. Blocks dangerous commands, watches suspicious activity, allows the rest.
  • Default action: allow
  • Use case: Daily development with protection
  • Policies: block-destructive, block-credential-reads, block-exfil, watch-sudo

paranoid

Explicit allowlist mode. Only explicitly allowed commands run.
  • Default action: deny
  • Use case: High-security environments, untrusted agents
  • Policies: allow-git, allow-dev-tools (must add more allowlist rules)

ci

Strict mode for headless/CI environments. All approvals become hard denies.
  • Default action: allow
  • Use case: CI pipelines, automated agents, non-interactive
  • Policies: Same as standard, but headless_only: true on all ask rules

yolo

Log-only mode. Nothing is blocked.
  • Default action: allow
  • Use case: Audit-only, learning phase, testing
  • Policies: All rules use action: watch

research-agent

Allows data collection and analysis tools while blocking destructive operations.
  • Default action: allow
  • Use case: Research, data science, analysis agents
  • Policies: Allow data tools, block destructive, block credential access

mcp-server

Deny-by-default for MCP servers. Only explicitly allowed tools run.
  • Default action: deny
  • Use case: MCP server protection
  • Policies: Generated from rampart mcp scan

Project policies

Project policies (.rampart/policy.yaml) add repo-specific rules on top of global policy:
# Create project policy
rampart init --project

# Edit .rampart/policy.yaml
vim .rampart/policy.yaml

# Commit to git
git add .rampart/policy.yaml
git commit -m "Add Rampart project policy"
Example project policy:
version: "1"
policies:
  - name: myapp-no-prod-migrations
    match:
      tool: exec
    rules:
      - action: deny
        when:
          command_matches: ["*migrate*--env=production*"]
        message: "Production migrations require human review"
Global policy always wins for:
  • default_action
  • Deny rules (project cannot weaken global denies)
Disable project policy:
export RAMPART_NO_PROJECT_POLICY=1

Policy evaluation

Rule order:
  1. Lower priority number = evaluated first
  2. First matching rule wins
  3. Deny always wins over allow
Actions:
  • deny - Block immediately
  • ask - Require human approval (native prompt or dashboard)
  • watch - Log but allow
  • allow - Allow without logging
  • webhook - Delegate decision to external service

Exit codes

  • 0 - Success
  • 1 - Policy error or validation failed

See also

Build docs developers (and LLMs) love