Governance is on the public record.
A standard earns trust when its process can be audited by anyone — not when a single authority vouches for it. ATR is an MIT-licensed open standard, not owned by any company. Who maintains it, how a rule gets in, how the spec changes, what the lead maintainer's conflicts are — all of it is on this page, and all of it is auditable on GitHub.
Responsible for rule quality, PR review, and releases.
Founder and primary maintainer of ATR. Responsible for RFC-001 quality standard design, community outreach, and ecosystem integration review. GitHub: eeee2345 (Adamthereal).
[email protected]ATR was started by a single maintainer — the same path Linus Torvalds took with Linux in 1991, and Florian Roth with Sigma: one person defines the format and the quality bar, the community takes over governance. That is the honest present state, not an apology. Recruitment of a second maintainer is underway (criteria below), and evaluating transfer to a neutral foundation (Linux Foundation, OpenSSF, or equivalent) is on the roadmap. The destination is a Technical Steering Committee; every standard that reaches one started with someone willing to write the first rule.
Six gates before any rule merges.
These gates are machine-enforced, and every one leaves a trace in a public CI log — anyone can see why a rule passed, or why it was blocked. Quality is not vouched for by a maintainer's judgment; it is demonstrated by tests anyone can re-run.
Valid YAML schema, valid regex (no ReDoS), at least 1 TP and 1 TN.
A confidence score — precision, in-the-wild validation, coverage depth, documented evasions — decides which detection lane a rule enters. Below the bar, a rule is never promoted to enforce, but may still exist as advisory. The threshold is a published formula, not a maintainer's preference.
A new rule must record zero false positives on the per-PR benign corpus gate. This is the floor at merge time; after release, false-positive rates are measured lane by lane on a larger benign corpus and published, never hidden behind a single figure.
New rule must not conflict with existing rules on the same input.
Maintainer reviews regex shape, test case coverage, and source citation. Stable tier requires human-reviewed provenance.
Maximum 10 new rules per PR. test_cases must include true_positives and true_negatives.
Different changes have different bars.
Changing a rule and changing the spec are not the same act. A wrong rule can be deprecated or revised; the spec is the contract every conforming engine relies on, so changing it has to be visible to every implementer with time to react. The bar scales with how many people a change moves.
Rule PRs run through the six safety gates (see Merge policy above). Once they pass, a single maintainer review is sufficient to merge. Two-reviewer requirement is not enforced because the safety gates already cover objective quality.
The spec is the contract between all conforming engines. Any spec change is opened first as an RFC issue with a 14-day public comment window (extended to 30 for complex proposals) so every implementer sees it, then the PR is accepted. Under the current BDFL phase the 'two approvals' bar will be satisfied by the lead maintainer plus one external reviewer once designated. When the TSC is formed the bar becomes a TSC majority.
Any change that breaks the rule schema, the engine API, or the semantics of an existing rule_id counts as breaking. A 30-day advance notice goes out via GOVERNANCE.md, CHANGELOG, and an @adopters notification so upstream adopters have time to react.
There is currently one maintainer, so adding a second requires that maintainer to agree. Once 2+ maintainers exist, additions require unanimous approval. Removal requires a 2/3 majority (not applicable under BDFL).
Deprecated rules remain in the corpus but engines MUST NOT enable them by default. After 30 days the rule may be removed from the corpus; downstream adopters who depended on it can pin to a deprecated version.
There isn't one yet, and the path to forming one is open.
OASIS CTI, OpenTelemetry SIGs, and OWASP Working Groups all run scheduled meetings. ATR is not yet at the scale where standing meetings earn their cost — for now every discussion happens asynchronously, in the open, on the public record in GitHub Issues and PRs. A standard with a handful of implementers should not stand up a committee before there is demand for one.
The path to forming one is open, and it is demand-driven: if you have active integration work, want to push the spec in a particular direction, or represent an implementer that wants structured voice in the process, open an issue titled with the prefix [WG-proposal]. When three or more independent implementers express the same need, the maintainers will schedule a recurring (bi-weekly) working-group meeting. The trigger is written here, and anyone may invoke it.
We are actively recruiting.
A single maintainer is the largest known structural risk to ATR, and we state it plainly. The path from one person to a Technical Steering Committee (TSC) is the one every open standard walks — governance distributes when contributors have merged enough to have earned commit rights, not before. We are actively recruiting a second and third maintainer.
Candidate criteria:
- Merged at least three substantive PRs in the ATR repo in the prior six months (new rules, schema fixes, engine improvements, or substantive documentation rewrites)
- Familiar enough with ATR-SPEC-v1 to explain its conformance clauses
- Able to accommodate asynchronous review (no real-time requirement, but PRs should receive a first review response within an average of 7 days)
- When representing ATR publicly (GitHub, issue comments, conferences), maintains a neutral register and does not imply any commercial interest
How to apply: [email protected] with subject 'ATR maintainer application'. Include links to your recent PRs and which area you want to take on (rules / spec / engine / documentation).
If the lead maintainer becomes unavailable.
Short term (within 30 days): The CODEOWNERS file and CI automation continue to function on GitHub. Merged rules continue to publish via npm. ATR has no dependency on a single server or closed system — rules are plain-text YAML and anyone can fork.
Medium term: a second maintainer (recruitment ongoing) takes over PR review. If none is identified within 30 days, interim maintainers will be sought from external contributors who meet the following criteria: merged at least three substantive PRs in the prior six months, demonstrated familiarity with the schema implementation, and able to accommodate asynchronous review. Specific names are NOT published on this page until the invitation has been sent AND the candidate has accepted — at which point the new maintainer appears under 'Current maintainers' above.
Long term: The ATR roadmap includes evaluating transfer to a neutral foundation (Linux Foundation or OpenSSF). Transfer requires: two or more external maintainers, and at least one organization willing to fund governance overhead.
Why this disclosure exists.
ATR (Agent Threat Rules) is an MIT-licensed open standard maintained under the Agent-Threat-Rule GitHub organization. The lead maintainer also holds a commercial affiliation in AI agent security. We do not hide this; we write it down — the disclosure itself is the governance mechanism. A standard's neutrality is not proven by a maintainer having no interests, but by a decision process open enough that anyone can check whether those interests bent it.
The boundary: ATR's rules, CHANGELOG, benchmark data, and documentation must not be distorted by any commercial interest. ATR's issue tracker and PR review process is open to everyone — including competitors of that commercial interest, who may propose rules, review pull requests, and fork the entire standard. GOVERNANCE.md is publicly auditable on GitHub. Neutrality is not asserted; it is what these open doors, one by one, demonstrate.
If you observe any violation of this boundary, please open an issue on GitHub or email [email protected].
All contributions are published under MIT license. Contributors retain all rights to use their attack research in any form — ATR carries the detection, not ownership of the research.
A contributor's name appears in the rule's author field and metadata_provenance.discovered_by field. When MISP exports to STIX, when NIST cites the rule, attribution travels with it.