For the complete documentation index, see llms.txt. This page is also available as Markdown.

Reconnaissance

The first part of recon is discovering AI implementations in web applications. This can be as obvious as a chat bot, but it can also be when fuzzing API endpoints and coming across a OpenAI specification endpoint.

Passive

Passive recon means that we are not directly fingerprinting the AI-system itself. This way, we leave no mark in logging and can do recon without getting detected.

Headers

One obvious way to do passive recon is by looking at HTTP headers.

$ curl -s -I http://192.168.50.21/
HTTP/1.1 200 OK
Server: nginx/1.24.0 (Ubuntu)
...
X-Powered-By: Corp/2.1.0
X-AI-Backend: OpenAI-GPT5.2
X-RAG-Provider: ChromaDB

Also look at /api/health for more information if available:

$ curl -s http://192.168.50.21/api/health | jq
{
  "mcp_enabled": true,
  "model": "gpt-5.2-turbo",
  "rag_enabled": false,
  "service": "corp-customer-assistant",
  "status": "healthy",
...
  "version": "2.1.0"
}

Source code analysis

If you have access to source code, look for files related to the AI-system. This can for example be useful to get a better understanding of the guardrails within the system prompts.

It can also lead to config data, such as embedding settings and RAG-pipelines.

Active

Active recon means that we are directly interacting with the AI-system.

Script files

First, look for javascript files.

JS files can identify API endpoints related to the AI-system:

Prompting

We can literally ask the agent about itself

If there is some kind of protection that prevents this, we can perhaps bypass it by letting the AI-agent correct us.

Fuzzing

Fuzzing can also reveal API-endpoints related to the AI-system.

The 401 endpoint means that the endpoints exists, but that we are not authorized to make a request. The /v1/chat/completions path follows the OpenAI API format, indicating either a direct proxy to OpenAI or an OpenAI-compatible backend.

RAG pipelines

Sometimes, systems return verbose responses regarding their sources to answer input.

Here, "chunk_id" and "vector_score" reveal that a RAG-pipeline is in place. Of course the information that can be gathered from this depends on the database itself. Perhaps we can reveal things like API endpoints or other internal information.

Not all RAG systems expose the same level of detail. Minimal implementations return only document titles like "sources": ["Employee Handbook"]. Moderate implementations include titles with text snippets, but omit scoring information. Detailed implementations expose full metadata, including chunk IDs, similarity scores, and raw text content. Comparing different endpoints helps us understand what intelligence each reveals and prioritize our reconnaissance accordingly.

AIbuster

aibuster takes a scope of base URLs, probes each one for AI-related surface (A2A Agent Cards, MCP JSON-RPC, OpenAPI/Swagger, common health/control endpoints), and tries to classify what it finds by generic capability categories (SQL, exec, file, network, secrets, orchestration, registration, …), exports everything to a single JSON file, and ships with a small web UI for triage.

https://github.com/1ncendium/aibuster

Example:

Last updated