Drael runs your exploit on its server. That is a flaw

Drael runs the code its model writes on Drael's own server, and it sells that as the feature. For security work it is a design flaw. The target sees Drael's address, your scope does not list it, the intermediate steps are hidden from you, and the terms make you answer for the result.

Data collected on 9 and 10 November 2026 from Drael's site, its tools documentation and its legal pages, and from NotHoly pricing. We did not open a Drael account or run its sandbox; everything below is quoted from its public pages.

#What Drael sells

The home page puts it in one sentence: "It writes the scanner, the exploit, the fix nothing else will, and the sandbox behind it is real: the network is a flag on the call, not a permanent no." The tool is run_code. It executes Python or bash in a container on Drael's infrastructure, inside a server-side loop of up to ten model turns.

run_code property	Value in Drael's docs
Where it runs	Drael's server, one container per run
Network	Off by default, on with network in the call
Duration	30 seconds by default, 5 minutes at most
Server loop	Up to 10 turns; "You never see the intermediate turns"
Files	"Files persist across calls in the same session"
Concurrency	"One run at a time" per account

The container protects Drael's host from your code. It does nothing for the host on the other end of the network flag, which receives the same packets from an address that belongs to Drael.

#Whose IP reaches the target

Drael's. Its privacy page says so about fetches: "A page you ask it to fetch sees a request from our server." Code that runs in its container with the network on leaves from the same side.

Step	On Drael	On NotHoly
Read a public page	web_fetch, from Drael's server, "including sites behind bot protection"	read_url, public pages only, through SSRF-protected egress
Send traffic to a host	run_code with network on, from Drael's container	No server tool does this; the CLI runs it on your machine, from your IP, after your approval
Reach a .onion	web_fetch over Tor	Search lists results and never opens the .onion
Handle a file	Attached to a workspace on the server where the model's code runs	Uploaded files are analysed in a gVisor sandbox and never executed
See each step	Up to 10 server turns you do not see	Each command reaches you for approval

The client's blue team works from a list of source addresses. Traffic from an address outside that list is an incident, and it will be handled as one.

#Why that breaks a scope

Rules of engagement name where a test comes from. NIST SP 800-115, Appendix B, lists authorized and unauthorized IPs in section 4 and the locations from which testing is authorized in section 2.3, with signatures in section 7. PTES asks for a signed Permission to Test and separate approval when third parties are involved.

Drael's addresses are not yours to declare, and its operator is not a party to your agreement. The operator is not even named in its own terms, so you could not add it to the paperwork if you wanted to.

Laws such as 18 USC 1030 in the United States and article 154-A of the Brazilian Penal Code turn on authorization. Whether an authorization that lists your addresses covers traffic from someone else's is a question for your lawyer, and you do not want to be asking it after the client's SOC opens a ticket.

#The evidence is not yours

A report has to state what was sent, when, from where, and what came back. Drael's documentation says "You never see the intermediate turns". What you receive is the model's account of what it did. The OWASP LLM Top 10 calls this class of problem LLM06, Excessive Agency: a loop that takes network actions with no checkpoint.

The data stays behind too. The privacy page lists what is kept: "Your conversations, image prompts, the code you ran and your instructions", plus "The files your code wrote, in that conversation's workspace, for up to three days after it was last used." The clock restarts each time you use it. NIST SP 800-115 asks for documented rules to store and destroy test data (section 7.4). On Drael, output from a client's systems sits on a disk run by a seller you cannot name. If you delete it, the same page says copies in a backup "leave as backups are rotated", on a schedule it does not give.

#Who answers when the client calls

You do. Drael's terms say that running or acting on an answer "is your decision and your risk", and that "If someone makes a claim against the operator because of how you used Drael or what you did with an answer, you take responsibility for it, including the reasonable cost of defending it."

So Drael's server sends the traffic, and the terms hand you the bill, the operator's defence costs included. Drael's own liability stops at three months of fees. The same terms add that "Nothing Drael says is legal, medical, financial or security advice." Our reading of the terms has the rest.

#Where execution belongs

NotHoly keeps inference on our side and execution on yours. No server tool scans, exploits or sends active traffic to third parties. The CLI runs commands on your machine, each with your approval, from the address your rules of engagement already list, and the record stays in your shell history and your packet capture.

That leaves you to run and contain your own environment, which is what a tester does anyway. Your prompts still go to inference on our side: API content is not recorded, only metadata, and chat history is saved unless you pick an ephemeral chat. The fit with real work is on pentesting, red team and the harness page.

#Where each fits

Drael's server-side sandbox fits a solo user who wants the model to run its own code and fetch pages without standing up a machine, and who is not sending that traffic at anyone else's systems. NotHoly fits work with a signed scope: inference on our side, execution on yours, each command run from your own address after you approve it, with the record in your shell history and packet capture. The trade is that you run and contain your own environment, which is what a tester does anyway.

#Frequently asked questions

#Which IP does the target see when an AI runs code?

The IP of wherever the code runs. With Drael that is Drael's server. With a CLI on your machine it is yours.

#Can I use an AI that runs code on a pentest?

Yes, when it executes from a location your rules of engagement list and you can log each command. A hosted tool that sends the traffic itself needs the client's written approval first.

#How long does Drael keep files from run_code?

Up to three days after the last use, according to its privacy page, and the code you ran is kept with your history.

#Who is liable if a hosted AI hits the wrong target?

Drael's terms put claims about your use on you, including the operator's reasonable defence costs.

#Does NotHoly execute code on its servers?

No. The infrastructure does not touch targets, and uploaded files are analysed without being executed.

#Verdict

Server-side execution is the feature Drael leads with and the reason it cannot be used on a client. It hides the steps, sends from an address outside your scope, stores the output and assigns you the liability. We decided against building it. If your work has a signed scope, read how the CLI handles approval, add US$ 5 on NotHoly pricing and keep the packets on your own address. Why professionals do not run engagements on Drael applies the same test to the rest of the product.