The Scan Never Reached the Login.

One target, two different demonstrations

The opening bypass is visible, but the actor is the presenter. OWASP Juice Shop documents its login injection challenge as an intentional training vulnerability. That makes it a reasonable test target in an isolated, authorized environment. It does not make a manual solution a Strix result.

The Strix architecture is substantial enough to inspect: the public repository and skill documentation describe specialized knowledge loaded into agents, while its scan modes offer different depths and time budgets. Those materials establish design and intended behavior. They do not measure detection coverage on this run. The video's promise that an agent will try techniques across every endpoint remains a product claim until a completed test records which endpoints it actually reached.

A vulnerable target plus an agent designed to test it is a test setup. The finding begins when the agent reaches the target and produces a reproducible proof.

Ten text turns reveal a configuration question

The presenter reports that his local model produced text on each of the first ten turns, so Strix could not execute a tool call and never reached the login form. The video attributes that experience mainly to weak local-model reasoning. Strix's local-model guide gives a more specific diagnostic: its agent requires native, structured tool_calls. If a model or inference server emits an apparent call as plain text, Strix cannot run it. The guide points to server tool parsing, chat templates, thinking mode, and context size as things to check. It also warns that smaller models can struggle even when configured correctly.

Without the model identifier, server configuration, raw response shape, and run log, this video cannot isolate which failure mode occurred. The observed result is narrower and firm: this local stack made no progress on the target. The paid-model attempt reportedly made real tool calls, but quota ended the run before a confirmed finding. A call proves that one integration step worked; it does not prove coverage or a detected vulnerability.

Make the next run inspectable

A useful follow-up would begin with a bounded, authorized target and a declared scan mode. Record the Strix revision, model and provider, inference server and tool-call configuration, budget, time limit, and exact target scope. Keep the run artifacts showing completed status, actions taken, reachable pages or endpoints, reported findings, and a minimal reproduction for each confirmed issue. Repeat the same target with another model or configuration to see whether failures are reproducible.

OWASP's Web Security Testing Guide treats automated tools as useful parts of a broader testing method and stresses their limits on application-specific logic. Even a completed Strix run with zero findings would need a coverage statement; it would not certify the app secure. The video's final prediction that a properly funded model will fulfill the product's promise is plausible as a hypothesis, but its own attempts have not tested it to completion.

Keep the permission boundary explicit. Strix's documentation says to test only applications you own or have permission to test. Agent execution can send live requests and attempt exploitation, so scope and approval are part of the experiment, not an afterthought.

GhostMesh's own takeaway: keep a scan's proposal, tool calls, completed actions, and verified findings distinct. For any future GhostMesh evaluation, we would retain a source-bound run record and require a reproducible result before publishing a vulnerability claim or authorizing a remediation.