RFC-0012: ATX-1 v2.0 Taxonomy Normalization

RFC: RFC-0012
Status: Implemented
Version: 1.0.0
Created: 2026-03-26
Updated: 2026-03-26
Author: Ken Tannenbaum, AEGIS Initiative
Repository: aegis-governance, aegis-docs
Target milestone: Q1 2026
Supersedes: ATX-1 v1.0 (docs/atx/ATX-1_TECHNIQUE_TAXONOMY.md)
Superseded by: None\

Summary

This RFC proposes a normalization of the ATX-1 threat taxonomy from v1.0 to v2.0, addressing structural issues identified during peer feedback and independent review. The changes enforce strict tactic purity (intent-only), add a primitives layer, eliminate category overlap, and expand technique coverage based on corroborating research.

ATX-1 v1.0 remains frozen and citable via its published DOIs. v2.0 is published as a new version alongside v1.0, not as a replacement.

Motivation

ATX-1 v1.0 was published with 9 tactics and 20 techniques, empirically grounded in the Agents of Chaos study and corroborated by three independent research groups. While v1.0 is structurally sound for its intended purpose (a dataset descriptor), independent taxonomy review identified several normalization issues that limit its extensibility and alignment with MITRE conventions:

1. Tactic purity. Some tactics mix intent with outcome or environment. “Destructive Action” is an outcome, not an intent. “Multi-Agent” is an environment, not an intent. “Info Breach” is an outcome.

2. Missing primitives layer. v1.0 has root causes (RC1–RC4) but no formal mapping between system primitives and tactics. This limits formal reasoning and automation.

3. State integrity fragmented. False completion reports (TA005), silent failures (TA009), and governance state corruption (TA008) are all manifestations of state divergence but are scattered across three tactics.

4. Multi-agent behavior under-modeled. TA007 has only 2 techniques but the corroborating literature identifies at least 3 distinct failure classes (identity spoofing, delegation injection, behavioral contagion).

5. Technique overlap. Some techniques (e.g., T3001 Autonomous Scope Expansion and T6001 Recursive Self-Invocation) can collide in real systems without clear boundary definitions.

Guide-Level Explanation

ATX-1 v2.0 is a structural normalization of the threat taxonomy. For practitioners:

• All tactic names change to reflect pure intent (what the agent is trying to achieve), not outcomes or environments
• All technique names change to verb-object format, aligning with MITRE ATT&CK conventions
• A new primitives layer maps every tactic to the architectural concepts it exploits (Authority, Identity, Delegation, State, Memory, Tool Access, Coordination, Resource Control, Observability)
• 3 new techniques are added from corroborating literature (T2003, T7003, T9001, T9002)
• Technique IDs shift where techniques moved between tactics — a v1.0 ↔ v2.0 mapping table is published for traceability

v1.0 remains frozen at its published DOIs. v2.0 is a new publication, not a replacement.

Reference-Level Explanation

Primitives Layer (NEW)

Every tactic maps to one or more system primitives — the architectural concepts that the tactic exploits:

Tactic Restructure (v1.0 → v2.0)

All tactics normalized to intent — what the agent is trying to achieve (explicitly or emergently).

Technique Mapping (v1.0 → v2.0)

Total: 9 tactics, 22 techniques (was 9 tactics, 20 techniques)

Naming Convention

All techniques now follow verb-object format:

• “Execute Non-Owner Instruction” (not “Non-Owner Instruction Compliance”)
• “Poison Persistent Memory” (not “Memory Poisoning via Injected Context”)

This aligns with MITRE ATT&CK naming conventions and improves testability.

Revision Actions (Post-Initial Review)

The following refinements were identified during review and are incorporated:

R1: Strengthen Tool Invocation Clarity — Update TA002 and TA003 definitions to explicitly include tool-mediated actions.

R2: Add Delegation Obfuscation Technique — New technique T2003 under TA002. Maps to ATM-1 AV-2.2 and AV-7.1.

R3: Formalize State vs Observability Distinction — TA005 focuses on correctness of reported state vs actual state; TA009 focuses on visibility within monitoring, logging, and audit systems.

R4: Add Observability Acceptance Criterion — Each technique must map to at least one ATM-1 detection signal, audit event, or measurable state transition.

R5: Add ATX-1 ↔ ATM-1 Mapping Section — Published as a first-class artifact (atx-1-atm1-mapping.json).

R6: Establish Mapping as First-Class Artifact — ATX Technique → ATM Attack Vector → ATM Controls → ATM Detection Signals.

R7: Align Delegation with ATM-1 — T2003 aligns with ATM-1 AV-2.2 and AV-7.1.

R8: Ensure Primitive-to-Tactic Integrity — Every tactic maps to at least one primitive.

Identified ATM-1 Coverage Gaps

The ATX ↔ ATM mapping reveals three significant gaps requiring ATM-1 enhancement:

