Pipelock Detection Rules: Community Collection

Pipelock ships with 65 built-in DLP patterns and 29 response scanning patterns. Pipelock detection rules from the community extend that with additional patterns maintained outside the release cycle.

Install

pipelock rules install pipelock-community

That’s it. Pipelock downloads the signed bundle, verifies the Ed25519 signature against the keyring baked into the binary, and installs the rules to ~/.pipelock/rules/.

What’s Included

The pipelock-community bundle ships 28 rules across three categories:

DLP patterns (secret detection): 1Password service account tokens, Mapbox tokens, Cloudflare API tokens, PlanetScale passwords, Supabase keys, Linear API keys, Notion tokens, Airtable tokens, and more. These extend the 65 built-in patterns with provider-specific formats that change more frequently than the core release cycle.

MCP tool poisoning detection: Patterns that flag suspicious tool descriptions containing hidden instructions, data exfiltration commands, or prompt injection payloads. These scan the description field of MCP tool definitions for known attack patterns.

Response injection patterns: Additional prompt injection signatures for response scanning, covering techniques like invisible Unicode injection and cross-agent instruction leaking.

Managing Rules

pipelock rules list              # Show installed bundles
pipelock rules update            # Pull latest versions
pipelock rules verify            # Re-verify all signatures
pipelock rules diff              # Compare installed vs remote
pipelock rules remove <name>     # Uninstall a bundle

Pipelock v2.2.0 adds pipelock rules status, which gives you a single runtime view of the active rule tiers, bundle sources, signed state, and loaded counts:

pipelock rules status
pipelock rules status --json

What’s New in Recent Releases

Rule bundles now declare both a tier and a required_features list.

• Tier tells you whether a bundle is standard, community, or pro.
• Required features fail fast if the runtime is missing something the bundle depends on, such as dlp or checksum.
• Standard-tier overrides let operators point rules.standard_dlp_source and rules.standard_response_source at vetted bundles on disk.

This matters operationally because rules now fail closed with a clear error instead of silently loading into a runtime that cannot actually enforce them.

For v3.3 specifically, rule bundles that cannot prove compatibility no longer load implicitly. See the Pipelock v3.3 upgrade guide before upgrading a deployment that depends on external bundles.

How Rules Merge

Installed rules merge with your config at startup. If a community rule has the same name as a built-in pattern, the built-in takes precedence. You can override this in your config YAML:

dlp:
  include_defaults: true    # Keep built-in patterns (default)
  patterns:                 # Your custom patterns merge on top
    - name: "My Custom Key"
      regex: 'mykey_[a-z0-9]{32}'
      severity: critical

Community rules, built-in defaults, and your custom patterns all combine. Rules are deduplicated by name.

Trust Model

Every community bundle is signed with an Ed25519 key. The public key is compiled into the pipelock binary at build time, so signature verification requires no network access and no external trust store.

The signing key is held offline (USB-stored, encrypted). Bundles are CalVer versioned (2026.03.1) and include a SHA-256 integrity hash in the lock file after installation.

To install unsigned local rules (for development or private use):

pipelock rules install --path ./my-rules/ --allow-unsigned

Source

The rules source is on GitHub: luckyPipewrench/pipelock-rules. Contributions welcome. See CONTRIBUTING.md for the rule format and testing requirements.