AI Recon on AI Infrastructure: What Hackers Are Looking For (and How to Defend It)

When your AI infrastructure is just a Jupyter notebook on a laptop, the threat surface is manageable. When it's production LLM endpoints serving thousands of users, a vector database holding sensitive embeddings, and a training pipeline with access to your cleanest data — it's a different story. Attackers have noticed.

The AI Attack Surface Has Changed

Traditional recon targets are well-understood: open ports, exposed services, misconfigured S3 buckets, leaked credentials. AI infrastructure introduces a new layer on top of all of that:

• Model endpoints — inference APIs, often with broad network access and minimal authentication beyond an API key
• Vector databases — embedding stores that may contain sensitive document representations, often with weaker access controls than the source documents
• Training pipelines — jobs with write access to model weights, often running with elevated IAM roles
• Context windows — LLMs that have been given privileged tool access (file read, code execution, API calls) can be probed to leak what's in their context
• Model weights themselves — fine-tuned models may encode sensitive training data that can be partially extracted via inversion attacks

What AI Reconnaissance Looks Like

Reconnaissance on AI infrastructure follows the same phases as traditional recon — passive discovery, active enumeration, service fingerprinting — but with AI-specific techniques layered in.

Passive Discovery

Attackers start with what's publicly visible:

• Shodan and Censys searches for exposed model serving ports (Triton Inference Server, vLLM, Ollama, BentoML)
• GitHub searches for hardcoded API keys to Anthropic, OpenAI, Cohere, Hugging Face, Replicate
• Public model cards and HuggingFace model pages that reveal the training data composition
• LinkedIn and job postings that disclose the AI stack (e.g., "experience with Weaviate and LangChain required")

Active Enumeration

Once a target AI service is identified:

• Probing model metadata endpoints (/v1/models, /info, /health) to identify model family, version, and capabilities
• Testing for unauthenticated inference — many internal model servers rely on network position rather than authentication
• Probing RAG systems with queries designed to surface what's in the vector store
• Sending crafted prompts to test for system prompt leakage and tool access

LLM-Specific Techniques

This is the new frontier. Attackers are using the model itself as a reconnaissance target:

• System prompt extraction — prompts designed to make the model repeat or describe its system prompt
• Tool enumeration — asking the model to describe what tools it has access to
• Data extraction via membership inference — probing whether specific documents were in the training set
• Indirect prompt injection — embedding instructions in documents the model will later retrieve, to hijack its behaviour when it processes that content

The CISO's Threat Model for AI Infrastructure

If you're running AI in production, your threat model should include:

1. Inventory your AI endpoints — every inference API, every model server, every vector database. If you don't know what's exposed, you can't defend it.
2. Authentication is not optional — API key authentication is the minimum; for sensitive models, consider mTLS and IP allowlisting as additional controls.
3. Treat vector databases like production databases — embeddings can leak sensitive content through similarity search. Apply the same access controls you'd apply to the source documents.
4. Audit model tool access — if your LLM has tools (file read, web search, code execution), document exactly what it can access. A model that can read files should be scoped to the minimum necessary set.
5. Log inference requests — model inference logs are your equivalent of web server logs. They're essential for detecting anomalous probing patterns and prompt injection attempts.

What This Looks Like in a War Room

At PlayCISO, we're building AI-specific incident scenarios into our War Room — including a "compromised model server" scenario where the first signal is anomalous inference logs, and a "RAG data exfiltration" scenario where an attacker is using similarity search to extract sensitive embedded documents.

The point isn't just to know these threats exist — it's to practise the decision-making under pressure: What do you isolate first? What do you tell the board? How do you assess whether training data was exfiltrated?

If you want to stress-test your AI security decision-making: run a free War Room →

Further reading: AI Reconnaissance on AI Infrastructure — Hackers Arise