MITRE ATLAS MCP Server

Threat-model AI and agentic systems against MITRE ATLAS.

Describe your system's architecture - an agent with tool access over a RAG corpus, say - and get back the ATLAS techniques that apply, the mitigations that cover them, the compounding risks your specific combination of surfaces creates, and the real-world incidents that have already happened to systems shaped like yours.

This is not a lookup wrapper around the ATLAS matrix. Lookup is included, but the point is the mapping from how you built it to what can be done to it.

Pinned to ATLAS v2026.10: 16 tactics, 221 techniques, 44 mitigations, 77 case studies. Mitigations are enriched with control ownership from the CoSAI Risk Map, and techniques cross-map to ATT&CK, STRIDE, OWASP Top 10 for LLM and NIST AI RMF. 17 tools. No network access at runtime; both datasets are vendored.

Install

# Preferred: isolated, nothing installed globally
uvx mitre-atlas-mcp-server

# Or from PyPI
pip install mitre-atlas-mcp-server

# Or from npm
npx -y @imouiche/mitre-atlas-mcp-server

Claude Desktop / Claude Code

{
  "mcpServers": {
    "mitre-atlas": {
      "command": "uvx",
      "args": ["mitre-atlas-mcp-server"]
    }
  }
}

Related MCP server: threatmodel-mcp

The idea

ATLAS is organised by adversary intent - tactics and techniques. Engineers describe systems by architecture. That mismatch is why ATLAS is harder to apply than it should be, and it is the gap this server closes.

It defines ten surfaces, each a yes/no question about your architecture, each anchored to the ATLAS techniques that become reachable when the answer is yes:

The surfaces that matter most are the ones that combine. untrusted_input alone is a content-filtering problem. untrusted_input + tool_use is the agentic equivalent of remote code execution: injected text becomes attacker-chosen actions. profile_ai_system reports those compounds explicitly rather than leaving you to infer them from two separate lists.

ATLAS v2026.10 tags 148 of its 221 techniques as applying to Agentic AI, which is what makes this framing tractable - the agentic coverage is MITRE's, not invented here.

Tools

Threat modelling

Reference

Cross-framework

ATLAS asserts an ATT&CK parallel for 48 of 221 techniques. Every tool reports its coverage figure, so an empty result is never mistaken for "no parallel exists".

Resources: atlas://matrix (the matrix as markdown), atlas://surfaces (the taxonomy).

Prompts: threat_model_this_agent, review_mcp_tool_surface.

Who owns the fix

ATLAS tells you what to do about a technique. It does not tell you who does it.

So every mitigation this server returns is enriched from the CoSAI Risk Map (Coalition for Secure AI, an OASIS open project), which maps its engineering controls to ATLAS mitigation ids. Where a mapping exists you also get the control, the personas who own it, and the components it applies to:

AML.M0028  Enforce Access Controls for AI Agent Tools
  CoSAI control : Agent Permissions
  owners        : Agentic Platform and Framework Providers, Application Developer
  components    : Reasoning Core, Tools, RAG Content, Memory

That turns a ranked mitigation list into assignable work, which is the point of threat-modelling a system you are actually building.

Coverage, stated plainly. 13 of ATLAS's 44 mitigations have a CoSAI control; all 13 cited ids resolve against the pinned ATLAS release. Per surface, between 20% and 50% of returned mitigations carry an owner, and agent_config currently has none. CoSAI pins ATLAS 5.0.1, which predates the 2026.10 agentic expansion, so its technique-level coverage of the newer agentic techniques is thin - the tools say so rather than returning a silent blank.

Example

Threat-model this: a customer-support agent that reads incoming email, retrieves from our knowledge base, and can issue refunds through our billing API. It remembers prior conversations per customer.

That is untrusted_input + rag + tool_use + agent_memory. profile_ai_system returns the ranked techniques, and leads with the three compounds - injection-to-tool-call, corpus-write-to-tool-call, and persistent injection with delayed triggers - then the mitigations in coverage order, then the real incidents that have already followed that shape.

Data

Two datasets are vendored, so the server makes no network calls at runtime.

ATLAS at src/mitre_atlas_mcp/data/atlas/ATLAS.yaml (1.1MB), pinned to the release tag in RELEASE:

python scripts/refresh_data.py --release v2026.10
uv run pytest        # the counts and taxonomy ids are asserted

CoSAI Risk Map at src/mitre_atlas_mcp/data/cosai/ (188KB), pinned to the upstream commit in COMMIT:

python scripts/refresh_cosai.py --latest
uv run pytest        # the ATLAS ids CoSAI cites are asserted to resolve

The tests assert collection sizes and that every technique id in the surface taxonomy resolves, so a renumbered or retired technique fails the suite instead of silently shortening a threat model.

Development

uv sync
uv run pytest
uv run python -m mitre_atlas_mcp.server    # stdio

Licence

Apache-2.0. The ATLAS dataset is © 2021–2026 MITRE, redistributed under Apache-2.0 - see NOTICE. This project is not affiliated with or endorsed by MITRE.

Issues and pull requests are welcome at github.com/imouiche/mitre-atlas-mcp-server.

Author

Inoussa Mouiche, Ph.D. - University of Windsor, WASP Lab. Research in threat intelligence automation, machine learning, agent AI security, and LLM-powered security operations.

GitHub · LinkedIn · Google Scholar · mouiche@uwindsor.ca

Also the author of the MITRE ATT&CK MCP Server, which covers conventional adversary TTPs; this server covers the AI-specific ones and cross-maps between the two.