Rampart

Open-source policy and approval control for AI agents.

Install · How it works · Integrations · Policies · Documentation

AI agents can edit files, run commands, call APIs, and ship code at machine speed. Harnesses provide their own permissions, sandboxes, and approval modes. Rampart adds operator-owned policies and a consistent audit trail across its supported integration boundaries.

It sits at supported hooks, plugins, proxies, and process boundaries; evaluates the action against local policy; and returns allow, ask, or deny before the host executes it. Decisions are visible, approvals stay human-owned, and the result becomes part of a hash-chained audit trail.

Agent proposes an action
          │
          ▼
   ┌─────────────┐
   │   Rampart   │  policy · approval · audit
   └──────┬──────┘
          │
      allow / ask / deny
          │
          ▼
Host executes — or does not

Rampart is a security boundary, not a sandbox. It sees actions exposed by the configured integration; it does not see arbitrary syscalls or network traffic inside a process you already allowed. Start with the threat model when deciding where to rely on it.

Install

brew install peg/tap/rampart

rampart protect
rampart verify --all
rampart watch

That is the normal path:

1. protect detects supported installed agents and configures their managed boundaries.
2. verify --all runs fixed, non-executing canaries without invoking a model.
3. watch shows decisions as they happen.

curl -fsSL https://rampart.sh/install | bash

irm https://rampart.sh/install.ps1 | iex

go install github.com/peg/rampart/cmd/rampart@latest

Why Rampart

How it works

Every integration has a concrete observation boundary. Rampart normalizes the action visible there. When a supported adapter receives multiple represented targets, it evaluates each one and lets the most restrictive decision win.

ALLOW  exec  npm test                         [allow-dev]
DENY   read  ~/.ssh/id_ed25519                [block-credentials]
ASK    exec  kubectl apply -f production.yaml [approve-production]
DENY   resp  tool output contained a secret   [scan-response]

rampart status separates configuration from evidence:

• HOST VERIFIED means an active safe verifier reached the installed host boundary.
• ADAPTER VERIFIED means Rampart proved its installed configuration and adapter behavior, not authenticated host ingestion.
• Experimental and static-only integrations stay labeled as such.

Verification receipts contain outcomes and fingerprints—not prompts, commands, credentials, host output, or agent memory.

Integrations

rampart protect openclaw
rampart setup claude-code
rampart setup codex
rampart setup cline
rampart setup antigravity
rampart setup copilot
rampart setup cursor

Experimental integrations are explicit opt-ins and stay outside bare rampart protect auto-detection:

rampart setup hermes
rampart setup gemini

See the support matrix for platform coverage, verifier strength, and known host-owned limitations.

A policy you can read

Rampart policies are YAML, local, and hot-reloaded:

version: "1"
default_action: allow

policies:
  - name: block-credential-reads
    match:
      tool: [read]
    rules:
      - action: deny
        when:
          path_matches:
            - "**/.ssh/id_*"
            - "**/.aws/credentials"
            - "**/.env"
        message: "Credential access blocked"

  - name: approve-production
    match:
      tool: [exec]
    rules:
      - action: ask
        when:
          command_matches:
            - "kubectl apply *"
            - "terraform apply *"
        message: "Production change requires approval"

For common cases, you do not need to edit YAML:

rampart allow "npm install *"
rampart block "curl * | bash"
rampart rules
rampart test "rm -rf /"

Project-specific policy can live with the code:

rampart init --project

That creates .rampart/policy.yaml. Set RAMPART_NO_PROJECT_POLICY=1 when working in a repository whose policy you do not trust.

Policy guide → · Policy schema → · Community policies →

Approvals without prompt fatigue

An ask rule requires human review of the action that matched. The integration determines where that review appears and whether it can resume the call. Paths without an approval resolver block the request.

For integrations using Rampart's approval queue, review and resolve requests through its dashboard or CLI:

rampart pending --details
rampart approve <id>
rampart deny <id>

The OpenClaw native plugin offers allow-once and deny in OpenClaw's own UI; those requests do not also appear in Rampart's queue. Persistent allowances require explicit operator policy. Compatible Hermes installations likewise use host-owned approval and resume. Standalone rampart mcp currently blocks ask requests; starting rampart serve does not connect a resolver to that proxy.

See the approval paths and limits before choosing an integration.

Watch, verify, and audit

rampart status
rampart doctor
rampart verify --all
rampart audit tail --follow
rampart audit verify

Audit records are hash-chained and redact common credential shapes before normal persistence and display boundaries. They still contain operational metadata and command structure, so treat the owner-only audit directory as sensitive authorization state.

MCP and non-native agents

Proxy a command-launched MCP server:

rampart mcp -- npx @modelcontextprotocol/server-filesystem /path
rampart init --profile mcp-server

For an agent without native hooks:

rampart wrap -- your-agent
rampart preload -- your-agent

wrap is a cooperative $SHELL boundary and cannot intercept absolute shell paths or direct process APIs. preload covers compatible dynamically linked exec/spawn calls on Linux and non-SIP-protected macOS processes; static, setuid, direct-syscall, and SIP-protected paths remain outside that boundary.

MCP proxy → · Any CLI agent → · Threat model →

Releases

Use the latest stable release and read the changelog for features, fixes, and upgrade notes.

Documentation

• Install and quick start
• Integration support matrix
• Security assurance model
• Configuration
• CLI reference
• API reference
• Threat model
• Upgrade guide

Contributing

Focused fixes, integration compatibility work, documentation improvements, and security hardening are welcome. Start with CONTRIBUTING.md.

Please report suspected vulnerabilities privately through SECURITY.md, not a public issue.

Companion project

Snare adds detective controls with canary credentials and paths. Rampart blocks; Snare catches.

License

Apache 2.0