Every detection that ships in Harpax follows the same five-step lifecycle: observe a real-world attack pattern, model it as a structured rule, validate against captured sessions, ship it with a confidence score and false-positive notes, and tune it once it's in the wild.

Where the rules come from

Cambric's research sits at the intersection of three feeds:

  • Public threat research. Every built-in rule cites the public research that motivated it — OWASP's LLM Top 10, the LLM Prompt Injection Prevention Cheat Sheet, the Jailbreak-LLMs corpus, and academic work on memory-poisoning attacks like MemoryGraft. You can see the citations directly in each rule's references field.
  • Observed attack patterns. Captured Claude Code sessions — both internal red-team exercises and patterns reported by users — are the source for sequence rules (the ones that match across multiple events instead of a single line of text).
  • Tool ecosystem analysis. Scanning the MCP server and skill ecosystem surfaces dangerous primitives early. The skill_threats.yaml ruleset, for example, came from cataloguing the most common dangerous capabilities exposed by community skills.

The rule lifecycle

1. Observe

A pattern is identified — from public research, an incident report, or pattern-mining over captured sessions. At this stage the team writes a short threat description, the attacker's goal, and at least one concrete example.

2. Model

The pattern is encoded as a structured rule. Every rule carries metadata so it can be reviewed and reasoned about:

id: PI-001
title: Direct Prompt Injection - Ignore Instructions
description: Detects attempts to override system prompts...
author: Harpax
date: 2026-01-24
status: stable
references:
  - https://owasp.org/www-community/attacks/PromptInjection
  - https://cheatsheetseries.owasp.org/...
tags:
  - attack.llm01
  - attack.prompt_injection
level: high
falsepositives:
  - Legitimate discussions about AI security testing
  - Documentation examples showing attack patterns
detection:
  patterns:
    - pattern: 'ignore\s+(all\s+)?previous\s+instructions?'
      weight: 40
      case_sensitive: false
  condition: any
  min_confidence: 30
fields:
  - user_prompt
  - tool_input

The weight on each pattern and the min_confidence threshold for the rule are tuned together — the goal is to fire on real attacks without flagging legitimate discussion of those attacks. Known false-positive scenarios are documented up front, before the rule ever ships.

3. Validate

Before a rule ships as status: stable, it's run against a corpus of captured sessions covering both adversarial inputs (attacks the rule should catch) and benign inputs (conversations that mention security concepts but aren't attacks). Rules that produce too many false positives are reweighted or scoped down. Rules that miss known attacks are widened.

4. Ship

Rules ship in two places. Built-in YAML rules live in internal/detection/builtin/ and are bundled with the binary. JS rules live in rules/ and are loaded from your local rules directory (~/.harpax/rules/) at startup, with hot-reload during runtime so changes take effect without a restart.

5. Tune

Once a rule is in the wild, the detection pipeline records every fire — whether the user approved or denied the override, whether the rule was eventually added to an allowlist. That feedback is what drives the next round of tuning: patterns that consistently trigger overrides get reweighted, and patterns that get whitelisted frequently get scoped tighter.

The methodology behind the tiers

Harpax's detection pipeline is layered intentionally. Different threat categories have different signal characteristics:

  • T1 (regex) works for high-confidence textual patterns — credential formats, known jailbreak phrases, dangerous shell primitives. Fast, deterministic, easy to audit.
  • T2 (embedding) targets semantic variations on known attacks — the rewordings and paraphrases that regex misses. Trades latency for recall.
  • T2.5 (sequence) catches behavioral patterns — the kind of multi-step attack where no single event would look suspicious in isolation. This tier is where most novel attack research lives.
  • T3 (LLM review) is the escape hatch for ambiguous cases: situations where the only realistic way to decide whether something is malicious is to read it. Used sparingly because of cost and latency.

Responsible disclosure and how you can contribute

If you discover a new agent-targeted attack pattern that Harpax doesn't catch, please report it through the Cambric service desk at cambric.atlassian.net/servicedesk or email [email protected]. Include the session JSONL if you have it — that's the input format the research team uses to validate new rules.

For attacks you'd like to disclose privately before public publication, please mark the report as confidential.

Want to write your own rules?

The same rule format Harpax ships with is what custom rules use. Drop a .js file into ~/.harpax/rules/ and it loads automatically. The Rules page in the GUI includes a tester for validating against captured events. Reading the built-in YAML rules in internal/detection/builtin/ is the fastest way to see good patterns.