# Mapping AI Dependencies, SDKs, and Frameworks

> Identify and enumerate AI/ML frameworks, SDKs, and third-party dependencies within target environments to uncover attack surface and supply chain risks.

- **URL:** https://hackindex.io/platforms/ai/reconnaissance/mapping-ai-dependencies-sdks-and-frameworks
- **Path:** AI Platforms > Reconnaissance
- **Up:** [Reconnaissance](https://hackindex.io/platforms/ai/reconnaissance.md)
- **Published:** 2026-03-18
- **Updated:** 2026-08-11

The framework and SDK stack behind an AI application determines which attack surfaces exist. LangChain applications expose different tool integration vulnerabilities than LlamaIndex ones. An application built on the Vercel AI SDK behaves differently from one using the OpenAI SDK directly. Identifying these dependencies before active testing lets you target the right attack techniques and avoid wasting time on techniques that do not apply to the stack in use.

## Identify Frameworks from JavaScript Bundles

Frontend JavaScript bundles often contain AI SDK references, even when the actual API calls happen server-side. Extract all JS files and search for framework signatures:

```bash
katana -u https://$TARGET_DOMAIN -jc -d 2 | grep '\.js$' | httpx -mc 200 -silent | while read url; do curl -sk "$url" | grep -iEo '(langchain|llamaindex|openai|anthropic|vercel.ai|ai-sdk|haystack|semantic.kernel|autogen|crewai|dspy|litellm|instructor|guidance|outlines)' | sort -u; done
# langchain
# openai
# litellm
```

Framework names in the bundle confirm what the application is built on. `langchain` means agent and chain abstractions with tool calling. `llamaindex` means a RAG-heavy architecture. `autogen` or `crewai` means multi-agent systems. `litellm` means the application proxies multiple providers through a unified interface: which may mean API keys for multiple providers are accessible server-side.

## Check Exposed Package Files

Misconfigured deployments sometimes expose package manifest files that list all dependencies including AI frameworks:

```bash
for path in package.json requirements.txt pyproject.toml Pipfile poetry.lock package-lock.json yarn.lock; do curl -sk https://$TARGET_DOMAIN/$path | head -50 && echo "--- $path ---"; done
```

An exposed `requirements.txt` or `package.json` is a full dependency map. Note exact version numbers: outdated versions of AI frameworks often have known prompt injection or tool abuse vulnerabilities. Cross-reference against CVE databases and framework changelogs.

## Identify Frameworks from Response Signatures

AI frameworks leave signatures in API response structures and error formats. Compare the response structure against known framework patterns:

```bash
curl -sk -X POST https://$TARGET_DOMAIN/api/chat -H 'Content-Type: application/json' -d '{"messages":[{"role":"user","content":"test"}]}' | python3 -m json.tool
```

Response field signatures by framework:

- **LangChain**: responses may include `run_id`, `intermediate_steps`, or `agent_scratchpad` fields when verbose mode is accidentally enabled
- **LlamaIndex**: responses sometimes include `source_nodes` with document metadata when debug logging leaks into responses
- **Vercel AI SDK**: streaming responses use a specific line-prefix format starting with `0:`, `8:`, `d:`
- **Haystack**: pipeline responses include `answers` arrays with `document_ids`

## Enumerate Dependencies via Error Stack Traces

Triggering server errors sometimes returns stack traces that reveal the exact framework and version:

```bash
curl -sk -X POST https://$TARGET_DOMAIN/api/chat -H 'Content-Type: application/json' -d '{"messages":null,"model":null}' -v 2>&1 | grep -iE 'langchain|llamaindex|traceback|error|exception|version'
```

## Check Python and Node Package Audit Data

If you have access to any exposed dependency files, audit them for known vulnerable AI framework versions:

```bash
curl -sk https://$TARGET_DOMAIN/requirements.txt -o /tmp/target-requirements.txt && pip-audit -r /tmp/target-requirements.txt
```

```bash
curl -sk https://$TARGET_DOMAIN/package.json -o /tmp/target-package.json && npm audit --package-lock-only --json 2>/dev/null | python3 -m json.tool | grep -A3 'severity'
```

## Identify Orchestration Framework from Network Traffic

If you can observe network traffic from a position on the same network segment, AI framework calls to provider APIs follow recognisable patterns. Different frameworks use different default parameter sets and header combinations that act as fingerprints even when request content is encrypted.

In a lab or internal assessment context, capture outbound HTTPS traffic from the AI application server and compare the TLS SNI values against known AI provider domains:

```bash
tshark -i eth0 -Y 'tls.handshake.type == 1' -T fields -e tls.handshake.extensions_server_name 2>/dev/null | grep -iE 'openai|anthropic|googleapis|amazonaws|azure|mistral|groq|cohere|huggingface'
# api.openai.com
# api.openai.com
# api.openai.com
```

## References

- [pypa/pip-audit on GitHub](https://github.com/pypa/pip-audit) - Python dependency vulnerability auditing for requirements.txt files
- [projectdiscovery/katana on GitHub](https://github.com/projectdiscovery/katana) - JavaScript-aware crawler for extracting SDK and framework references from bundles