Automation & Ops offensive-securitysecurity-reconred-teamingmcp-serverlocal-agentvulnerability-researchdocker

T3MP3ST Security Harness

Turn a connected coding agent into an orchestrated workflow for authorized security testing.

FollowAgents review · FARS-2.1
Not recommended
55/ 100 5-point scale 2.8 / 5
1 2 3 4 5 6
Per-dimension scores and reasoning
1Trust14 / 29 · 2.4/5

least_privilege: 1 - There are permission controls (e.g., scope restrictions, gated dangerous tools), but no full evidence of least privilege principle. user_confirmation: 2 - Update flow requires user confirmation, but other operations (e.g., mission start) do not explicitly require confirmation. data_flow_transparency: 1 - Documentation mentions data flows (e.g., evidence vault, credential store), but does not detail data flow and usage. sensitive_data_handling: 2 - Protected paths (.env, key files) and data handling guidelines exist, but no encryption or redaction details. dependency_security: 2 - Dependency overrides and npm audit report exist, but no full vulnerability scan evidence. external_effects: 1 - Tools perform real operations (e.g., port scanning), but no side-effect control or rollback mechanism. rollback: 2 - Updater provides rollback and protected paths, but no task-level rollback. source_attribution: 1 - Contributor guidelines exist, but no clear source attribution mechanism.

2Reliability8 / 14 · 2.9/5

self_consistency: 2 - Documentation and code structure are consistent, status table is clear. dependency_availability: 2 - Dependency list is complete, but no availability guarantee. failure_messages: 1 - Error handling scripts exist, but no user-friendly error messages.

3Adaptability10 / 18 · 2.8/5

audience_and_scenarios: 2 - Clear target users and scenarios (authorized testing, CTF, etc.). capability_boundaries: 2 - Status table clearly distinguishes stable, experimental, and planned features. trigger_precision: 1 - Mission start relies on natural language, but no precise trigger mechanism. environment_fit: 2 - Supports multiple environments (local, Docker, offline).

4Convention10 / 18 · 2.8/5

information_architecture: 2 - Documentation structure is clear, with index and navigation. install_notes: 2 - Installation steps and Docker guide provided. naming_stability: 2 - Naming is consistent, with version numbers. examples_and_faq: 2 - Quick start and documentation links provided. known_limitations: 2 - Status table clearly lists limitations. license: 2 - AGPL-3.0 license provided. versioning_changelog: 1 - Version number exists but no changelog. maintenance_responsibility: 1 - Contribution guidelines exist but no maintainer information.

5Effectiveness9 / 13 · 3.5/5

output_usability: 2 - Reports and evidence provided, but no output format details. marginal_value: 2 - Unique features (e.g., multi-agent, offline) provided. cost_benefit: 2 - Emphasizes no extra API key cost, but no performance data.

6Verifiability4 / 8 · 2.5/5

claim_traceability: 2 - verify-claims script and benchmark data provided. cross_source_corroboration: 1 - Relies on single source, no external verification. fact_inference_separation: 2 - Clearly distinguishes facts and inferences (e.g., status table).

Evidence confidence: Low Reviewed Aug 09, 2026 Reviewed revision afc9dad1b27e
The upstream repository has new commits since this review. The score still applies to the reviewed revision shown and may not cover the latest changes.
Before you use it
  • This is an offensive security tool, intended for authorized testing only, but carries risk of misuse.
  • Publisher identity is unverified; treat with caution.
  • Dependency security relies on npm audit report only, no full vulnerability scan evidence.
  • Data flow transparency is insufficient; further review needed.
Review evidence [1][2][3][4][5]
See the full review method →

What does this agent do, and when should you use it?

T3MP3ST is a multi-agent offensive-security framework for authorized testing, research, and education. It connects an already authenticated local coding agent or an API provider through a browser War Room, CLI, HTTP API, and MCP server. Mission Control, the Target Model, the Arsenal, and eight operator roles organize missions; the README marks the reconnaissance engine, mission engine, and evidence/reporting flow as stable while describing much of the coordinated downstream chain as experimental. It covers tool-backed web reconnaissance, white-box source analysis, CTF work, coordinated disclosure, and scaffolding for cloud, mobile, and binary static detection. It is designed for local or self-hosted deployment, and the documented Docker service binds only to 127.0.0.1:3333 by default.

