ATR (Agent Threat Rules): a YAML rule format for agent runtime detection

The gap ATR targets: Sigma and YARA do not model agent runtime events

The README states the problem directly. Sigma describes log-based detections for SIEM ingestion and, per the README, has no native model for LLM I/O, tool-call arguments, or agent context windows. YARA describes binary and text patterns for file-system artifacts and, again per the README, has no native model for runtime agent events. OWASP Agentic Top 10 and MITRE ATLAS are described as taxonomies, not executable detection content. ATR fills that slot with a rule format meant to be evaluated against agent events rather than log lines or files. The intended audience is detection engineers and platform teams running MCP servers, autonomous coding assistants, or multi-agent frameworks who want to write a detection once and have it evaluated by any conforming engine, in the same way a Sigma rule is portable across SIEM backends. It is not aimed at teams who only need a scanner for a single product, and it is not a runtime enforcement layer. The repository ships rules and an engine that evaluates them; what you do with a match is your integration's problem.

Rule anatomy: YAML documents, ATR-YYYY-NNNNN identifiers, and a versioned schema

Rules are YAML documents conforming to a versioned schema, identified by the public ATR-YYYY-NNNNN scheme, and evaluated by any conforming engine. That is the whole mechanism as the README describes it: a schema, a naming convention, and a corpus. The reference engine is TypeScript and lives at src/ in the repository; a Python wrapper ships alongside it. The README also describes a proposed v1.0 spec layer with separate documents for events, profiles, correlation, and language detection, each with JSON schemas, plus a conformance corpus structure at three levels (L1, L2, L3). Those artifacts are tagged PROPOSED, so treat the event, profile, correlation, and language-detection documents as drafts rather than as the interface you build against. The stable part is the rule format in SPEC.md, which the README says is merged into open-source repositories at Microsoft, Cisco, and Gen Digital and integrated by MISP/CIRCL, the OWASP Agent Security Regression Harness, SigmaHQ, and FINOS Common Cloud Controls. Note the distinction the README itself draws: every number in the document is sourced from data/stats.json, and where the README and stats.json disagree, stats.json is authoritative. If you are going to depend on a rule count or a coverage percentage, read that file.

ATD, the technique catalog, and why it is separate from the rules

ATD (Agentic Threat Detection) is the technique catalog: an enumeration of agent-runtime attack techniques mapped to MITRE ATLAS, OWASP ASI, and CWE. The README frames the split as technique versus detection: ATD names the what, ATR rules are the how. The catalog lists 80 techniques across 9 tactics, each mapped to an upstream framework or carrying a documented gap, and only a subset have a live ATR rule. That gap is deliberate. The README states a technique needs verifiable provenance, not a rule. Two scripts gate contributions: scripts/validate-atd.ts validates each technique against website/public/atd/atd-technique.schema.json, and scripts/atd/verify-atd-mappings.ts verifies every cited MITRE ATLAS id against the authoritative catalog. If you maintain detections, this is the part worth reading before you write anything new. It tells you which techniques the project considers in scope even when no rule exists yet, which is a more honest signal of coverage than a rule count alone. A rule count tells you how many detections shipped; the catalog tells you how many named techniques have no detection behind them.

Getting it running: npm, PyPI, and the ATR Scan GitHub Action

Installation paths visible in the README are the npm package agent-threat-rules, the PyPI package pyatr, and a GitHub Marketplace action listed as ATR Scan. The badges in the README point at npmjs.com/package/agent-threat-rules and pypi.org/project/pyatr/. The README does not include a worked example of loading a rule file and evaluating an event, and it does not print the engine's constructor or evaluation API in the excerpt available here. That is a real gap for anyone trying to evaluate the project in an afternoon: you can install the package, but the README as supplied does not show the call you make to run a rule against an event. The documented entry points are the package names, the GitHub Action, the rule corpus, SPEC.md for the format, and the validation scripts for ATD contributions. If you need the engine API before installing, read src/ in the repository rather than the README. Releases are versioned separately for the rule corpus and the Python wrapper: v4.0.0 is labelled as 785 detection rules, pyatr-v0.3.0 is the Python wrapper, and v3.5.12 is described as a TC crystallization batch. Pin both the rules and the wrapper, since they move on their own schedules.

The draft status is the main constraint, not the rule format

