A rule written in Taipei catches an attack first reported in Seattle.
ATR is a public good. Anyone can propose a rule; through a public PR and the safety gate, it becomes part of a standard every defender shares. MIT licensed, no proprietary tooling, no CLA. Start by reporting an evasion — fifteen minutes.
Open an Integration Request issue
Any engine may implement the standard — this path is for the people building one. Structured intake form, five minutes. Use it when you need a spec walkthrough, a design review, sample code for your language, or framework-compliance mapping. Maintainers respond within seven days.
Open the issue→Open a PR against ADOPTERS.md
Take this path when your integration is publicly verifiable. Schema-conforming entries with a verifiable evidence link get merged — maintainers do not pre-approve adopters. Same model as Sigma.
ADOPTERS.md →Submit a New Rule (5 min, no fork)
~5 minFound a new attack pattern? File one issue, the bot converts it to a draft proposal PR automatically. No clone, no YAML required.
Open an Issue→Submit a Red Team Probe (joins the benchmark)
~10 minHave an attack payload plus benign look-alikes? The bot converts it into a proposal; once merged, your probe joins the next benchmark run. Your contribution shows up in the recall numbers.
Submit a Probe→Report an Evasion
~15 minFound a way to bypass a rule? Every confirmed evasion triggers a rule improvement. Most impactful contribution.
Open an Issue→Report a False Positive
~20 minRule triggered on legitimate content? Every false positive sharpens the per-lane precision ATR publishes. A standard earns trust by publishing its worst figure, not hiding it.
Open an Issue→Full Rule Authoring (advanced)
1-2 hrWant to author YAML directly? Fork the repo, follow the spec, run atr validate + atr test, open a PR. Full walkthrough provided.
See the Guide→AI-Native Contribution
VariableUse Claude Code or Cursor with ATR's MCP server. The AI writes YAML, you review.
See MCP Setup→- Bot converts your issue to a YAML draft under proposals/ and opens a draft PR with your name in the author field.
- A maintainer or community member writes the detection regex and runs the safety gate — true- and false-positive samples, schema compliance, no conflict with existing rules, and zero false positives on the benign corpus as a hard requirement. The gate actually blocks; it is not decorative.
- Rule merges to main, auto-publishes to npm + GitHub release — from that moment it belongs to every engine that reads ATR, across vendors and across borders.
- On the next measurement run, your payload joins the benchmark corpus. data/measurements/<source>/ stores the historical recall / precision / fp-rate per run, version-pinned and drift-proof.
- Every public recall claim cites a measurement file path, so your contribution is traceable in the public audit chain.
The spec (ATR-SPEC-v1, currently v3.5.0 Working Draft) is the contract between all conforming engines. Spec changes are not as direct as rule additions — the process is: open an RFC issue with title prefixed [RFC] describing what you want to change and why; leave a 14-day public comment window (extended to 30 for complex proposals) so every implementer sees it and can respond; then submit the PR. Breaking changes (SemVer major bump) require an additional 30-day advance notice.
Full process documented under Decision-making on the governance page.
If you want to contribute but don't know where to start, two low-friction entry points:
- Open issues labelled 'good first issue' — maintainer-tagged starter tasks with clear scope.
- False-positive reports — if you hit a misfire in your workflow, a 15-minute report directly helps every downstream adopter. Maintainers prioritise this class of feedback.
ATR is currently single-maintainer and is actively recruiting a second and third. Candidate criteria, the decision-making structure, and how to apply are all on the governance page.
See 'Become a maintainer' on the governance page→Threat Cloud is an optional reference service operated by the ATR maintainers — not part of the standard. The standard is the spec plus the MIT-licensed rules, fully usable offline via npm / PyPI / raw YAML. Threat Cloud only adds hosted convenience (rule sync, threat submission); the same outcomes are reachable without it.
The Threat Cloud auto-pipeline (optional convenience layer)
The canonical way rules get made is the community/maintainer workflow described in "What happens after you contribute" above (issue → bot draft PR → maintainer writes regex → safety gate → merge → npm publish). Below is the optional, maintainer-operated automated version Threat Cloud runs to target hours for that same flow — the standard and the rules are identical whether or not you use it.