Independent Submission K-H. Lin Internet-Draft ATR Project / Panguard AI, Inc. Intended status: Informational 16 May 2026 Expires: 17 November 2026 Agent Threat Rules (ATR): An Open Detection Standard for AI Agent Security Threats draft-lin-atr-core-00 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Lin Expires 17 November 2026 [Page 1] Internet-Draft ATR Core May 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Relationship to Existing Standards . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Rule Identifier . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Assignment Rules . . . . . . . . . . . . . . . . . . . . 4 4. Rule Document Structure . . . . . . . . . . . . . . . . . . . 5 5. Detection Semantics . . . . . . . . . . . . . . . . . . . . . 5 5.1. Match Definition . . . . . . . . . . . . . . . . . . . . 5 5.2. Condition Combinators . . . . . . . . . . . . . . . . . . 5 5.3. Selector Operators . . . . . . . . . . . . . . . . . . . 6 5.4. Determinism . . . . . . . . . . . . . . . . . . . . . . . 6 6. Match Output . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Canonical Categories . . . . . . . . . . . . . . . . . . . . 7 8. Crosswalks . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. Normative References . . . . . . . . . . . . . . . . . . . . 8 13. Informative References . . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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 Lin Expires 17 November 2026 [Page 2] Internet-Draft ATR Core May 2026 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. 1.1. Relationship to Existing Standards ATR is the executable detection layer for AI agent threats. It cites adjacent standards rather than replacing them: * [NIST-AI-RMF] and [NIST-GAI-PROFILE] define risk management functions (Govern, Map, Measure, Manage). ATR provides detection rules that populate the Measure function at scan time, with a crosswalk in Section 8. * [OWASP-AGENTIC] and [MITRE-ATLAS] categorize adversarial behaviors. ATR rule metadata maps each rule to specific categories and techniques in these frameworks. The format itself is inspired by [SIGMA]. * [STIX21] provides a CTI interchange envelope. ATR Match output can be emitted in STIX 2.1 via the x-atr-rule extension defined in the project repository. 2. Conventions and Terminology 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. Lin Expires 17 November 2026 [Page 3] Internet-Draft ATR Core May 2026 +=============+=========================================+ | 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 | The body authorized to assign permanent | | Authority | Rule IDs (see project Governance | | | document). | +-------------+-----------------------------------------+ | Conformance | One of L1, L2, L3, see Section 9. | | Level | | +-------------+-----------------------------------------+ | Corpus | The set of Rules officially published | | | under a given ATR version. | +-------------+-----------------------------------------+ Table 1 3. Rule Identifier 3.1. Format A Rule ID conforms to the following ABNF [RFC5234]: rule-id = "ATR" "-" year "-" sequence year = 4DIGIT sequence = 5DIGIT DIGIT = %x30-39 3.2. Assignment Rules 1. Rule IDs MUST be assigned by the Numbering Authority and MUST NOT be self-assigned by contributors. Lin Expires 17 November 2026 [Page 4] Internet-Draft ATR Core May 2026 2. Once assigned, a Rule ID MUST be considered permanent and MUST NOT be reassigned, even if the originally-assigned Rule is deprecated. 3. A Rule ID MUST NOT encode classification information (category, severity, scan target). Classification is carried in metadata fields per Section 4. 4. A Rule ID MUST be globally unique within the official Corpus. 5. Contributors SHOULD use a placeholder identifier of the form ATR- YYYY-DRAFT- in pull requests prior to merge. 4. Rule Document Structure 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. 5. Detection Semantics 5.1. Match Definition 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. 5.2. Condition Combinators R.detection.condition is a logical expression over named selectors declared in R.detection.selectors. Engines MUST implement: Lin Expires 17 November 2026 [Page 5] Internet-Draft ATR Core May 2026 +============+=================================+ | 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 | +------------+---------------------------------+ Table 2 5.3. Selector Operators 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. 5.4. Determinism 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. 6. Match Output 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. Lin Expires 17 November 2026 [Page 6] Internet-Draft ATR Core May 2026 7. Canonical Categories The following ten categories are normative for the current Specification. New categories are introduced only by Specification amendment. 1. prompt-injection 2. agent-manipulation 3. skill-compromise 4. context-exfiltration 5. tool-poisoning 6. privilege-escalation 7. model-abuse 8. excessive-autonomy 9. model-security 10. data-poisoning 8. Crosswalks 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]. 9. Conformance Levels +=======+===========================================================+ | 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. | +-------+-----------------------------------------------------------+ Lin Expires 17 November 2026 [Page 7] Internet-Draft ATR Core May 2026 | 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. | +-------+-----------------------------------------------------------+ Table 3 An implementation MAY claim "ATR-Compatible" only with a declared Conformance Level and a reproducible test report. 10. Security Considerations 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. 11. IANA Considerations This document requests registration of the following media types: * application/vnd.atr.rule+yaml — a single ATR Rule * application/vnd.atr.corpus+yaml — a corpus manifest listing multiple Rules * application/vnd.atr.match+json — Match output Registration templates are provided in Appendix B of the project's SPEC.md and will be filed with IANA on advancement of this document. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . Lin Expires 17 November 2026 [Page 8] Internet-Draft ATR Core May 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, . [YAML12] Ben-Kiki, O., Evans, C., and I. dot Net, "YAML Ain't Markup Language (YAML) Version 1.2 (3rd Edition)", October 2021, . 13. Informative References [SIGMA] SigmaHQ, "Sigma Rule Specification", 2024, . [STIX21] OASIS, "STIX Version 2.1 OASIS Standard", 2021, . [NIST-AI-RMF] NIST, "Artificial Intelligence Risk Management Framework (AI 100-1)", 2023, . [NIST-GAI-PROFILE] NIST, "NIST AI 600-1 Generative AI Profile", 2024, . [OWASP-AGENTIC] OWASP Gen AI Security Project, "OWASP Agentic Security Initiative Top 10 (2026)", 2026, . [MITRE-ATLAS] MITRE Corporation, "Adversarial Threat Landscape for AI Systems", 2024, . [SAFE-MCP] safe-agentic-framework, "Secure AI Framework for Enterprise — Model Context Protocol", 2026, . Lin Expires 17 November 2026 [Page 9] Internet-Draft ATR Core May 2026 Appendix A. Acknowledgments 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. Author's Address Kuan-Hsin Lin ATR Project / Panguard AI, Inc. Taipei, Taiwan Email: adam@agentthreatrule.org URI: https://agentthreatrule.org Lin Expires 17 November 2026 [Page 10]