Skip to main content

​
Policy Structure

This page documents the top-level structure of Rampart policy files, including version, default action, notifications, and policy organization.

​
Schema Overview

Every Rampart policy file follows this structure: 
version: "1"
default_action: allow
notify:
  url: "https://..."
  platform: "auto"
  on: ["deny"]
policies:
  - name: my-policy
    # ...

​
Top-Level Fields

​
version
string
required
Schema version. Always "1". Required for all policy files.
version: "1"
​
default_action
string
required
Default decision when no policy matches. Must be "allow" or "deny".
  • allow - Permit unmatched tool calls (recommended for most use cases)
  • deny - Block unmatched tool calls (paranoid mode)
default_action: allow
When using project policies (.rampart/policy.yaml), the global policy’s default_action always takes precedence. Project policies can only add restrictions, not weaken security.
​
policies
array
required
List of policy objects. Each policy contains match conditions and rules. See Match Conditions for details.
policies:
  - name: block-destructive
    match:
      tool: ["exec"]
    rules:
      - action: deny
        when:
          command_matches: ["rm -rf /"]
        message: "Destructive command blocked"
​
notify
object
Optional webhook notification configuration. Send alerts to Slack, Discord, Teams, or custom endpoints when policies trigger.

​
Complete Example

version: "1"
default_action: allow

notify:
  url: "https://discord.com/api/webhooks/your/webhook"
  on: ["deny"]

policies:
  # Block destructive commands
  - name: block-destructive
    priority: 1
    match:
      tool: ["exec"]
    rules:
      - action: deny
        when:
          command_matches:
            - "rm -rf /"
            - "rm -rf ~"
            - "mkfs*"
        message: "Destructive command blocked"

  # Protect credentials
  - name: block-credential-reads
    priority: 1
    match:
      tool: ["read"]
    rules:
      - action: deny
        when:
          path_matches:
            - "**/.ssh/id_*"
            - "**/.aws/credentials"
          path_not_matches:
            - "**/*.pub"
        message: "Credential access blocked"

  # Block exfiltration domains
  - name: block-exfil
    priority: 2
    match:
      tool: ["fetch"]
    rules:
      - action: deny
        when:
          domain_matches:
            - "*.ngrok-free.app"
            - "webhook.site"
        message: "Exfiltration domain blocked"

  # Require approval for deployments
  - name: approve-deploys
    match:
      tool: ["exec"]
    rules:
      - action: ask
        when:
          command_matches: ["kubectl apply *"]
        message: "Deployment requires approval"

​
Validation Rules

​
Required Fields

  • version must be present and set to "1"
  • default_action must be "allow" or "deny"
  • policies must be a non-empty array

​
Constraints

  • Policy names must be unique within a file
  • Each policy must have at least one rule
  • If notify is present, it must include url and on
  • notify.on must contain at least one valid event type

​
Best Practices

Deny Always Wins

If any policy denies a tool call, the call is denied regardless of other policies. Use this for security-critical rules.

Priority Ordering

Policies with lower priority numbers are evaluated first. Default priority is 100. Use priority 1 for critical security rules.

First Match Wins

Within a policy, rules are evaluated top-to-bottom. The first matching rule determines the action. Order your rules from specific to general.

​
Profile Presets

Rampart includes built-in profiles with different security postures:
ProfileDefaultUse Case
standardallowBlock dangerous, watch suspicious, allow the rest
ciallowStrict mode for headless/CI - all approvals become denies
paranoiddenyExplicit allowlist for everything
yoloallowLog-only, no blocking
Initialize a profile: 
rampart init --profile standard
rampart init --profile paranoid
rampart init --profile ci

​
Project-Local Policies

Place .rampart/policy.yaml in any git repo to add project-specific rules on top of your global policy: 
mkdir -p .rampart
cat > .rampart/policy.yaml << 'EOF'
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"
EOF
Project policies can only add restrictions, not weaken global policy. The global default_action always wins.Set RAMPART_NO_PROJECT_POLICY=1 to skip project policy loading in untrusted repos.

​
Next Steps

Build docs developers (and LLMs) love

Get started for freeTalk to us