agent-threat-rules 2.2.1 → 3.1.0

package/spec/internet-drafts/draft-lin-atr-core-00.txt

@@ -0,0 +1,560 @@
+
+
+
+
+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]