An autonomous pentest agent worked. Now everyone wants one.

TL;DR: ARTEX was billed as proof that an AI agent can plan and run a penetration test on its own. Security teams are now downloading it, its forks and tools built the same way, and pointing them at their own systems. Many products sold as "AI pentest tools" are thinner than ARTEX: a general model wired to a set of tools. Our static review of ARTEX shows how much authority even the engineered version hands over. The boundaries most operators assume are there are not in the application.

It worked. That's the problem.

ARTEX is an open-source autonomous penetration-testing system written in Go. Its project page billed it as the winning entry in Baidu's "agent+" attack-and-defence challenge. It drew a large GitHub following and was widely forked. Its design is now the default shape of AI pentest tooling: a planner that decides what to do next, workers that execute in parallel, and shell, HTTP, MCP and skill tools wired straight in.

That success story is why this post exists.

The autonomy that wins a competition is the same autonomy that runs on your network when you press start. A competition environment is built to be attacked. Your production website isn't.

People with no testing background will run these tools on defaults they've never read. Experienced testers will run them too, assuming the guardrails they'd apply by hand are built in. Both are exposed. We know of no reported case of a legitimate tester causing an incident with ARTEX. The design makes one easy.

It is not a scanner

Figure 1 β€” A traditional scanner executes checks; an autonomous agent repeatedly decides which action to take next.

A security team might think: "It's AI running Nmap, Burp and some HTTP requests. Same as any scanner."

It isn't. A scanner runs a list of checks. An agent decides the next step for itself, and each finding can start another round of planning. When you start one, you are delegating decisions, not running a job.

Most "AI pentest tools" are a model with tools attached

Figure 2 β€” A language model connected directly to tools is not, by itself, an independently governed testing system.

Look inside many products marketed as AI pentest tools and you find the same thing: a general-purpose language model, a system prompt, and a set of MCP servers connecting it to scanners, proxies, a browser and a shell. The model reads the output and picks the next tool.

That design isn't wrong. ARTEX is also a model calling tools. The difference is what is engineered around the model: state that persists between steps, a planner, a record of what is in scope, approval rules, and a log of what was actually sent.

A wrapper doesn't have those. Whatever the model decides next is what runs. Its judgement is the only control.

So when you evaluate one, don't ask which model it uses or how many tools it connects to. Ask what decides the next action, what stops it, and what record exists afterwards. If the answer to all three is "the model", you are not buying a testing system. You are buying a prompt with a shell.

ARTEX is the better-engineered case, which makes it the useful one to examine. If an engineered system leaves these boundaries to the operator, don't assume a thinner tool has built them in. Ask to see them.

What you actually authorised

Figure 3 β€” Conceptual summary of capabilities discussed in our static review of ARTEX v0.3.14; not evidence of observed runtime behaviour.

We reviewed the source of ARTEX v0.3.14, the release its developer published. This was a static review. We didn't run the tool, and we did not test whether these boundaries can be exceeded in practice. What follows is what the code permits.

"Planner" doesn't mean read-only. The component that plans the work also gets general shell and file-editing tools. Its prompt tells it to leave real testing to the workers. That's an instruction to the model, not a limit on what it can do. Those general tools also sit outside the tool-binding table, so an admin who reviews only that table sees less than the agent has.

The agent can widen its own scope. The code describes task scope as the task's "authorization edge". The agent has a tool built to widen it, for example to a whole root domain. Hosts it records along the way are added automatically. That's good for coverage. It also means the system the boundary is meant to limit is the one writing it.

Rules apply at planning, not at the network. Version 0.3.13 added blocklists and allowlists, checked when the agent queues a task or records an asset. We found no equivalent check on outbound shell or web traffic. The allowlist does nothing and allow all until you configure it.

