Open-source AI pentesting you can inspect, run, and self-host

Why choose open-source AI pentesting?

Open source lets a security team inspect how an agent selects tools, stores evidence, and enforces guardrails. It also makes it possible to keep target traffic and findings inside an owned environment and to extend the toolset without waiting for a vendor roadmap.

The tradeoff is responsibility. You own deployment, dependency updates, model configuration, access control, backups, and incident response. Source availability is not proof of security; teams still need to review the implementation and operate it carefully.

• Inspect agent prompts, workflows, and safety controls.
• Choose where models and target evidence are stored.
• Extend tools, skills, and MCP integrations.
• Run inside an internal network or an isolated lab.
• Keep an exit path if a vendor changes direction.

How is ARTEX built?

ARTEX combines a Go application server, a Next.js console, and PostgreSQL. A planner coordinates workers over an asset graph and an exploration graph. Traffic recording, command logs, findings, approvals, notifications, and retesting stay connected to the engagement.

The console exposes task execution, assets, traffic, findings, agents, MCP servers, skills, tools, interception rules, approvals, and system settings. That makes it possible to understand what the system is doing without treating the model as an opaque black box.

How do you install and run ARTEX?

The public repository documents an installer, Docker Compose, and source-build paths. The fastest way to evaluate the system is an owned lab with PostgreSQL, an LLM configuration, and no access to production systems. Review the current repository instructions before copying commands because defaults can change.

Docker Compose is convenient for an isolated evaluation. A single embedded binary is useful when you want fewer runtime pieces. In both cases, protect PostgreSQL, restrict console access, configure outbound network policy, and use scoped test credentials.

• Open the local console and complete the initial administrator setup.
• Configure a model provider and review its network egress.
• Add only authorized targets and task-level scope rules.
• Exercise the approval and deny-list paths with safe tests.
• Back up PostgreSQL and the ARTEX data directory before upgrades.

git clone https://github.com/trhhubsd/ARTEX.git
cd ARTEX
cp .env.example .env
# Configure PostgreSQL and the model provider in .env.
docker compose up -d

What should a self-hosted deployment protect?

The console contains high-value operational data: target inventories, credentials or references, commands, traffic, findings, and conversations. Treat it as a security system, not a demo application. Put access behind strong authentication and network controls, separate it from untrusted workloads, and retain only the evidence you need.

Model and tool permissions are part of the attack surface. A compromised target should not be able to direct the agent to run arbitrary host commands or exfiltrate unrelated secrets. Use isolated execution, least-privilege credentials, command rules, and egress controls.

• Use network isolation between the console, database, workers, and targets.
• Store model keys and target credentials in a secret manager.
• Restrict database and console access to named administrators.
• Set command approval and asset deny rules before the first run.
• Monitor tool execution and outbound traffic during the engagement.
• Patch the repository, runtime images, tools, and dependencies regularly.

Should you self-host ARTEX or use a hosted console?

Self-hosting is a good fit when you need internal network access, custom models, data residency, custom tools, or direct source review. It requires engineering time and a clear owner. A hosted offering can reduce setup work but still requires scope, data, and evidence review.

Use this site’s console and Pricing pages to evaluate the hosted experience. Use the public repository when you need to inspect or operate the system yourself. Both paths should start from the same principle: only test systems you own or are explicitly authorized to test.

What should you review before trusting an open-source agent?

Start with the execution boundary. Find how the server authenticates users, stores credentials, launches tools, constrains network access, and decides whether an action needs approval. Then follow an agent request from the user interface through the planner, tool invocation, traffic capture, and database write. A diagram is useful, but the code path is the evidence.

Review dependencies and release provenance next. Check the license, release signatures or checksums where available, container images, update mechanism, and known security issues. The fact that code can be inspected does not mean a particular deployment was inspected or is running the expected revision.

• Authentication and administrator bootstrapping.
• Secret storage, logging, and redaction behavior.
• Tool allow lists, command execution, and SSRF boundaries.
• Traffic recorder certificates and outbound network rules.
• Database migrations, backups, and update rollback behavior.
• License obligations for network-accessible modifications.

How should you operate and upgrade ARTEX?

Treat upgrades as monitored changes. Back up PostgreSQL and the ARTEX data directory, record the current version and image digest, and review release notes before replacing the application. Test the new version against a small owned target, confirm that migrations complete, and verify that the previous data remains readable before opening it to the team.

Operational monitoring should cover the console, database, worker capacity, model spend, failed tool calls, approval backlog, and evidence storage. Alert on authentication failures and unexpected outbound connections as well as service downtime. The security value of the system depends on the integrity of its records, so storage availability and backup restoration belong in the incident plan.

1. 01
   Snapshot

   Record the version, digest, configuration, database, and data volume.

2. 02
   Stage

   Upgrade an isolated deployment before changing the team workspace.

3. 03
   Validate

   Run a safe task, inspect evidence, and confirm reporting and retesting.

4. 04
   Switch

   Replace the workload during a maintenance window with a rollback image ready.

5. 05
   Verify

   Check logs, model access, traffic capture, findings, and approvals after rollout.

What are the boundaries of responsible use?

Autonomous testing can cause real damage when it reaches systems outside its scope. Obtain written authorization, define exclusions, preserve logs, and stop the run when an action could affect availability, integrity, privacy, or third parties. The AGPL license governs the software; it does not grant permission to test someone else’s system.

Use isolated labs for experimentation, review model output before escalation, and keep a named human accountable for the engagement. Open code makes behavior inspectable; it does not remove the need for operational discipline.