The README is unusually direct about this. ATR is published as a Working Draft at version 3.0.0-alpha.1. Governance is single-maintainer (BDFL) transitioning to a Technical Steering Committee per GOVERNANCE.md. The standardization scaffolding added in May 2026 (a proposed 9-seat TSC charter, the v1.0 spec layer, a conformance corpus structure, legal artifacts, and an ATR-Certified program guide) is tagged PROPOSED v1.0 and v2.0 and is not ratified. The 9-seat TSC has not been formed. The trust marks are not registered. The README says existing v1.1 governance continues to operate and that the rule format, npm package, TypeScript engine API, and rule corpus are unchanged, so current integrations keep working. Read that as two separate claims with two separate risk profiles. The rule format is described as stable and already merged into third-party repositories. The governance and certification layer is a proposal. If your adoption decision depends on a ratified standard, a seated committee, or a certification program you can point auditors at, the material says none of those exist yet. If it depends on a YAML schema and a MIT-licensed engine, those do exist.

Where ATR is the wrong tool

Three cases stand out from the material. First, if you need file or binary scanning, use YARA. The README's own framing is that YARA covers file-system artifacts and ATR covers runtime agent events; they are not substitutes. Second, if your detections are already expressed as SIEM log rules and your telemetry pipeline is a log pipeline, Sigma is the established format and ATR does not replace it. ATR assumes agent events (LLM I/O, tool-call arguments, agent context) as the input, and if you are not collecting those, the rules have nothing to match against. Third, if you need a single-vendor product with a support contract, ATR is a rule format plus reference engines, not a managed detection service. The README notes integrations into Microsoft AGT, Cisco AI Defense, and other products, which means the format may reach you through a vendor console rather than through the npm package. Also note the Python side: the README describes a Python wrapper, and the engines/ directory is described as holding Python and Go reference implementation interface contracts, tagged PROPOSED. If you are a Python shop expecting a first-class engine rather than a wrapper, verify what pyatr actually exposes before committing. The supplied material does not describe its API surface.

Adoption claims, and what they do and do not tell you

The README lists merges and integrations at Microsoft, Cisco, Gen Digital, MISP/CIRCL, the OWASP Agent Security Regression Harness, SigmaHQ, FINOS Common Cloud Controls, precize, and Sage, and says the full list with PR links is in section 6 of the README. That is the strongest signal in the material, and it is a signal about the format, not about detection quality. A merged rule file means another project accepted the schema and the content into its repository. It does not tell you the rules fire correctly on your traffic, and the README does not present precision or false-positive measurements in the excerpt available here. The coverage badges claim 10 of 10 OWASP Agentic Top 10 categories and 91.8 percent against SAFE-MCP. Treat those as coverage-of-taxonomy claims, which is what they are labelled as, not as detection efficacy. The evaluation section exists in the README table of contents, but its contents are not in the supplied material, so there is no basis here to say how the rules perform against a labeled corpus. If you need that before adopting, it is the first thing to look for.

Maintenance cost, licensing, and what to pin

MIT covers the repository, including the reference TypeScript engine and the Python wrapper. MIT is permissive and places no obligation on your own rule files or on your integration code; it also means there is no patent grant and no warranty, which matters if you are embedding this in a product. That is a description of the licence text, not legal advice. The maintenance picture has two moving parts. The rule corpus and the Python wrapper release independently (v4.0.0 and pyatr-v0.3.0 are separate tags), so a version bump in the corpus does not imply a matching engine change, and vice versa. The standardization layer is the other moving part: the README says the scaffolding is not ratified and that a TSC is not seated, so the governance documents you read today may be replaced by the v1.0 and v2.0 proposals, or not. The README also says the rule format, npm package, TypeScript engine API, and rule corpus are unchanged by that process, which is the commitment to hold them to. Concretely: pin the npm package version, pin the rule corpus tag, and re-read data/stats.json at each upgrade rather than trusting the badge counts, since the README itself defers to that file.

Editorial conclusion

Adopt ATR if you need to express agent-runtime detections (prompt injection, tool poisoning, credential exfiltration) in a format that is not tied to one vendor's engine, and if you can pin a rule corpus version. Do not adopt it if you need a ratified standard with a seated technical steering committee: the README states the 9-seat TSC has not been formed and the v1.0 and v2.0 scaffolding is tagged PROPOSED. Before integrating, read data/stats.json because the README says stats.json is authoritative where the two disagree, check STANDARDIZATION-STATUS.md for the status of each artifact you plan to depend on, and confirm the rule count you are pinning against the release you install rather than against the badge.

Official sources

1. Agent-Threat-Rule/agent-threat-rules on GitHub
2. License: MIT
3. Project website
4. README
5. Releases