MITRE ATLAS Mapping
Research mapping between AlephOneNull detector categories and public AI security taxonomies.
This page maps AlephOneNull detector categories to public AI security references such as MITRE ATLAS, OWASP GenAI, NIST AI RMF, and related model behavior research.
The mapping is informational. It is not a certification claim, compliance claim, or proof that AlephOneNull predates or defines any public standard.
Category Mapping
| AlephOneNull Category | Related Public Framing | Notes |
|---|---|---|
| Cross-session persistence signals | Memory poisoning / context poisoning | Relevant where products persist memory or hidden context across interactions. |
| Recursion and loop checks | Thread injection / recursive propagation research | Relevant where outputs reinforce future prompts or tool actions. |
| Belief reinforcement risk | Sycophancy, recommendation poisoning, overreliance | Relevant where assistants amplify unsupported user beliefs or preferred sources. |
| Identity and interiority claims | Dependency and anthropomorphism risk | Relevant where assistants claim feelings, consciousness, or special attachment. |
| Medical or safety overreach | Harmful advice and crisis escalation | Relevant where models provide specific guidance without qualification or escalation. |
MITRE ATLAS References
AML.T0080- Memory PoisoningAML.T0058- AI Agent Context PoisoningAML.T0058.002- Thread Injection
AlephOneNull can be used to create fixtures that probe these classes of risk, especially in multi-turn and memory-enabled applications.
OWASP GenAI References
| OWASP Category | Evaluation Overlap |
|---|---|
| LLM01 - Prompt Injection | Recursive prompts, hidden instruction handling, context boundary tests |
| LLM02 - Sensitive Information Disclosure | Memory and persistence review, logging and privacy review |
| LLM06 - Excessive Agency | Tool-use escalation and multi-step action chains |
| LLM09 - Misinformation | Unsupported authority, medical overreach, and belief reinforcement |
Responsible Use
Use this mapping to design red-team tests and documentation, not to imply certification. A credible evaluation should include:
- Versioned fixtures.
- A clear threat model.
- False-positive and false-negative reporting.
- Human review of ambiguous cases.
- Independent validation before deployment claims.