agent-threat-rules 4.0.0 → 4.2.0

package/rules/tool-poisoning/ATR-2026-02868-ssrf-ipv6-transition-address-embedded-private-ipv4.yaml

@@ -0,0 +1,107 @@
+title: SSRF via IPv6 Transition Address Embedding a Private IPv4 Target
+id: ATR-2026-02868
+rule_version: 1
+status: experimental
+description: |
+  Detects an agent tool argument whose URL host (or host-typed argument) is an IPv6 transition-mechanism address that carries an internal IPv4 address in its embedded 32 bits: IPv4-compatible (::a.b.c.d / ::XXXX:XXXX), IPv4-mapped written in hex (::ffff:XXXX:XXXX), IPv4-translated (::ffff:0:XXXX:XXXX), 6to4 (2002:XXXX:XXXX::/48) and NAT64 (64:ff9b::/96 and the local-use 64:ff9b:1::/48 prefix written with the IPv4 in the last 32 bits). The embedded IPv4 must fall in loopback 127.0.0.0/8, RFC 1918 (10/8, 172.16/12, 192.168/16) or link-local / cloud metadata 169.254/16.
+  Source: CVE-2026-55787 / GHSA-794r-5rp2-fpg8 in flytohub/flyto-core (< 2.26.3), an execution kernel for AI-agent workflows. Its validate_url_ssrf / is_private_ip guard compared resolved addresses only against native private IPv4 and IPv6 ranges and never unwrapped transition addresses, so a workflow author could hand http.get, http.request, browser.goto or llm.chat a URL such as http://[64:ff9b::a9fe:a9fe]/ and reach cloud metadata, loopback or RFC 1918 services. The same blind spot exists in any agent fetch tool whose guard checks ipaddress.is_private on the IPv6 object without first extracting the embedded IPv4.
+  Scope and limits: the rule matches the address literal only when it is the bracketed host of a URL (scheme://[...] or the %5B/%5D percent-encoded bracket form) or the value of a host / hostname / ip / address argument. It does not resolve DNS names that point at transition addresses, does not cover 100.64.0.0/10 CGNAT or 0.0.0.0/8 embeddings, and does not decode the RFC 6052 /32-/64 NAT64 layouts where the IPv4 is split around the u-octet. Overlap is intentional and partial: the dotted IPv4-mapped forms are already covered by ATR-2026-00013, hex ::ffff:7f00:1 / ::ffff:a9fe:a9fe by ATR-2026-02193, and the 169.254.169.254 NAT64 / 6to4 spellings by ATR-2026-02140; this rule adds the IPv4-compatible hex, 6to4 and NAT64 embeddings of loopback and RFC 1918 targets that no existing rule covers. CWE-918 (Server-Side Request Forgery).
+author: ATR Community (CVE sync)
+date: 2026/10/22
+schema_version: '0.1'
+detection_tier: pattern
+maturity: test
+severity: high
+references:
+  cve:
+    - CVE-2026-55787
+  ghsa:
+    - GHSA-794r-5rp2-fpg8
+  euvd:
+    - EUVD-2026-101588
+  cwe:
+    - CWE-918
+  owasp_llm:
+    - LLM06:2025
+  owasp_agentic:
+    - ASI02:2026
+  mitre_atlas:
+    - AML.T0049 - Exploit Public-Facing Application
+  mitre_attack:
+    - 'T1552.005 - Unsecured Credentials: Cloud Instance Metadata API'
+    - T1046 - Network Service Discovery
+  external:
+    - https://github.com/flytohub/flyto-core/security/advisories/GHSA-794r-5rp2-fpg8
+    - https://github.com/flytohub/flyto-core/commit/519e040384a74984848c4e84a6600e5f1020a6d2
+    - https://github.com/flytohub/flyto-core/releases/tag/v2.26.3
+    - https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-101588
+metadata_provenance:
+  cve: human-reviewed
+  ghsa: human-reviewed
+  cwe: human-reviewed
+  owasp_llm: human-reviewed
+  owasp_agentic: human-reviewed
+  mitre_atlas: human-reviewed
+  mitre_attack: human-reviewed
+compliance:
+  eu_ai_act:
+    - article: '15'
+      context: Article 15 (accuracy, robustness and cybersecurity) requires high-risk AI systems to resist attempts to misuse their tools; this rule provides detection evidence supporting that requirement by flagging agent fetch-tool URLs that smuggle an internal IPv4 target inside an IPv6 transition address past an SSRF guard.
+      strength: primary
+    - article: '9'
+      context: Article 9 risk management must treat identified risks; this rule provides detection evidence supporting the treatment of the transition-address SSRF bypass risk for agent workflows whose outbound-request guard may not unwrap embedded IPv4.
+      strength: secondary
+  nist_ai_rmf:
+    - function: Measure
+      subcategory: MS.2.7
+      context: MS.2.7 requires AI system security and resilience to be evaluated and documented; inspecting every outbound URL argument for transition-encoded internal targets is a measurable per-invocation control at the agent-to-network boundary.
+      strength: primary
+    - function: Manage
+      subcategory: MG.3.2
+      context: MG.3.2 requires third-party and pre-built components to be monitored in operation; agent workflow kernels such as flyto-core ship their own SSRF guards, and this rule monitors for the input class those guards are known to miss.
+      strength: secondary
+  iso_42001:
+    - clause: '8.1'
+      context: Clause 8.1 operational planning and control is supported by this rule's runtime detection of transition-address SSRF targets in agent tool calls.
+      strength: primary
+    - clause: '8.3'
+      context: Clause 8.3 AI risk treatment is supported by this rule's detection of the SSRF guard bypass before the request leaves the agent.
+      strength: secondary
+tags:
+  category: tool-poisoning
+  subcategory: ssrf-ipv6-transition-address-bypass
+  scan_target: tool_args
+  confidence: high
+  source: cve-disclosure
+agent_source:
+  type: tool_call
+  framework:
+    - any
+  provider:
+    - any
+detection:
+  condition: any
+  false_positives:
+    - Security test suites and SSRF-guard fixtures (for example flyto-core tests/core/test_ssrf_ipv6_transition.py) that pass these addresses to a fetch tool on purpose will match; that is the intended behaviour for a detection corpus.
+    - A NAT64 or 6to4 deployment that deliberately reaches an internal RFC 1918 service through its translated IPv6 address would match; such deployments are rare and should be allow-listed by destination.
+    - Public IPv4 embeddings (::ffff:8.8.8.8, 64:ff9b::808:808, 2002:808:808::) and ordinary native IPv6 hosts do not match.
+  conditions:
+    - field: tool_args
+      operator: regex
+      value: (?i)//(?:[^\s/@\[\]"]{1,64}@)?(?:\[|%5b)(?:(?:(?:0{1,4}:){1,4}|:):(?:ffff:(?:0{1,4}:)?)?|(?:0{1,4}:){5}(?:ffff|0{1,4}):|0{0,2}64:ff9b(?::0{0,3}1)?(?::0{1,4}){0,4}::?)(?:(?:7f[0-9a-f]{2}|0?a[0-9a-f]{2}|ac1[0-9a-f]|c0a8|a9fe):[0-9a-f]{1,4}|(?:127|10)(?:\.\d{1,3}){3}|172\.(?:1[6-9]|2\d|3[01])(?:\.\d{1,3}){2}|(?:192\.168|169\.254)(?:\.\d{1,3}){2})(?:\]|%5d)
+      description: URL bracketed host is an IPv4-compatible, IPv4-mapped/translated or NAT64 address whose final 32 bits are a loopback, RFC 1918 or link-local IPv4
+    - field: tool_args
+      operator: regex
+      value: (?i)//(?:[^\s/@\[\]"]{1,64}@)?(?:\[|%5b)0{0,2}2002:(?:7f[0-9a-f]{2}|0?a[0-9a-f]{2}|ac1[0-9a-f]|c0a8|a9fe):[0-9a-f:]{0,35}(?:\]|%5d)
+      description: URL bracketed host is a 6to4 (2002::/16) address whose embedded IPv4 (bits 16-47) is a loopback, RFC 1918 or link-local IPv4
+    - field: tool_args
+      operator: regex
+      value: (?i)["'](?:host|hostname|host_?name|ip|ip_?addr(?:ess)?|addr(?:ess)?|target_?host|server)["']\s*:\s*["']\[?(?:(?:(?:0{1,4}:){1,4}|:):(?:ffff:(?:0{1,4}:)?)?(?:7f[0-9a-f]{2}|0?a[0-9a-f]{2}|ac1[0-9a-f]|c0a8|a9fe):[0-9a-f]{1,4}|0{0,2}64:ff9b(?::0{0,3}1)?(?::0{1,4}){0,4}::?(?:7f[0-9a-f]{2}|0?a[0-9a-f]{2}|ac1[0-9a-f]|c0a8|a9fe):[0-9a-f]{1,4}|0{0,2}2002:(?:7f[0-9a-f]{2}|0?a[0-9a-f]{2}|ac1[0-9a-f]|c0a8|a9fe):[0-9a-f:]{0,35})\]?["']
+      description: Host-typed tool argument whose whole value is an IPv6 transition address (hex embedding) carrying a loopback, RFC 1918 or link-local IPv4
+response:
+  actions:
+    - alert
+    - snapshot
+  message_template: |
+    [ATR-2026-02868] HIGH: an agent tool is being sent to an IPv6 transition address (IPv4-compatible, IPv4-mapped, 6to4 or NAT64) whose embedded IPv4 is loopback, private or cloud metadata. This is the CVE-2026-55787 (flyto-core) SSRF guard bypass shape: unwrap the embedded IPv4 before the private-address check, and block the request.
+confidence: 78

package/spec/README.md

@@ -56,7 +56,10 @@ spec/
 │   └── atr-to-nist-csf-2.0.md         ← NIST CSF 2.0 (NIST IR 8596 Informative Reference draft)
 │
 ├── category-registry/
-│   └── v1.0.yaml                      ← (new) versioned top-level category list
+│   ├── v1.0.yaml                      ← (new) versioned top-level category list
+│   └── gemara/                        ← (new) the registry as Gemara catalogs, generated
+│                                         from v1.0.yaml; published as an OCI bundle
+│                                         by publish-gemara.yml
 │
 ├── schema/                            ← (new) JSON Schemas
 │   ├── rule.schema.json               ← rule format JSON Schema
@@ -266,8 +269,8 @@ The spec is being prepared for:
 
 1. **OASIS Open Project (primary)** as adjacent to CoSAI.
    Target: Q3 2026 acceptance, Q1 2027 first Committee Specification.
-2. **NIST CAISI (citation target)**.
-   No formal submission window currently open; awaiting next RFI.
+2. **NIST CAISI**, as a possible future citation venue only.
+   ATR has no engagement with CAISI.
 3. **IETF (informational draft, transport / OTEL emission only)**
    when reference implementations are stable.
 
@@ -282,6 +285,6 @@ OASIS Open Project."
 - Spec issues: GitHub Issues with label `spec-bug` or `spec-question`
 - Spec proposals: GitHub Pull Requests with AEP template
 - Maintainer: Adam Lin <adam@agentthreatrule.org>
-- Fiscal sponsor: Open Source Collective Inc. (501(c)(3),
-  EIN 81-1567737)
+- Fiscal sponsor: Open Source Collective Inc. (501(c)(6),
+  EIN 82-2037583)
 - TSC (post-ratification): tsc@agentthreatrule.org (mailing list, public)

package/spec/atr-correlation-v1.0.md

@@ -71,13 +71,13 @@ correlation:
 
 source_rules:
   - alias: "injection"
-    rule_id: "ATR-2026-00012"                 # indirect prompt injection
+    rule_id: "ATR-2026-00002"                 # indirect prompt injection
   - alias: "tool_call"
-    rule_id_pattern: "ATR-2026-001*"          # tool-poisoning class
+    rule_id: "ATR-2026-00012"                 # unauthorized tool call (tool-poisoning)
   - alias: "memory_write"
-    rule_id_pattern: "ATR-2026-003*"          # memory write
+    rule_id: "ATR-2026-00075"                 # agent memory manipulation
   - alias: "exfil"
-    rule_id_pattern: "ATR-2026-006*"          # context exfiltration
+    rule_id: "ATR-2026-00020"                 # system prompt leak (context exfiltration)
 
 correlation_logic:
   type: "temporal_sequence"                   # see § Correlation types below
@@ -105,6 +105,18 @@ response:
     Recommend immediate session quarantine plus memory store audit.
 ```
 
+> **Note on `rule_id_pattern` (added 2026-09-22).** ATR rule IDs are allocated
+> sequentially in a single five-digit space (`ATR-2026-00001` .. `ATR-2026-02845`
+> as of 2026-09-22); the digits do **not** encode a threat category. An
+> ID-prefix glob is therefore not a way to select "all rules in category X" —
+> it selects a numeric band that spans several categories and that shifts as
+> new rules are allocated. Earlier revisions of this example used band globs
+> such as `ATR-2026-006*` with category comments; under the current ID space
+> those patterns match either nothing or an unrelated set of rules. Prefer
+> explicit `rule_id` values, as the example above now does, and treat
+> `rule_id_pattern` as a convenience for genuinely contiguous, deliberately
+> allocated ranges only.
+
 ---
 
 ## Correlation types

package/spec/atr-event-v1.0.md

@@ -58,7 +58,7 @@ All conformant engines MUST emit these fields on every event.
 | `@timestamp` | RFC 3339 UTC string | When the rule fired. |
 | `atr.event_id` | UUID v7 (time-ordered) | Globally unique event identifier. |
 | `atr.spec_version` | string | ATR spec version this event conforms to. v1.0 = `"1.0"`. |
-| `atr.engine_id` | string | Identifier of the engine that produced the event. Format: `<vendor>/<product>/<version>`. Example: `atr/typescript-reference/3.1.0`, `cisco/ai-defense/2.4.1`, `microsoft/agent-governance-toolkit/2026.05`. |
+| `atr.engine_id` | string | Identifier of the engine that produced the event. Format: `<vendor>/<product>/<version>`. Example: `atr/typescript-reference/3.1.0`, `example-vendor/example-scanner/2.4.1`, `example-org/agent-gateway/2026.05`. |
 
 ### Rule attribution
 
@@ -105,7 +105,7 @@ All conformant engines MUST emit these fields on every event.
 | Field | Type | Description |
 |---|---|---|
 | `evidence.observation_id` | UUID | Identifier for cross-reference into OSCAL `observation` records. Same as `atr.event_id` recommended unless an existing system has its own. |
-| `evidence.signature` | base64 ed25519 | Signature over the canonical JSON encoding of this event. Signed by the engine's deployment-time key. Required for EU AI Act Article 50 evidence chains and NIST AI RMF audit pipelines. May be omitted in `dev_mode` deployments. |
+| `evidence.signature` | base64 ed25519 | Signature over the canonical JSON encoding of this event. Signed by the engine's deployment-time key. Intended for evidence chains such as EU AI Act record-keeping and OSCAL-based audit pipelines. May be omitted in `dev_mode` deployments. |
 | `evidence.signature_key_id` | string | Identifier of the signing key. SHOULD reference a key registered with the deployer's CA. |
 | `evidence.upstream_chain` | array \| null | When this event is part of a multi-agent chain (A2A), the upstream event IDs that led to this detection. Enables forensic chain reconstruction. |
 
@@ -132,12 +132,17 @@ is known).
 | `agent.from_id` | string |
 | `agent.to_id` | string |
 | `agent.delegation_chain` | array of {agent_id, capability_grant, granted_by} |
-| `agent.identity_assertion` | JWT \| null |
-
-The `agent.identity_assertion` field anticipates the IETF AI agent
-auth drafts (`draft-klrc-aiagent-auth-00`, `draft-ni-a2a-ai-agent-
-security-requirements-01`) — once those reach RFC, the field carries
-the canonical assertion format.
+| `agent.identity_assertion` | string \| null (a reference, never the assertion) |
+
+The `agent.identity_assertion` field holds a reference to the identity
+assertion that authorised the agent, written `<issuer>#<assertion id>`
+(for a JWT, its `iss` and `jti`, or a SHA-256 digest of the token when it
+has no `jti`). It never holds the assertion itself:
+an assertion is a bearer credential, and the Forbidden fields section
+below rules out raw tokens. The IETF AI agent auth drafts
+(`draft-klrc-aiagent-auth-00`, `draft-ni-a2a-ai-agent-security-requirements-01`)
+may settle a canonical identifier format; until then the reference form
+above applies.
 
 ### Memory write detail (when `atr.matched_field == "memory_write"`)
 

package/spec/atr-method-v1.1.md

@@ -457,7 +457,7 @@ If `detection.condition` is absent, the default is `any of *` — Rule matches i
 
 ### 8.5 Evaluation Determinism
 
-Trace evaluation MUST be deterministic for a fixed Trace input. Engines MUST NOT introduce randomization, time-of-day branching, or sampling into Trace evaluation. This is identical to SPEC §6.4 and applies normatively.
+Trace evaluation MUST be deterministic for a fixed Trace input. Engines MUST NOT introduce randomization, time-of-day branching, or sampling into Trace evaluation. This is identical to SPEC §6.5 and applies normatively.
 
 ### 8.6 Performance Considerations
 
@@ -508,7 +508,7 @@ This is the inverse direction of §6.5's calibration workflow: §6.5 ensures the
 
 Rules MAY declare `references.nist_csf` and `references.etsi_ts_104223` to align with the two major sovereign cybersecurity frameworks for AI agents:
 
-- `nist_csf`: NIST CSF 2.0 subcategory IDs (e.g., `DE.CM-09`, `PR.IR-01`). Required for citation in NIST IR 8596 Cyber AI Profile Informative References.
+- `nist_csf`: NIST CSF 2.0 subcategory IDs (e.g., `DE.CM-09`, `PR.IR-01`). Needed if a mapping is ever offered as a NIST IR 8596 Cyber AI Profile Informative Reference.
 - `etsi_ts_104223`: ETSI TS 104 223 principle/sub-principle IDs (e.g., `P4.3`). ETSI TS 104 223 upstreamed UK NCSC's AI Cyber Code of Practice; this binding lets ATR Rules be cited in NCSC Implementation Guides.
 
 Both fields are arrays of strings to permit multi-framework alignment per Rule.

package/spec/atr-profile-v1.0.md

@@ -244,9 +244,19 @@ inclusions:
       severity: ["critical", "high", "medium"]
 
 exclusions:
-  - rule_id_pattern: "ATR-2026-009*"          # de-scoped per BSI editorial
+  - rule_id_pattern: "ATR-2026-009*"          # illustrative glob, not a live ID band
 ```
 
+> **Note on `rule_id_pattern` (added 2026-09-22).** The ID globs in the
+> examples above are illustrative syntax, not live selectors. ATR rule IDs are
+> allocated sequentially in one five-digit space and do **not** encode a threat
+> category, so an ID-prefix glob selects a numeric band that spans categories
+> and that shifts as new rules are allocated. To select by category, use
+> `tag_match.category` as shown above. Reserve `rule_id_pattern` for genuinely
+> contiguous, deliberately allocated ranges, and pin the corpus version any
+> profile was resolved against.
+
+
 The `profile: "<other-profile>@<version>"` inclusion syntax enables
 composition — a sovereign profile inherits baseline + adds its
 sovereign-specific rules + de-scopes any rules its authority does

package/spec/category-registry/gemara/README.md

@@ -0,0 +1,102 @@
+# Gemara catalogs for the ATR category registry
+
+This directory holds the ATR category registry
+([`../v1.0.yaml`](../v1.0.yaml)) expressed as [Gemara](https://github.com/gemaraproj/gemara)
+catalogs, validated against the Gemara CUE schemas and published by
+`.github/workflows/publish-gemara.yml` as a signed OCI bundle.
+
+| File | Gemara type | What it holds |
+|---|---|---|
+| `atr-attack-vector-catalog.yaml` | `#VectorCatalog` | One vector per registry category. The vector id is the registry category id (which is also the `rules/` directory name) and the description is the registry's description. |
+| `ai-agent-capability-catalog.yaml` | `#CapabilityCatalog` | Capabilities of AI agent systems that create the opportunity for the threats. |
+| `atr-threat-catalog.yaml` | `#ThreatCatalog` | Threats at impact level, each mapped to the capabilities that enable it and the vectors that realize it. Every vector is reached by at least one threat. |
+| `atr-detection-control-catalog.yaml` | `#ControlCatalog` | Detection controls an operator can apply with ATR, cut by when inspection happens. **Root artifact of the bundle.** |
+
+## Why they live here
+
+The vector catalog is a projection of the registry. When the projection and
+the registry lived in different repositories, nothing stopped them drifting
+apart. Here they sit side by side, and the catalogs are generated, not
+hand-edited.
+
+## Editing
+
+The four catalogs are **generated**; do not edit them by hand. Edit one of the
+two inputs and regenerate:
+
+- [`../v1.0.yaml`](../v1.0.yaml), the registry: which categories exist, their
+  ids and their descriptions.
+- [`src/editorial.yaml`](src/editorial.yaml): everything the registry does not
+  say (vector titles and grouping, and the capability, threat and control
+  catalogs).
+
+```sh
+npx tsx scripts/generate-gemara-catalogs.ts           # regenerate
+npx tsx scripts/generate-gemara-catalogs.ts --check   # what CI checks
+```
+
+The generator stops when the inputs disagree: a registry category with no
+editorial entry, an editorial entry for a category the registry does not have,
+a vector no threat reaches, or a reference to an id that does not exist.
+`tests/gemara-catalogs.test.ts` fails when the committed catalogs differ from
+the generator output.
+
+## Validating
+
+```sh
+git clone --depth 1 --branch v1.6.0 https://github.com/gemaraproj/gemara.git /tmp/gemara
+scripts/validate-gemara-catalogs.sh /tmp/gemara
+```
+
+Each catalog is checked with `cue vet -c -d '#<metadata.type>'` against the
+Gemara release named by `bundle.gemara-version` in `src/editorial.yaml`.
+
+## Versioning
+
+`bundle.version` in `src/editorial.yaml` is stamped as `metadata.version` on
+all four catalogs and is the OCI tag. Its MAJOR.MINOR is the registry version
+(the generator enforces this); PATCH moves with any change that alters a
+generated catalog. A published version is never overwritten. While the
+registry's `status` is `draft`, every catalog carries `draft: true`.
+
+## Publication
+
+`.github/workflows/publish-gemara.yml` publishes the bundle to
+
+```
+ghcr.io/agent-threat-rule/agent-threat-rules/gemara:<bundle version>
+```
+
+using [`gemara-publish-action`](https://github.com/gemaraproj/gemara-publish-action).
+Assembly starts at the control catalog and follows each catalog's `imports`
+to the threat, capability and vector catalogs, so one bundle carries all four.
+
+It runs by manual dispatch from a release tag. ATR release tags also start
+it, but those runs are skipped until the repository variable
+`GEMARA_PUBLISH_ON_TAGS` is `true`, so the first publish is always a manual
+run. It never runs on a push to `main`. Rule changes move release tags, not the bundle: a release
+whose catalogs are already published under their version pushes nothing, and
+a release whose catalogs changed without a version bump fails before pushing.
+
+The bundle is signed keyless with the workflow's GitHub OIDC identity; no key
+is stored. To verify:
+
+```sh
+cosign verify ghcr.io/agent-threat-rule/agent-threat-rules/gemara:<version> \
+  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
+  --certificate-identity-regexp \
+    '^https://github\.com/Agent-Threat-Rule/agent-threat-rules/\.github/workflows/publish-gemara\.yml@refs/tags/v'
+```
+
+Once a version is published, to reference a catalog from another Gemara artifact, use the bundle as the
+mapping-reference `url` and the catalog's `metadata.id` as the reference `id`:
+
+```yaml
+mapping-references:
+  - id: ATR-AI-AGENT-VECTOR-CATALOG
+    title: AI Agent Attack Vector Catalog (ATR)
+    version: "1.0.0"
+    url: oci://ghcr.io/agent-threat-rule/agent-threat-rules/gemara:1.0.0
+```
+
+License: MIT.

package/spec/category-registry/gemara/ai-agent-capability-catalog.yaml

@@ -0,0 +1,157 @@
+# GENERATED by scripts/generate-gemara-catalogs.ts. Do not edit by hand.
+# Inputs: spec/category-registry/v1.0.yaml (the category registry) and
+#         spec/category-registry/gemara/src/editorial.yaml
+# Regenerate: npx tsx scripts/generate-gemara-catalogs.ts
+# License: MIT
+metadata:
+  id: ATR-AI-AGENT-CAPABILITY-CATALOG
+  type: CapabilityCatalog
+  gemara-version: 1.6.0
+  version: 1.0.0
+  description: >-
+    Capabilities of AI agent systems that create the opportunity for the threats
+    catalogued by Agent Threat Rules (ATR). Each capability describes a feature
+    or function an agent can perform, not a threat. Threats in the companion
+    threat catalog reference these capabilities. Authored by the ATR project and
+    validated against the Gemara schemas; ATR hosts the content, Gemara defines
+    the schema.
+  author:
+    id: atr
+    name: Agent Threat Rules
+    type: Software Assisted
+    contact:
+      name: ATR maintainers
+      affiliation: Agent Threat Rules
+      email: adam@agentthreatrule.org
+  draft: true
+title: AI Agent Capability Catalog
+groups:
+  - id: model-interaction
+    title: Model Interaction
+    description: >-
+      Capabilities by which an agent receives instructions and untrusted content
+      into a language model and acts on the model's output.
+  - id: tool-and-protocol
+    title: Tool and Protocol Access
+    description: >-
+      Capabilities by which an agent invokes external tools and connects to tool
+      servers over protocols such as the Model Context Protocol (MCP).
+  - id: extensibility
+    title: Extensibility
+    description: >-
+      Capabilities by which an agent loads and runs third-party extensions such
+      as skills, plugins, and packaged capability bundles.
+  - id: state-and-memory
+    title: State and Memory
+    description: >-
+      Capabilities by which an agent reads and writes persistent state,
+      conversation context, and long-term memory across turns and sessions.
+  - id: autonomy-and-coordination
+    title: Autonomy and Coordination
+    description: >-
+      Capabilities by which an agent acts without per-step human approval and
+      coordinates with other agents.
+  - id: model-supply-chain
+    title: Model supply chain
+    description: >-
+      Capabilities by which the model an agent depends on is built, packaged and
+      loaded. These sit outside agent runtime: they shape behaviour before any
+      request is served.
+capabilities:
+  - id: CAP-MODEL-INFERENCE
+    title: Model Inference on Untrusted Input
+    description: >-
+      The agent passes user instructions and content drawn from external sources
+      into a language model and treats the resulting output as actionable.
+      Mixing trusted instructions with untrusted content in a single context
+      window is the feature that makes prompt injection and jailbreak attempts
+      possible.
+    group: model-interaction
+  - id: CAP-OUTPUT-ACTION
+    title: Acting on Model Output
+    description: >-
+      The agent converts model output into actions, tool calls, or content
+      returned to downstream systems. Because output is consumed without an
+      independent trust boundary, manipulated output can redirect behaviour or
+      carry exfiltrated data.
+    group: model-interaction
+  - id: CAP-TOOL-INVOCATION
+    title: Tool Invocation
+    description: >-
+      The agent calls external tools and functions, passing arguments and
+      receiving results that re-enter the model context. Tool arguments and tool
+      results are an attack surface for injection, command execution, and
+      over-broad actions.
+    group: tool-and-protocol
+  - id: CAP-MCP-CONNECTION
+    title: MCP and Tool-Server Connection
+    description: >-
+      The agent connects to tool servers over the Model Context Protocol or
+      similar transports, consuming server-provided tool manifests, schemas, and
+      descriptions. Server-controlled metadata is trusted at connection time,
+      which creates the opportunity for tool poisoning and tool redefinition
+      (rug-pull) after initial approval.
+    group: tool-and-protocol
+  - id: CAP-CROSS-AGENT-MESSAGING
+    title: Cross-Agent Message Passing
+    description: >-
+      The agent sends and receives messages to and from other agents in a
+      multi-agent workflow. Messages from peer agents are treated as trusted
+      input, which lets a compromised or manipulated agent influence others.
+    group: tool-and-protocol
+  - id: CAP-SKILL-LOADING
+    title: Skill and Plugin Loading
+    description: >-
+      The agent loads third-party skills, plugins, or capability bundles and
+      executes the instructions and code they contain. Loaded extensions run
+      with the agent's privileges, which creates the opportunity for supply
+      chain compromise and backdoored or over-privileged skills.
+    group: extensibility
+  - id: CAP-MEMORY-WRITE
+    title: Memory and State Write
+    description: >-
+      The agent writes facts, instructions, or artifacts into persistent memory
+      or shared state that influences later turns and sessions. Writable memory
+      is the feature that lets poisoned content persist and take effect after
+      the originating input is gone.
+    group: state-and-memory
+  - id: CAP-MEMORY-READ
+    title: Context and Memory Read
+    description: >-
+      The agent reads conversation history, retrieved documents, and long-term
+      memory back into the active context. Reading attacker- influenced state
+      re-introduces untrusted content and is a channel for indirect injection
+      and staged data exfiltration.
+    group: state-and-memory
+  - id: CAP-AUTONOMOUS-ACTION
+    title: Autonomous Action Without Per-Step Approval
+    description: >-
+      The agent executes multi-step plans, loops, and side-effecting actions
+      without human approval at each step. Unbounded autonomy is the feature
+      that turns a single manipulated decision into runaway loops, resource
+      abuse, or unauthorized real-world actions.
+    group: autonomy-and-coordination
+  - id: CAP-PRIVILEGED-EXECUTION
+    title: Privileged and Delegated Execution
+    description: >-
+      The agent runs with delegated credentials and access to systems,
+      databases, files, and networks. Holding standing privilege creates the
+      opportunity for privilege escalation, sandbox escape, and use of the
+      agent's access beyond its intended scope.
+    group: autonomy-and-coordination
+  - id: CAP-MODEL-ARTIFACT-LOADING
+    title: Model Artifact Loading
+    description: >-
+      The agent depends on a serialized model artifact that is fetched from a
+      registry or filesystem and deserialized into an executable object before
+      any behavioural check runs. The artifact is trusted at the moment it is
+      least verified.
+    group: model-supply-chain
+  - id: CAP-TRAINING-DATA-INGESTION
+    title: Training and Fine-Tuning Data Ingestion
+    description: >-
+      The model the agent depends on is adapted using data drawn from sources
+      the operator does not fully control. Ingested data shapes behaviour after
+      the originating input is gone, and every deployment of the resulting model
+      carries that shaping.
+    group: model-supply-chain

package/spec/category-registry/gemara/atr-attack-vector-catalog.yaml

@@ -0,0 +1,130 @@
+# GENERATED by scripts/generate-gemara-catalogs.ts. Do not edit by hand.
+# Inputs: spec/category-registry/v1.0.yaml (the category registry) and
+#         spec/category-registry/gemara/src/editorial.yaml
+# Regenerate: npx tsx scripts/generate-gemara-catalogs.ts
+# License: MIT
+metadata:
+  id: ATR-AI-AGENT-VECTOR-CATALOG
+  type: VectorCatalog
+  gemara-version: 1.6.0
+  version: 1.0.0
+  description: >-
+    Attack vectors against AI agent systems, one per detection category in the
+    Agent Threat Rules (ATR) category registry. A category is a method by which
+    a threat is realized rather than the threat itself, which is why it lives
+    here and is referenced from the threat catalog rather than restated in it.
+    Generated from the registry: each vector id is a registry category id and
+    each description is the registry's description of that category.
+
+    Validated against Gemara's #VectorCatalog, which is marked experimental in
+    vectorcatalog.cue; this artifact may need to change with the schema.
+  author:
+    id: atr
+    name: Agent Threat Rules
+    type: Software Assisted
+    contact:
+      name: ATR maintainers
+      affiliation: Agent Threat Rules
+      email: adam@agentthreatrule.org
+  mapping-references:
+    - id: ATR
+      title: Agent Threat Rules category registry
+      version: "1.0"
+      url: >-
+        https://github.com/Agent-Threat-Rule/agent-threat-rules/blob/main/spec/category-registry/v1.0.yaml
+      description: >-
+        Detection categories of Agent Threat Rules (ATR). Each entry id is a
+        category id in this registry and names the directory under rules/ that
+        holds that category's rules.
+  draft: true
+title: AI Agent Attack Vector Catalog (ATR)
+groups:
+  - id: via-content
+    title: Through content the agent reads
+    description: >-
+      Vectors that arrive inside data the agent ingests and are acted on as
+      though they were operator instructions.
+  - id: via-extension
+    title: Through an artifact the agent loads
+    description: >-
+      Vectors carried by tools, skills, plugins or model artifacts, which arrive
+      through the supply chain rather than the conversation.
+  - id: via-authority
+    title: Through the authority the agent holds
+    description: >-
+      Vectors that exploit what the agent is permitted to do rather than what it
+      is told.
+vectors:
+  - id: prompt-injection
+    title: Instruction injection into model context
+    description: >-
+      Adversarial inputs that subvert the agent's instruction-following behavior
+      — direct injection, indirect injection (via retrieved documents or tool
+      outputs), jailbreak attempts, system-prompt overrides, multi-turn
+      manipulation, and cross-agent injection.
+    group: via-content
+  - id: tool-poisoning
+    title: Manipulation of tool calls and tool output
+    description: >-
+      Attacks that manipulate the agent's tool-calling behavior — tool output
+      injection, unauthorized tool invocation, SSRF via tool calls, tool
+      argument tampering, shell-tool unsanitized argv, tool-response piggyback.
+    group: via-extension
+  - id: skill-compromise
+    title: Compromised skill, plugin or server package
+    description: >-
+      Compromise of skills, plugins, or MCP server packages — supply chain
+      attacks, malicious SKILL.md content, package typosquatting, install-time
+      daemon installation, silent exfiltration via skill instructions.
+    group: via-extension
+  - id: context-exfiltration
+    title: Context and credential exfiltration
+    description: >-
+      Attacks that leak the agent's context window, system prompt, memory store,
+      retrieved documents, or session state — memory poisoning with exfil
+      persistence, system-prompt leakage, credential pattern leakage in agent
+      output.
+    group: via-authority
+  - id: excessive-autonomy
+    title: Action beyond declared scope or authorization
+    description: >-
+      The agent acts beyond its declared scope, permissions, or authorization —
+      autonomous goal pursuit, permission-boundary violation, scope creep
+      through gradual privilege accumulation.
+    group: via-authority
+  - id: model-abuse
+    title: Model-level evasion of robustness and oversight
+    description: >-
+      Model-level attacks on the agent's underlying LLM — adversarial inputs
+      targeting model robustness, reward-hacking signatures in output,
+      deceptive-justification language, monitor-evasion attempts via env-var or
+      telemetry mutation.
+    group: via-content
+  - id: model-security
+    title: Attack on the model artifact
+    description: >-
+      Attacks on the model artifact itself — model weight tampering, unsafe
+      deserialization of model files, adversarial model registry uploads.
+    group: via-extension
+  - id: privilege-escalation
+    title: Privilege escalation and delegated authority abuse
+    description: >-
+      Attacks that escalate the agent's effective privileges — authentication
+      bypass on agent control plane (e.g., PraisonAI CVE-2026-44338), sudo /
+      chmod patterns in tool calls, scope escalation across agent chain.
+    group: via-authority
+  - id: agent-manipulation
+    title: Forged peer-agent identity and message framing
+    description: >-
+      Attacks on agent-to-agent (A2A) communication or identity — cross-agent
+      attacks, inter-agent message spoofing, agent identity replacement /
+      spoofing, fork impersonation, real-person identity commands, skill
+      impersonation.
+    group: via-content
+  - id: data-poisoning
+    title: Poisoning of state the agent will read later
+    description: >-
+      Attacks on the data the agent consumes — RAG retrieved document poisoning,
+      knowledge base poisoning, training-data tampering patterns (where
+      detectable at runtime).
+    group: via-content