AIMap: nmap for the Agentic Era

1. The problem it solves

The exposed-AI-service surface has grown fast over the past year: MCP servers, Ollama and vLLM instances that were meant for an internal network get mapped straight onto the public internet, many with no authentication by default. To an attacker, these are open APIs with tool calling built in. To a defender, they are attack surface nobody can see.

The catch is that conventional mapping tools don’t speak these protocols:

AIMap’s official tagline is “nmap for the Agentic Era”: probe actively like nmap, but land at conclusions like “this is an MCP server exposing 14 tools, two of which can run commands” rather than “port 8000 is open”.

2. The four-stage pipeline

Fingerprinting cross-checks three evidence streams: Shodan banner parsing (Server headers for the framework, status codes for auth), Nuclei findings normalization (five custom templates), and live probes (lightweight requests to protocol-fixed paths like /api/tags and /v1/models, with an 8-second timeout). First stream to find a field wins it — a system prompt, for instance, is extracted from the MCP initialize response or the prompt-leak template, and flagged the moment it shows up.

3. What the 32 queries look for

The query set is organized around 11 protocol families:

The queries are not improvised. The source comments list their origins: Knostic’s MCP-Scanner research, Praetorian’s Julius LLM fingerprinting, the Cisco / SentinelOne / FuzzingLabs Ollama exposure studies, and UpGuard’s Streamlit / ComfyUI exposure reports — the query bank is effectively a compilation of industry exposure research.

Two details from the source: the README’s protocol table covers only 30 of the queries, while the code ships 32 — the missing two are oobabooga’s text-generation-webui and a generic /v1/chat/completions query. In the other direction, the banner-detection code has an autogen branch, but no query preset exists for it: it can recognize one, it just can’t go looking for one.

4. How the risk score is computed

The weights below are all verified against compute_risk_score:

The total is clamped to 0–10, with tiers at critical ≥9.0, high 7.0–8.9, medium 4.0–6.9, low 1.0–3.9 and info <1.0.

Worth noting in the design: no-auth is the single largest factor at +4, matching the intuition that an exposed AI service is already the worst case; unknown auth still earns +1 so unverified endpoints don’t sink below notice; and dangerous combos add independently — no auth plus a command-execution tool (exec_no_auth), full database read/write (db_read_write), full file read/write (file_read_write).

Three findings from the scoring code:

1. Auth detection is coarse: an HTTP 200 is taken as “no auth”. Plenty of login-walled services return 200 on their landing page, so they get marked no_auth and +4 — fake exposed services will mix into the list.
2. Combos are substring matches: a tool name containing “admin” triggers admin_no_auth. A tool called manage_notes will be treated as an admin tool.
3. Clamping saturates: the score caps at 10, so a 14-point endpoint and a 10-point endpoint display the same number and the ranking loses resolution.

5. The attack engines

The MCP engine runs seven phases:

Depth comes in four levels — quick / standard / deep / exhaustive — with standard as the default and a 20-step cap, 0.2 seconds between steps. The SSRF targets include 169.254.169.254, Google’s metadata service, Alibaba Cloud’s 100.100.100.200 and localhost. The Ollama engine goes after model listing, weight extraction and prompt injection; the OpenClaw engine targets the control dashboard.

One finding from the attack code: verdicts are keyword heuristics with wide fallbacks — a file read, for instance, counts as successful whenever the response is non-error and non-empty (a string longer than 20 characters, or any non-empty list). Normal business responses satisfy that all the time. The engine is built to quickly surface targets that are obviously broken, not to replace human review — results still need line-by-line verification.

6. Where the AI is

The README and the environment template both carry ANTHROPIC_API_KEY, annotated “optional — enables AI-powered attack analysis”, and the ROADMAP vision promises an “autonomous red-team agent (Claude-powered)” that reads a fingerprint and reasons about attack chains. But reading the current code: the key is declared in config.py and mentioned in .env.example and the Modal deployment docs — no line of code ever reads it. The attack engines are hard-coded scripts with no model calls anywhere.

So the AI currently lives in the roadmap. That is, if anything, the honest part of the design: discovery, fingerprinting and scoring don’t need a model — deterministic rules are more controllable and reproducible. The genuinely hard step, reading a fingerprint and reasoning about attack chains, is left in the ROADMAP until the capability earns its place. Don’t be misled by the “AI-powered” label.

7. Getting started

Docker Compose brings up four services (MongoDB, Redis, the FastAPI backend and the frontend); the .env needs at least SHODAN_API_KEY. Redis can degrade to an in-memory fallback, and Nuclei is only required for active scanning. There are two scan modes: discovery scans (query presets or custom Shodan queries, optionally scoped to a CIDR range) and active scans (httpx plus custom templates against a given IP range, default ports 80/443/3000/8000/8080/8443/8888).

Search uses Shodan-style syntax:

Concurrency is capped at 3 scans and 5 attacks at once, with 10 requests/minute on the creation endpoints; heavy workloads can be dispatched to Modal serverless containers. Each endpoint’s detail page shows the full fingerprint, lets you re-trigger enrichment, and opens the Attack panel with streaming results.

8. Before you use it

• Authorization: the official warning is explicit — authorized testing only. Scans and attacks send real requests to real targets.
• False positives: scoring and attack verdicts are heuristics throughout. “Critical” in the list does not mean a confirmed vulnerability.
• Cost: the Shodan API is metered per query; the code self-throttles at one second between pages, but running all 32 queries still consumes real quota — budget it yourself.
• Operations: MongoDB + Redis + Nuclei + a frontend. It’s a small platform, not a one-liner.