MAKO · AUTONOMOUS ADVERSARY EMULATION · CLOSED BETA
An autonomous attacker, run with permission.
Mako is the kind of attacker that is now cheap to run: an AI agent pointed at a target and left to work unsupervised. Given written authorization, it goes after an external network, an Active Directory domain, or a web application the way that attacker would, and records every step. A person reads the record, checks the claims, and signs the report.
$
What Mako is
One operator’s judgment, scaled with compute.
Mako is not a scanner. A scanner reports what might be wrong; Mako picks a way in and keeps going: enumerate, choose a path, exploit, pivot, escalate, until it reaches the objective or runs out of budget. Each step is logged with the command, the response, and the reason the agent chose it.
The agent does the volume; the operator has the last word. Before a report goes out, the operator reads the log and reproduces the findings that matter. Each finding is marked verified, meaning the harness observed it, or claimed, meaning the agent asserted it and the operator could not confirm it. Claimed findings are listed as leads, not results.
Mako is model-agnostic. The report names the model that drove the run and what the run cost in compute. One recent lab machine took 538 automated steps and $18.91.
Built in the open
The build log is public.
Mako’s development is published as it happens, in the Making Mako series. The current track runs Mako against Hack The Box Season 12 machines and writes up each one: how it got from boot to root, how many steps it took, what it cost in compute, and which bugs had to be fixed along the way.
Process
From application to signed report.
01
Apply
An email describing the target, who owns it, and what the report is for. Applications are read by hand and answered either way.
02
Scope and authorization, in writing
Targets, exclusions, windows, and the objective. Mako’s scope gate is loaded from this document, so what is agreed is what is enforced.
03
The run
In-scope reads and exploitation proceed autonomously. State-changing or destructive actions stop and wait for the operator’s approval before they execute.
04
Verification
The operator reads the full action log, reproduces the findings that matter, and strikes anything that does not hold up.
05
The report and walkthrough
A signed report and a call to walk through it. The action log ships with it.
What you get
A report that shows its work.
- A one-line verdict: how far the run got, and the three numbers that describe it — steps, compute cost, findings
- A fix-these-first list, ordered so the first item breaks the attack chain
- How the attack unfolded, step by step, with the step number where each foothold was taken
- Each finding with severity, verified-or-claimed status, the evidence, and the remediation
- What held: what the run tried and could not do
- Cleanup: every artifact the run left on the target, so it can be reverted
- The model that drove the run, and a limitations section written for the reader, not the lawyer
- The operator’s sign-off
A run stops when it reaches the objective, so the report describes the path it took, not every path that exists. The limitations section says so in as many words.
Autonomous adversary emulation
Engagement report
0At a glance
Command execution on the target was obtained as a non-administrative user. The run shows how far an attacker gets before administrative access.
USER-LEVEL ACCESS
Automated steps
538
Attacker compute
$18.91
Findings
1
3Findings
F-01Application input reaches a dangerous interpreterHighVerified
User-supplied input is executed as code by the application. From the public side of the network, that hands over the data behind the application and often the server itself.
A print-service subcommand passed a job name straight to a shell. At step 55 the run used it to gain command execution on .
- Never pass user input to a shell; allow-list file paths and upload types.
- Run the service as a low-privileged account with no write access to its own code.
- Add the reproduction request as a regression test.
4What held
Full administrative control was not obtained within the engagement bounds.
Validated by, Byteshark
Date2026-10-13
Engagementblind-opus-1013-0326
Coverage
What Mako can be pointed at.
Coverage expands as the research does. Nothing is listed here until the harness has done it against a real machine.
● In the harness
External networks
Exposed services, weak or default credentials, exploitable software, and whatever the first foothold reaches next.
● In the harness
Active Directory
Kerberoasting, ACL abuse, delegation, credential reuse, and lateral movement toward domain admin.
● In the harness
Web applications
Injection, broken access control, authentication flaws, SSRF, and the chains between them.
Boundaries
Written authorization, enforced in code.
Mako runs only against systems the applicant is authorized, in writing, to have tested. Scope is checked before each request executes, including requests made from scripts the agent writes for itself. Destructive actions do not run without an operator’s approval.
Engagements are confidential by default. Nothing from a beta engagement is published without written approval, and anything published is anonymized. The full authorization policy, rules of engagement, and data-handling terms are on the Security page.
Questions
Common questions.
Is a Mako engagement a penetration test?
Yes. A Mako engagement is an authorized penetration test run as adversary emulation: Mako pursues an objective on the target the way an intruder would, and the report documents the path it took, verified and signed by a human operator. Whether that satisfies a particular compliance requirement depends on the requirement. Ask before applying.
What does the closed beta mean?
Mako has rooted lab machines end to end and has had few runs against production environments. The beta is a handful of engagements at no cost, in exchange for honest feedback on the report. A small company with a clear target is a better fit than a large one with a vague one.
Who is a good fit?
An organization that owns or is authorized to have tested an external range, a domain, or a web application, has someone who can act on a technical report, and is willing to say what was useful and what was not.
Who verifies the findings?
A human operator. Every claim the model makes is checked against the evidence before it enters the report, and the operator signs the report. Reproduction steps are included so the recipient can check the work too.
How is scope enforced?
Scope is loaded from the written authorization and checked in code before each request executes, not by instructing the model. State-changing or destructive actions stop and wait for the operator. The full action log ships with the report, so what Mako did is on the record.
Which model does Mako use?
Mako is model-agnostic. The model used for an engagement, and what the run cost, is stated in the report. Engagements that require zero data retention can be run on locally hosted models, so no engagement data leaves infrastructure under the lab’s control. The build log on the Research page compares runs.
Does Byteshark still take commissioned analysis work?
Yes. Threat intelligence and malware analysis projects are taken on selectively. See Services.
Closed beta
Apply for the beta.
Email contact@byteshark.tech with three things: what the target is, who owns it and your authority to have it tested, and what you want from the report. A few lines is enough. Every application gets a reply.