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. Their permission systems usually ask a different question: can this tool run?

Rampart asks: should this action run?

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 escalates only the action that matched. Depending on the integration, approval appears in the agent's native UI or in Rampart's CLI and dashboard.

rampart pending
rampart approve <id>
rampart deny <id>

OpenClaw can offer allow-once, allow-always, and deny on the original tool call. Compatible Hermes installations pause and resume that same call. Other integrations expose only the approval behavior their host can safely support; Rampart does not invent a second approval owner and call it equivalent.

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 →

What changed in 1.8

Rampart 1.8 adds a native local Cursor hook, separates approval of reviewed pending calls from explicit grants for future calls, and binds those grants to the requesting credential and run. It also gives approval state one live service owner and keeps native approvals compatible with Hermes v0.20.2.

Read the changelog for the full release 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