



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-<hex> 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,
              <https://www.rfc-editor.org/rfc/rfc2119>.



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,
              <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [YAML12]   Ben-Kiki, O., Evans, C., and I. dot Net, "YAML Ain't
              Markup Language (YAML) Version 1.2 (3rd Edition)", October
              2021, <https://yaml.org/spec/1.2.2/>.

13.  Informative References

   [SIGMA]    SigmaHQ, "Sigma Rule Specification", 2024,
              <https://github.com/SigmaHQ/sigma-specification>.

   [STIX21]   OASIS, "STIX Version 2.1 OASIS Standard", 2021,
              <https://docs.oasis-open.org/cti/stix/v2.1/stix-
              v2.1.html>.

   [NIST-AI-RMF]
              NIST, "Artificial Intelligence Risk Management Framework
              (AI 100-1)", 2023,
              <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf>.

   [NIST-GAI-PROFILE]
              NIST, "NIST AI 600-1 Generative AI Profile", 2024,
              <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf>.

   [OWASP-AGENTIC]
              OWASP Gen AI Security Project, "OWASP Agentic Security
              Initiative Top 10 (2026)", 2026,
              <https://genai.owasp.org/llm-top-10/agentic-top-10/>.

   [MITRE-ATLAS]
              MITRE Corporation, "Adversarial Threat Landscape for AI
              Systems", 2024, <https://atlas.mitre.org/>.

   [SAFE-MCP] safe-agentic-framework, "Secure AI Framework for
              Enterprise — Model Context Protocol", 2026,
              <https://github.com/safe-agentic-framework/safe-mcp>.









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]
