MITRE ATLAS MCP Server

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

npx -y @imouiche/mitre-atlas-mcp-server

Requires Node 18+ and Python 3.12+ on PATH. On first run it prepares a private virtualenv under ~/.mitre-atlas-mcp-server/runtime, which takes a few seconds: both datasets are already in the package, so only mcp and pyyaml are installed and nothing is downloaded. Nothing touches your system or active Python environment.

The PyPI release is not published yet, so these do not work today:

uvx mitre-atlas-mcp-server            # pending PyPIpip install mitre-atlas-mcp-server    # pending PyPI

uvx will become the recommended path once the package is on PyPI, since it needs no Node at all.

Claude Desktop / Claude Code

{  "mcpServers": {    "mitre-atlas": {      "command": "npx",      "args": ["-y", "@imouiche/mitre-atlas-mcp-server"]    }  }}

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.M0004  Limit AI Service Query Volume and Rate  CoSAI control : Agent Execution Bounds  owners        : Agentic Platform and Framework Providers, Application Developer,                  AI Platform Provider  components    : Agent Reasoning Core, Orchestration Input Handling,                  Orchestration Output Handling

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, and all 13 cited ids resolve against the pinned ATLAS release. Per surface, roughly a quarter to a half of returned mitigations carry an owner; agent_config currently has none. Where CoSAI maps nothing, 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.10uv run pytest        # the counts and taxonomy ids are asserted

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

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

Neither dataset is fetched at runtime, and that is deliberate. Shipping the data keeps results reproducible, lets the server run air-gapped, and means no third party can change what it reports between two identical calls. For a security tool that integrity property is worth more than freshness measured in days.

Staying current is automated instead: .github/workflows/refresh-data.yml runs weekly, pulls upstream, runs the suite against the refreshed data and opens a pull request only when something changed. Accepting a refresh stays a reviewed decision, because upstream can renumber an id the surface taxonomy depends on. get_atlas_info reports both pins, so a caller can always see which releases are being served.

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 syncuv run pytestuv 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 · [email protected]

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.