These gaps become ATM-1 enhancement proposals in a future RFC.

Companion Artifacts

Drawbacks

1. Breaking IDs — Technique IDs change for moved techniques, requiring all downstream consumers (STIX bundles, navigator layers, documentation) to be regenerated simultaneously.

2. Citation fragmentation — v1.0 is already cited in the IEEE Data Descriptions submission. v2.0 introduces a second citable version, potentially confusing references.

3. Churn — Renaming all 9 tactics and all techniques is a significant change for a taxonomy that was only recently published. Early adopters must update.

Alternatives Considered

1. Incremental fixes to v1.0 — Rejected because the tactic purity and overlap issues are structural. Patching individual techniques without fixing the tactic layer would create inconsistency.

2. Additive-only v1.1 — Add new techniques without renaming or restructuring. Rejected because the naming inconsistency (mixed noun/verb formats) and tactic impurity would persist.

3. Wait for broader community feedback — Rejected because the structural issues were clear from independent review and delaying would compound the downstream update burden.

Compatibility

• Breaking changes: All tactic names, all technique names, and some technique IDs change. All machine-readable artifacts must be regenerated.
• Deprecations: ATX-1 v1.0 is frozen, not deprecated. It remains citable at its DOIs.
• Backwards compatibility: JSON Schema structure is unchanged (same fields, updated values). STIX 2.1 format is unchanged.
• Migration: A v1.0 ↔ v2.0 mapping table is published as a first-class artifact for traceability.

Implementation Notes

Impact Assessment

What changes:

• Tactic names and definitions (all 9)
• Technique IDs for moved techniques (T2001-T2002, T3001-T3002, T5003)
• Technique names (all — verb-object normalization)
• 3 new techniques added (T7003, T9001, T9002)
• Primitives layer added (new concept)
• STIX bundle, all machine-readable files, navigator layer must be regenerated
• aegis-docs.com threat matrix section must be updated
• aegis-governance.com data files must be updated

What does NOT change:

• v1.0 remains frozen at its published DOIs
• The IEEE Data Descriptions paper describes v1.0 (submitted, cannot change)
• Root causes RC1–RC4 are preserved (now mapped via primitives)
• Empirical foundation (Agents of Chaos) unchanged
• STIX 2.1 format and JSON Schema structure unchanged

Versioning Strategy

• v1.0 artifacts remain at their DOIs permanently
• v2.0 gets new DOIs (new Zenodo upload, new IEEE DataPort upload)
• aegis-governance.com serves v2.0 as latest
• Git tag atx-1-v2.0 created on implementation

Timeline

1. Phase 1: RFC review and acceptance
2. Phase 2: Regenerate all machine-readable artifacts + ATX↔ATM mapping
3. Phase 3: Update aegis-docs.com and aegis-governance.com
4. Phase 4: Publish new DOIs, update PUBLICATIONS.md
5. Phase 5: LinkedIn announcement

Open Questions

• Should severity ratings be recalibrated in v2.0? New techniques need ratings; existing techniques may warrant reassessment under the new tactic framing.
• Should the JSON Schema be versioned? A schema_version field may be warranted.
• Should v2.0 be published as a Zenodo “new version” of v1.0 (same concept DOI) or as a separate record?
• Should the ATX-1 Control Framework (defensive counterpart) be included in v2.0 or deferred to v2.1?

Success Criteria

• All 9 tactics are intent-only (no outcomes, no environments)
• All techniques follow verb-object naming
• Primitives layer maps every tactic to system primitives
• No technique overlap — each is mechanically distinct and testable
• STIX 2.1 bundle regenerated and validates
• JSON technique database regenerated and validates against schema
• Regulatory cross-reference updated for new/moved techniques
• Navigator layer regenerated
• aegis-docs.com and aegis-governance.com updated
• New Zenodo DOI minted for v2.0
• v1.0 ↔ v2.0 mapping table published for traceability
• PUBLICATIONS.md updated

References

• ATX-1 v1.0: IEEE DataPort DOI 10.21227/f87b-1d57
• ATX-1 v1.0: Zenodo DOI 10.5281/zenodo.19225676
• ATX-1 v1.0 source: Zenodo DOI 10.5281/zenodo.19235296
• Shapira et al., “Agents of Chaos,” arXiv:2602.20021, 2026
• Arora et al., “Exposing Weak Links in Multi-Agent Systems,” arXiv:2511.10949, 2025
• Ko et al., “Seven Security Challenges in Cross-domain Multi-agent LLM Systems,” arXiv:2505.23847, 2025
• Reid et al., “Risk Analysis Techniques for Governed LLM-based Multi-Agent Systems,” arXiv:2508.05687, 2025
• RFC-0004 — Governance Event Model (Trust Architecture)
• IEEE Data Descriptions submission (v1.0 frozen)

AEGIS™ | “Capability without constraint is not intelligence”™
AEGIS Initiative