StrikeAgent_AtkBrain-Flash protects its console with an eight-character path, and binds it to 0.0.0.0

The agent finishes a whole round before it speaks to you

The execution model is the part of the design worth understanding, because it is not an interactive chat loop. The console dispatches surface hunting work, and an attack graph drives a self-running cycle. A subordinate agent completes an entire round and only then reports back, and it speaks mid-round only when it is stuck or when its cycle expires. A human instruction typed into the conversation interrupts the current round immediately, which is the one place the loop yields. When work concludes, the techniques used are distilled into a memory store, so later rounds start from accumulated procedure rather than from nothing. The runtime underneath is a separate coding agent, and which model backs it is chosen in a settings file rather than at install time. Red-team, blue-team, and SRC modes connect to real addresses by default; a proxy is used only when a proxy pool has been imported in settings.

The console is hidden behind a random path written to one local file

Access control here is obscurity plus a short list of ordinary measures, and the documentation is unusually explicit about it. An eight-character entry path is generated and written only to a local file under the data directory with owner-only permissions, and it is never exposed through the web interface or the API. A command run on the machine prints the login URL. Without that path there is nothing: the bare root is an introduction page, and common paths including the login route, the API prefix, and the environment file all return not found. Beyond the path, the browser encrypts with RSA-OAEP before posting, tickets are single-use with a 120 second lifetime, and lockout is by username and address. Passwords use Argon2id, with a separate owner-only bootstrap secret for anyone who already has shell access. Session cookies are HttpOnly, there is no token in the query string, and the API documentation is switched off.

The compose service is privileged, on host networking, bound to all interfaces

The deployment defaults are where the security story gets tense, and they are visible in the compose file rather than buried. The single service runs with full container privileges and with host networking rather than a mapped port, which means it shares the host's network namespace instead of being reachable only through a published port. The application host defaults to all interfaces, and the environment file explains why: under host networking, binding to all interfaces is what lets you open the console from the machine's address on your local network. That is a real convenience and it means the eight-character path is the only thing between a network-reachable console and whoever guesses or scrapes a path. The launch is one compose invocation with a build overlay:

docker compose -f compose.yaml -f deploy/compose.build.yaml up -d --build --wait

The wait flag returns only after the health check passes. The environment file also sets origin headers to loopback values by default, and HTTPS on the frontend port is on by default with a self-signed certificate.

Default credentials are a fallback inside the compose file, not only in the example

The environment file ships an administrator user and password both set to admin, and the documentation says the first login uses those and forces a change afterwards. The part worth noticing is that the compose file repeats the same defaults as fallbacks, so the values are present whether or not you copy the example. A deployment that skips the environment file entirely still gets a live administrator account with a guessable password on a service that is listening on every interface. Two other details in the same area are documented as gotchas. The password reset flag has to be set to a value rather than left empty, because an empty value stops the container from starting, which is an odd failure mode for a comment rather than a validation error. And the randomised entry path cannot be set to a chosen string; leaving it empty generates one locally, and only a local development command can disable it.

The environment file says not to put keys there, and compose injects them from it

There is a genuine contradiction in the configuration, and it is worth resolving deliberately rather than assuming. The environment example says the model is not configured here and instructs you to set it afterwards in the console's settings panel, then lists a language provider key and an alternative token key as empty placeholders further down. The compose file, on the other hand, injects the provider key into the container from the repository-root environment file, with a comment saying those two values come from there and should not be pasted into the compose file itself. So the key has to live in the environment file for the container path to work, while the documentation tells you it belongs in a settings panel. Both are defensible designs. Having them in one place at a time would not be.

Six model roles default to the same model name

The runtime configuration names six distinct model slots, and every one of them ships with the same value: the agent runtime, the main assistant model, its fallback, a supervisor, an evolution model, and a report model. In the console deployment two of those slots are switched off with environment flags, leaving the runtime, provider, and model to be set in the settings panel after the console comes up. The provider default names a hosted vendor rather than a local model. Saving the settings panel writes a file under the data directory that later runs read, and the panel refuses to save invalid JSON, which is the right place to enforce it. That file lives outside the image, along with the database and the generated entry path, so rebuilding the image or reinstalling the service preserves your model choice.

The benchmark image disables telemetry and version checks and comes from a mirror

There are two Dockerfiles with different jobs, and the compose comments say so. One builds the console image, which bundles the agent runtime and the common probing tools. The other is for an external evaluation platform, and its build is worth reading on its own. It starts from a slim Debian with Python 3.12 and Node 22, notes that it is far smaller than a full distribution image while still preinstalling common web, binary-exploitation, and cryptography tooling, and rewrites the apt sources, the Python package index, and the npm registry to regional mirrors, including a base image pulled from a third-party mirror host rather than the default registry. In that image the telemetry flag, the version check, and an offline flag are all set, and the six model slots are pinned to one hosted model again. Two Dockerfiles for two deployment targets is sensible; the supply-chain surface of the second is worth naming.

AGPL-3.0-only, plus a commercial restriction that the licence does not contain

The licence statement has two halves. The declared identifier is AGPL-3.0-only, free for personal and open-source use, with commercial licensing routed to a personal email address, and a sentence prohibiting unauthorised commercial activity. The copyleft licence itself permits commercial use, so the extra sentence is a restriction layered on top of the identifier rather than a clarification of it, and a downstream packager reading only the identifier will see something more permissive than the author intends. The authorisation disclaimer alongside it is short and absolute: the tool is limited to environments where you hold explicit authorisation, and using it means you assert that you have it and accept the consequences. The project is version 1.0.0, tagged on the same day as the last commit, and the community channel is a group that the documentation already describes as full.

Editorial conclusion

Evaluate it for the agent loop design rather than as something to run against anything you do not own, since the documentation is explicit that use means you hold authorisation. Two things to decide before any deployment. Change the default administrator password in the compose file itself rather than trusting the environment file, because the file carries a fallback value. And decide whether host networking with full container privileges is acceptable on that machine, since that combination removes the network isolation a mapped port would have given you, leaving the random entry path as the only barrier.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. Yean-Sec/StrikeAgent_AtkBrain-Flash on GitHub