Discovering AI Applications and LLM Endpoints
AI applications expose themselves differently from traditional web services. LLM endpoints often live under predictable paths, return distinctive response structures, and leak provider information in headers and error messages. The goal here is to map every AI-enabled surface within scope before touching anything actively — chat interfaces, completion APIs, embedding endpoints, agent frameworks, and any AI-powered feature bolted onto existing applications.
Passive Discovery
Start with passive sources before sending a single request to the target. Historical URLs from crawlers and the Wayback Machine frequently surface AI endpoints that have since been removed from navigation but remain live:
https://target.com/api/v1/chat/completions https://target.com/ai/embed https://target.com/api/generate
Crawl for AI Endpoints
katana crawls the application and follows JavaScript-rendered content where traditional crawlers miss dynamically loaded AI features:
Brute-Force Common AI Endpoint Paths
AI frameworks and providers expose endpoints under predictable paths. Build a targeted wordlist from common patterns and brute-force with ffuf:
Include 400, 401, 403, and 422 in the match codes — AI endpoints frequently return these for malformed or unauthenticated requests, which confirms the endpoint exists even when access is denied. A 422 Unprocessable Entity is a strong indicator of an LLM API expecting a specific JSON body.
Scan with Nuclei AI Templates
nuclei has templates specifically for detecting AI services, exposed model APIs, and misconfigured LLM endpoints:
Identify AI Features in JavaScript
Modern AI applications load model provider SDKs and call AI APIs from the frontend. Extract JavaScript files and search for AI provider references:
Provider names in JavaScript bundles reveal which AI service the application uses. A reference to azure.openai means the application proxies through Azure OpenAI Service. bedrock means AWS. anthropic means direct API calls to Claude. Each has slightly different endpoint structures and authentication patterns that inform the next steps.
Check for Proxy Pass-Through Endpoints
Many applications proxy AI provider APIs rather than exposing them directly. Send a minimal completion request to candidate endpoints and observe the response structure:
{
"error": {
"message": "Invalid API key",
"type": "invalid_request_error",
"code": "invalid_api_key"
}
}
An OpenAI-format error response on a target's own domain confirms the endpoint is a proxy to an AI provider. The error type and structure identify the backend provider even when access is denied. This endpoint is a target for authentication bypass and API key extraction in later phases.
References
-
lc/gau on GitHubgithub.com/lc/gau (opens in new tab)
GetAllUrls — passive URL collection from multiple sources
-
projectdiscovery/katana on GitHubgithub.com/projectdiscovery/katana (opens in new tab)
Fast web crawler with JavaScript rendering support
-
projectdiscovery/nuclei on GitHubgithub.com/projectdiscovery/nuclei (opens in new tab)
Template-based vulnerability scanner including AI and LLM detection templates
Was this helpful?
Your feedback helps improve this page.