Signed, versioned detection rules for Pipelock, the open-source agent firewall.
Pipelock ships with built-in DLP, injection, and tool-poison scanners. Rule bundles extend those defaults with patterns that ship on a faster cadence than the core binary. Bundles are Ed25519-signed, versioned, and additive: they add detections and never override or weaken a built-in one.
Any published bundle installs by name from the Pipelock registry at https://pipelab.org/rules/:
pipelock rules install <bundle>Published so far. Each is a separate block, because you almost certainly want one of them rather than both:
pipelock-community — credentials, prompt injection, and MCP tool poisoning.
pipelock rules install pipelock-communityhealthcare-phi-pii — PHI and PII for healthcare agents.
pipelock rules install healthcare-phi-piiThat is the whole install. Pipelock verifies the signature against the keyring compiled into its release binary before the bundle loads, so there is nothing further to check by hand.
Installing from a GitHub Release instead, verifying the signature yourself
Release assets are an alternate HTTPS source for anyone who would rather not depend on the registry, or who wants to check the signature independently before installing.
Each asset is prefixed with its bundle name, because a GitHub Release cannot hold two files called bundle.yaml. Repository releases use plain v* tags for packaging; each bundle keeps its own CalVer version, so a repository tag neither replaces nor synchronizes bundle versions.
Download the bundle, its detached signature, and the checksum file:
base=https://github.com/luckyPipewrench/pipelock-rules/releases/latest/download
curl -fsSLO "$base/pipelock-community-bundle.yaml"
curl -fsSLO "$base/pipelock-community-bundle.yaml.sig"
curl -fsSLO "$base/SHA256SUMS"
grep -E ' \./pipelock-community-bundle\.yaml(\.sig)?$' SHA256SUMS | sha256sum -c -Fetch the official public key and confirm it is the one this repository publishes:
mkdir -p verify/agents/pipelock-official
curl -fsSLo verify/agents/pipelock-official/id_ed25519.pub \
https://raw.githubusercontent.com/luckyPipewrench/pipelock-rules/main/.github/rules-official/pipelock-official.pub
printf '%s %s\n' d63673b9fb7546dd5f223dc8df3b39a51eb8298d914fc602ba75c5d22910dd9f \
verify/agents/pipelock-official/id_ed25519.pub | sha256sum -c -Check the signature, then install from the same URL:
pipelock verify pipelock-community-bundle.yaml \
--sig pipelock-community-bundle.yaml.sig \
--keystore verify --agent pipelock-official
pipelock rules install --source "$base/pipelock-community-bundle.yaml" pipelock-community--source takes any HTTPS URL. For a bundle you are still writing, use --path instead.
pipelock-community is the official community bundle: credential patterns for providers Pipelock does not cover by default, such as 1Password, Doppler, Pulumi, Shopify, and Vercel; prompt-injection techniques including non-English overrides; and MCP tool-description poisoning.
healthcare-phi-pii is a healthcare DLP bundle contributed by BGASoft, Inc. It covers the regex-detectable entries from HIPAA Safe Harbor's 18 identifiers, financial PII, and clinical laboratory identifiers.
The rule catalog lists every rule in every published bundle, with its severity and primary source where present. make diagrams generates it from the compiled bundles, and make check-diagrams detects a committed catalog that no longer matches them.
Stable rules are enabled by default. Experimental rules aren't: they need true-positive fixtures but may lack false-positive ones, so they can fire on traffic you consider benign. Enable them when you want to include those rules:
rules:
include_experimental: true
Fixture tests require each rule to match its true-positive examples and, for stable rules, to reject its false-positive examples. Fixtures can't cover every input, so review also considers traffic they don't represent.
A rule is a small YAML file: an identifier, what it detects, how severe a match is, the field it reads, and an RE2-compatible pattern. Next to it live the fixtures, one test string per line, that decide whether it is allowed to ship.
Official bundles are verified against the keyring compiled into Pipelock release binaries. Third-party bundles are verified against keys you list in trusted_keys. Installing writes a bundle.lock recording what you actually got.
Anyone can publish a bundle. Security teams write internal ones for company-specific credentials; researchers publish them for new attack patterns. Three rule types are supported:
| Type | type value |
What it detects |
|---|---|---|
| DLP | dlp |
Credentials and secrets in outbound traffic |
| Injection | injection |
Prompt injection in fetched content and tool responses |
| Tool-poison | tool-poison |
Hidden instructions in MCP tool descriptions |
# Install a third-party bundle from an HTTPS URL
pipelock rules install --source https://example.com/bundles/acme-rules/bundle.yaml acme-rules
# Install from a local path while you are still writing it
pipelock rules install --path ./my-bundle/ --allow-unsigned
# List what's installed
pipelock rules listSee the full bundle authoring guide for the YAML schema, signing, distribution, and trust model.
CI tests each maintained bundle with the declared min_pipelock release and with a Pipelock build that reports the tested_through_pipelock version recorded in compatibility/contract.yaml. The matrix doesn't individually test every version between those endpoints. A newer Pipelock version is outside this repository's recorded tested range. The compatibility contract records that range; it doesn't establish whether the running Pipelock version emits a warning about it.
The contract binds each published bundle's name, CalVer, minimum version, and format_version to a SHA-256-pinned reader-schema identity. The two bundles named in the contract add detections. They don't carry per-rule allow or block actions, and they can't replace built-in patterns. Format 1 has no monotonic rollback counter. The installer refuses a same-version digest change.
Run make check-compatibility to check that binding and exercise the installer with two pinned bundles, one format-1 optional-field fixture, and four negative cases: same-version digest change, unsupported format, too-new minimum, and unknown reader field. make preflight includes the check.
# Compile individual rule files into a single bundle
make compile
# Compile a specific bundle
BUNDLE_NAME=healthcare-phi-pii make compile
# Validate the compiled bundle against the Pipelock schema
make validate
# Run every regex against its true and false positive fixtures
make test-fixtures
# Re-render the README diagrams and the rule catalog from the live bundles
make diagrams
# Check diagrams, brand assets, compatibility, validation and fixtures for every maintained bundle
make preflightSee CONTRIBUTING.md for prerequisites and the complete rule-change sequence. Preflight needs the Pipelock version core recorded in compatibility/contract.yaml and doesn't download a CLI. Missing tools fail the check. YAML lint, published-signature verification and version-history checks run separately in CI.
rules/<bundle>/<type>/ One YAML file per rule
fixtures/<bundle>/<type>/ Lines that must match, and lines that must not
published/<bundle>/ The compiled bundle.yaml and its detached .sig
assets/ README diagrams, generated by scripts/render_diagrams.py
scripts/compile.sh Merges rule files into bundle.yaml
scripts/test-fixtures.sh Runs every regex against its fixtures
- What is an Agent Firewall?: how Pipelock scans agent traffic
- Community Rules: install guide and rule documentation
- MCP Tool Poisoning: why tool-poison rules exist
- Pipelock on GitHub
See CONTRIBUTING.md for how to add a rule. Every rule needs:
- An RE2-compatible regex (no lookahead, no backreferences)
- At least one true-positive fixture
- A primary source citation (stable rules)
- At least one false-positive fixture (stable rules)
Apache 2.0. See LICENSE.