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? A maintainer reviews it and turns 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→- New Rule issues: a bot converts your issue to a YAML draft under proposals/ and opens a draft PR with your name in the author field. The other issue types above, Red Team Probes included, are reviewed by a maintainer first; a PR follows only if the maintainer accepts the report.
- 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 (SPEC.md) 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 → 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.