| Internet-Draft | ATR Core | May 2026 |
| Lin | Expires 17 November 2026 | [Page] |
This document specifies the Agent Threat Rules (ATR) Core Specification, an open, vendor-neutral detection rule standard for AI agent security threats. ATR is analogous in role to Sigma for SIEM but applies to AI agent artifacts (skill descriptions, MCP tool definitions, agent configurations) and AI agent runtime events (LLM input/output, tool invocations, context windows). The specification defines the rule wire format in YAML 1.2, the canonical rule identifier scheme, evaluation semantics with explicit combinator and operator vocabularies, match output structure, ten canonical threat categories, and three conformance levels. The intent is to enable interoperable detection across independent implementations and to provide a machine-readable layer that operationalizes policy frameworks such as NIST AI RMF, the NIST Generative AI Profile (AI 600-1), OWASP Agentic Top 10, and MITRE ATLAS.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 November 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
AI agents now browse the web, run code, and invoke external tools. The attack surface they expose is observable: prompt injections, tool description poisoning, context window exfiltration, credential leakage through agent-controlled HTTP traffic, and configuration files that take effect before any human trust dialog. Several policy frameworks describe these risks, but none of them are directly executable by a scanner. ATR fills that gap with a vendor-neutral rule format, a stable identifier scheme, and a conformance test suite that lets independent implementations agree on whether a given input matches a given rule.¶
ATR rules are YAML documents. Each rule has a globally unique identifier of the form ATR-YYYY-NNNNN assigned by the project's Numbering Authority. A conforming engine loads the rule corpus and emits Match outputs for inputs that satisfy the rule's detection condition. The Specification is intentionally narrow: it defines wire format, identifiers, evaluation semantics, match output, and three conformance levels. Higher-level governance (rule contribution, deprecation, trademark policy) lives in companion documents in the project repository.¶
ATR is the executable detection layer for AI agent threats. It cites adjacent standards rather than replacing them:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
| Term | Definition |
|---|---|
| Rule | A YAML document conforming to Section 4 that describes one detection pattern. |
| Rule ID | A globally unique identifier in the form ATR-YYYY-NNNNN, see Section 3. |
| Engine | Software that loads Rules and evaluates Inputs against them. |
| Input | A structured artifact or AgentEvent submitted for evaluation. |
| Match | An Engine's output indicating that a Rule's detection condition evaluated to true for a given Input. |
| Numbering Authority | The body authorized to assign permanent Rule IDs (see project Governance document). |
| Conformance Level | One of L1, L2, L3, see Section 9. |
| Corpus | The set of Rules officially published under a given ATR version. |
A Rule ID conforms to the following ABNF [RFC5234]:¶
rule-id = "ATR" "-" year "-" sequence year = 4DIGIT sequence = 5DIGIT DIGIT = %x30-39¶
A conforming Rule is a UTF-8 encoded [YAML12] document whose top-level value is a mapping containing at minimum the fields defined in this section. Engines MUST preserve unknown top-level fields when round-tripping Rules but MUST NOT allow such fields to alter evaluation outcomes.¶
The full field schema, including required and optional fields with type constraints, is given in the project's spec/atr-schema.yaml and tracked in this document by reference. Required top-level keys are: id, title, status, description, author, date, severity, tags, agent_source, detection, response, test_cases.¶
Given a Rule R and an Input I, an Engine MUST emit a Match if, and only if, all conditions in R.detection.condition evaluate to true against I per the combinator semantics in Section 5.2.¶
R.detection.condition is a logical expression over named selectors declared in R.detection.selectors. Engines MUST implement:¶
| Combinator | Semantics |
|---|---|
| S | true iff selector S matches |
| S1 and S2 | true iff both S1 and S2 match |
| S1 or S2 | true iff S1 or S2 matches |
| not S | true iff S does not match |
| all of S* | true iff every selector matched by the wildcard matches |
| 1 of S* | true iff at least one selector matched by the wildcard matches |
Engines MUST implement the operators below with the given semantics: contains, contains_i, regex (ECMAScript-compatible), equals, startswith, endswith, length_gt, length_lt, in.¶
Engines MUST reject Rules that use operators outside this list, with a clear error message. Engines MAY support additional operators as extensions but MUST treat Rules using such extensions as non-portable.¶
For a given Engine version, a given Rule, and a given Input, the Match outcome MUST be deterministic. Engines MUST NOT introduce non-determinism (e.g., sampling, time-of-day branching) into Rule evaluation.¶
An Engine MUST emit Match output that includes, at minimum, a rule_id, the corpus_version it was loaded from, a stable input_identifier, the matched_at timestamp (ISO 8601), the rule severity, the rule category, and the list of matched_selectors. Engines MAY emit additional fields and MAY use JSON, SARIF, STIX 2.1, or other serializations.¶
The following ten categories are normative for the current Specification. New categories are introduced only by Specification amendment.¶
A Rule MAY include a compliance object mapping its detection to external frameworks. Identifiers MUST come from the authoritative source for each framework. Where ambiguity exists, Rule authors SHOULD include a references entry pointing to the source document. Crosswalks defined for the current Specification include [OWASP-AGENTIC], OWASP LLM Top 10, [MITRE-ATLAS], [NIST-AI-RMF], ISO/IEC 42001, EU AI Act, and [SAFE-MCP].¶
| Level | Requirement |
|---|---|
| L1 | Engine loads the published Corpus without parse errors and emits Match output for at least one Rule. |
| L2 | Engine passes 100 percent of the Conformance Test Suite for the declared Spec version. |
| L3 | Engine passes L2, emits Match output in at least two interchange formats (JSON plus one of SARIF, STIX 2.1, MISP, OpenCTI), and publishes its results against the public benign Corpus with documented false-positive rate. |
An implementation MAY claim "ATR-Compatible" only with a declared Conformance Level and a reproducible test report.¶
Rules are content that an Engine evaluates against potentially untrusted Inputs. An Engine MUST NOT permit a Rule's free-form metadata fields (description, references) to alter evaluation behavior. Only fields listed in Section 4, Section 5, and the match-output section affect evaluation.¶
A malformed regex selector may cause catastrophic backtracking. Engines MUST apply a per-rule execution timeout (RECOMMENDED: 100 ms per Input per Rule) and MUST report a timeout as a non-match rather than an error.¶
If a Rule's matched substring contains PII or sensitive credentials, Engines SHOULD provide a redaction option that hashes or truncates the matched substring before emitting Match output.¶
This document requests registration of the following media types:¶
Registration templates are provided in Appendix B of the project's SPEC.md and will be filed with IANA on advancement of this document.¶
The author acknowledges contributions from external maintainers at Cisco AI Defense, MISP / CIRCL, Microsoft Agent Governance Toolkit, Gen Digital Sage, and the OWASP Gen AI Security Project, as well as researchers at NVIDIA garak and the HackAPrompt 2023 competition whose attack payloads seeded the rule corpus.¶