elder-plinius/t3mp3st

Purpose and entry points

T3MP3ST is a TypeScript/Node.js, self-hosted offensive-security framework for authorized engagements. It orchestrates agent-driven reconnaissance, exploitation workflows, evidence handling, reporting, and reproducible benchmark evaluation. Primary entry points are the package CLI (index.ts, src/cli.ts), local HTTP/War Room server (src/server.ts), and MCP server (src/mcp-server.ts). Docker deployment is defined by Dockerfile and docker-compose.yml.

Mission control and orchestration

Mission execution centers on an orchestrator that turns target intent into agent tasks, shared context, and results. The control boundary is between mission planning/coordination and individual tool or model calls:

• src/mission/index.ts

• src/orchestration/orchestrator.ts

• src/orchestration/context-pack.ts

• src/orchestration/types.ts

The orchestration layer builds context packs, selects prompts/operators, dispatches work, and collects outputs. Mission adjudication is separated in src/mission/adjudicate.ts, allowing findings or task outcomes to be evaluated independently of generation.

LLM and local-agent boundary

The framework supports cloud providers and connected local coding agents; provider selection and model metadata are centralized rather than embedded in mission logic:

• src/llm/index.ts

• src/agent/local-agents.ts

• src/config/provider-models.ts

This is the principal external-service boundary: OpenRouter, Venice, Anthropic, OpenAI-compatible/local endpoints, and local agent CLIs. Credentials/environment configuration enter through src/config/index.ts and .env.example. Local-agent dispatch is a keyless alternative to API-backed models.

Targeting, reconnaissance, and source analysis

Target modelling and recon are distinct from orchestration, enabling black-box and white-box workflows:

• src/target/index.ts

• src/recon/attack-graph.ts

• src/recon/code-ingest.ts

• src/recon/whitebox.ts

For source targets, ingestion parses and extracts code structure, with TypeScript grammars/parsing isolated in src/recon/ts-grammars.ts and src/recon/ts-parse.ts. Recon can produce an attack graph and parameter splits before downstream tool-backed actions. Network proxy behavior is isolated at src/net/proxy.ts.

Arsenal, containment, and validation

The Arsenal is the controlled adapter layer for security tooling. Its catalog, adapters, parsers, and approval controls form a deliberate boundary between agent intent and command/tool execution:

• src/arsenal/catalog.ts

• src/arsenal/adapter-tools.ts

• src/arsenal/parsers.ts

• src/arsenal/approval.ts

Approval and scope enforcement constrain potentially dangerous operations; evidence validation is separately represented by src/evidence/gate.ts and src/validation/index.ts. This separation supports tool-proven findings rather than model-only assertions.

Evidence, reporting, and integrations

Evidence collection and report workspace management preserve artifacts across mission stages:

• src/evidence/index.ts

• src/arsenal/report-workspace.ts

• src/integrations/bounty.ts

The HTTP server exposes local API endpoints, while src/mcp-server.ts exposes the security_recon capability to MCP clients. The application is designed for localhost-oriented deployment; Docker Compose supplies the runtime boundary, and optional external security binaries are containerized via tools/Dockerfile.

Benchmark and reproducibility pipeline

Committed corpora, oracle data, and run receipts make benchmark claims independently recomputable rather than runtime application state:

• bench/cve-zero/samples/

• bench/cybench/results/

• bench/xbow/results/

• scripts/verify-claims.mjs

Benchmark runners under scripts/ execute domain-specific evaluations; artifacts are stored as JSON under bench/. This is operationally separate from live missions, but architecturally important because it verifies tool counts, benchmark outcomes, and published claims from repository-contained evidence.