An operator connects Claude Code, Codex, Hermes, OpenCode, or Oh My Pi in the War Room Settings, describes an authorized target to Op Admiral, and starts a mission. Mission Control coordinates the Target Model and Arsenal; the README describes Recon as a tool-backed loop that drives nmap, DNS, HTTP, and fingerprinting, with built-in networked tools refusing public hosts outside mission scope as well as loopback and private addresses. The system produces mission status, findings, evidence, reports, and coordinated-disclosure drafts. npm run server starts the HTTP API, while node dist/mcp-server.js exposes security_recon to MCP-aware clients. npm run verify-claims recomputes the README's benchmark claims from committed JSON under bench/.

  1. A penetration-testing team with written authorization needs local War Room-driven asset discovery, service fingerprinting, and mission evidence for a web application assessment.
  2. A security researcher reviewing open-source robotics, OT, or embedded software needs an OSV novelty, live-PoC, refuter-panel, and CVSS workflow for coordinated-disclosure drafts.
  3. A CTF learner working in an isolated authorized challenge environment wants to run hint-free Cybench-style tasks through a connected local coding agent.
  4. An application-security engineer needs white-box ingestion and decomposed vulnerability analysis for Python, JavaScript, TypeScript, Go, Java, C, or C++ repositories.
  5. A self-hosting team wants to expose security_recon to an MCP-aware agent while retaining local agent authentication or switching to OpenAI, Anthropic, OpenRouter, or Venice providers.

What are this agent's strengths and limitations?

Pros
  • It can use an already authenticated local coding agent while also documenting OpenRouter, Venice, Anthropic, OpenAI, and local OpenAI-compatible model paths; the local-agent path does not require a new API key.
  • War Room, CLI, HTTP API, and MCP security_recon provide both an operator interface and integration surface for MCP-aware workflows.
  • The README documents verify-claims as recomputing published metrics from committed benchmark JSON and reports black-box and white-box XBEN results separately.
  • Default egress-scope containment rejects out-of-scope public hosts plus loopback and private addresses, and the documented Docker deployment listens only on the local loopback interface.
Limitations
  • This is an offensive-security tool for owned or explicitly authorized targets only; adopters remain responsible for legal scope and rules of engagement.
  • The README explicitly says end-to-end coordinated swarm exploitation is unbenchmarked and unreliable; several downstream operators and white-box source analysis remain experimental.
  • Cloud, mobile, and binary modules are primarily static-detection or interface scaffolding, without benchmarks for live cloud exploitation, mobile dynamic exploitation, or binary solving/pwn work.
  • Local operation depends on npm, shell access, and either a local authenticated agent or configured model provider; Docker deployment and update workflows add Docker or Git dependencies.

How do you install or deploy this agent?

Install and start the local War Room:

npm install
npm run server

Open http://127.0.0.1:3333/ui/ and connect a local agent in Settings. Alternatively, configure OPENROUTER_API_KEY, VENICE_API_KEY, ANTHROPIC_API_KEY, or OPENAI_API_KEY for a provider path. For offline use, run ollama serve && ollama pull llama3, set TEMPEST_LOCAL_BASE_URL=http://localhost:11434/api and TEMPEST_LOCAL_MODEL=llama3, then run npm run build and npx tempest. For Docker, run cp .env.example .env and then docker compose up -d.

How do you use this agent?

Connect a local agent in War Room Settings, describe an authorized target to Op Admiral, and launch the mission. Check the local service with curl http://localhost:3333/api/health; the README also documents curl http://localhost:3333/api/bounty/platforms as an API example. For MCP integration, run node dist/mcp-server.js and use its exposed security_recon capability. Run npm run verify-claims when you want to recompute the repository's published benchmark claims.

FAQ

Do I need to buy a new model API?
Not necessarily. The README documents connections to already authenticated Claude Code, Codex, Hermes, OpenCode, and Oh My Pi, alongside OpenRouter, Venice, Anthropic, OpenAI, and local-model options.
Can I point it at any public target?
No. The project is limited to authorized testing, research, and education; the README requires that you own the target or have explicit written permission.
Has the eight-operator swarm been proven to exploit targets reliably?
No. The README marks reconnaissance as stable but says end-to-end swarm exploitation is unbenchmarked and still unreliable; the public benchmarks are primarily single-agent ReAct-loop results.
Can it run without a cloud model?
Yes. The README documents Ollama and OpenAI-compatible servers such as LM Studio, vLLM, and llama.cpp; configure the local base URL and model, then select the local provider through npx tempest.

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents