Exploit Modules

aipostex includes 20 post-exploitation modules, each targeting a specific AI service family. Modules follow a consistent pattern: read-only enumeration commands run without restrictions, while state-changing or high-noise actions require --force-exploit.

Module Summary

Module	Service(s)	Subcommands	Read-Only	Gated
ollama	Ollama	10	5	5
vectordb	ChromaDB, Weaviate, Qdrant, Milvus, pgvector	5	3	2
jupyter	Jupyter Notebook	8	4	4
mcp	MCP servers	8	3	5
openai-compat	OpenAI-compatible APIs	10	8	2
ray	Ray	9	4	5
mlflow	MLflow	12	8	4
gradio	Gradio	7	4	3
bentoml	BentoML	4	3	1
triton	NVIDIA Triton Inference Server	7	4	3
torchserve	PyTorch TorchServe	7	3	4
litellm	LiteLLM Proxy	5	4	1
huggingface	HuggingFace TGI/TEI	6	3	3
tfserving	TensorFlow Serving	5	4	1
kubeflow	Kubeflow Pipelines	6	5	1
wandb	Weights & Biases	5	5	0
a2a	Agent-to-Agent APIs	12	4	8
k8s	Kubernetes API server (ML/AI workloads)	7	3	4
agent	Bespoke LLM /chat apps	6	6	0
rag	Black-box RAG apps	3	2	1

Utilities

Command	Purpose	Doc
model-scan	Local model file supply-chain scan (pickle / PyTorch / formats)	model-scan

These modules provide the main post-exploitation surface of the tool, covering read-only enumeration through gated proof actions.

Common Flags

All exploit modules share these flags:

Flag	Description
--target	Target service URL (required for all remote commands).
--header	Custom HTTP header(s) in Key: Value format. Repeatable.

Safety Model

flowchart LR
    ReadOnly[Read-Only Commands] -->|no flag needed| Execute[Execute]
    Gated[State-Changing Commands] -->|requires --force-exploit| Execute
    Gated -->|without flag| Blocked[Blocked with message]

Read-only commands include: enumeration, listing, reading, extraction, fingerprinting, and passive analysis.

Gated commands include: model creation/deletion/poisoning, code execution, file uploads, throughput/proxy testing, and queue/serve probes.

See Safety Model for the complete gated action reference.

Operator Progression

Each module supports a progression from enumeration to proof:

flowchart TD
    Discovery["discover network\n(fingerprint services)"] --> Enum["module enum\n(enumerate assets)"]
    Enum --> Read["module read commands\n(extract data, validate access)"]
    Read --> Proof["module gated commands\n(demonstrate impact)"]

Findings from earlier stages attach workflow recommendations pointing to the next logical command, using values discovered in the current step (model names, collection IDs, kernel IDs, job IDs, etc.).

Operator Console

Alongside the module verbs, the operator console lets you keep interacting with a reached service by hand — authenticated or unauthenticated — at any stage, driving every request yourself (no automated chaining). Two commands: request, a one-shot arbitrary HTTP call captured and mined for loot, and shell, an interactive REPL. Which modules expose which:

Console verb	Modules
request (one-shot HTTP)	ollama, mlflow, ray, openai-compat, litellm, vectordb, huggingface — plus the top-level aipostex request for any HTTP service
shell (interactive REPL)	ollama/openai-compat/litellm/huggingface (LLM chat), jupyter (kernel Python), mcp (tool-caller), a2a (task console)

The execution shells (jupyter/mcp/a2a) require --force-exploit; LLM chat is ungated. Kubernetes has no in-tool console — its interactive channel is kubectl, handed off as a kubeconfig by the dossier's manual/ folder.