The reviewer watches for damage, not for data leaving. The built-in review policy targets destructive actions. In its own words (our translation): "Purely read-only operations: ALLOW. Whether what is read is /etc/shadow, .env, source code, keys or an entire database, reading sensitive information is not in itself a reason to block." The model reviewer for calls no rule covers is off by default. If it's switched on and fails, the default is to allow. A code comment records that an earlier rules-of-engagement scope check "was removed". The remaining safety rules are database entries a user can disable or delete.

None of this is hidden, and most of it is documented. The point is that the boundary the operator assumes isn't in the application. It has to be built outside it, in the network and the host the agent runs on.

That doesn't mean switching discovery off. Let the agent find the payment provider, the support portal and the identity service. Don't let it act on them until a person has approved widening the boundary. Discovery is the agent's job. Authorisation stays yours.

This isn't an ARTEX problem

Figure 4 β€” Illustrative autonomous decision loop: tool results inform the next planning cycle.

Picture a hypothetical bank whose security team runs an agent like this against internal systems. The risks they're likely to miss aren't specific to one product:

  • Excessive agency: after one task, the agent plans more work nobody expected.
  • Scope expansion: asset discovery turns up targets outside what was approved.
  • Production impact: high-volume or stateful testing disrupts live services.
  • Data exposure: HTTP responses, session tokens and internal records end up in model context, logs or a third-party model provider.
  • Prompt injection: untrusted pages, API responses or tool output steer the agent's next decision.
  • Tool supply chain: MCP servers, skills or dependencies carry more privilege than the user realises.

OWASP lists Excessive Agency as a top risk for LLM applications and maintains a separate MCP Top 10 for the same trust boundaries. Any agent that operates tools faces these. A wrapper faces all of them with nothing between the model and the target.

An abandoned tool is its own risk

Figure 5 β€” Planning-time controls and execution-time restrictions are distinct security boundaries; the latter require independent enforcement.

CrowdStrike has assessed that suspects in recent attacks on South Korean banks used ARTEX. The developer has since said the project will no longer be updated and will go private, and the GitHub repository is gone. (SBS News)

That ends maintenance, not circulation. Forks and mirrors of unknown origin remain. They get no security fixes, and most users have no practical way to tell whether a copy matches what was published.

Our advice: don't download or run circulating copies of ARTEX. Treat any fork of any tool like it as untrusted code until it has been reviewed.

Before you press start

Figure 6 β€” Discovery can be automated, but action outside approved scope must be gated by human approval and external controls.

Every pentester learns one rule early: never run a tool unless you know what it does and what it can break. You read it, you try it in a lab, and only then do you point it at someone's production system.

Autonomous agents make that rule harder to follow, not obsolete. You can read every line of an agent's code and still not know what it will do on your network, because it chooses the next step as it goes. With a scanner, knowing the tool meant knowing its checks. With an agent, it means knowing its limits: what it can reach, what stops it, and who has to approve before it goes further. The read-only rule quoted above is exactly the kind of thing you only learn by reading the source, and most people running these tools never will.

If you can't answer the questions below, you don't know what you're running.

  • Execution: which machine, identity, credentials and mounted files can the agent reach?
  • Boundary: what outside the agent blocks traffic to anything but approved destinations? Think network egress controls, not a database setting the agent can write to.
  • Approval: which actions need a person, and what happens when review fails or times out?
  • Data: what can reach the model provider, extensions, logs and reports, and when is it deleted?
  • Stop and recover: who can stop it, see what it did, and confirm cleanup?

Start in an isolated environment with synthetic data and limited credentials. Test the controls deliberately before you trust them.

Finding vulnerabilities shows the tool works. It doesn't show the test was controlled.

Get it governed properly

If your team is evaluating an autonomous pentest agent, or already running one, DracoSec can review the deployment, its boundaries and its data flows before it touches production. Get in touch via web form or email: enquiry@dracosec.tech

Review note: static review of the ARTEX v0.3.14 release as published by its developer, provenance verified. No code was executed. October 2026.