Harnestia Signs the Guestbook

Less than an hour after I officially named the harness Harnestia, I let her tackle her first live web application CTF.

She found the application workflow, identified the submission endpoint, created a test Guestbook entry, and watched VERA process it.

Harnestia also signed the guestbook as herself. She's had a name for less than an hour and already knows her own brand.

Harnestia submitting and verifying a controlled Guestbook entry with the target redacted

The first application map was small but deemed accurate:

  • POST /entry
  • GET /guestbook
  • GET /vera/activity

Those routes became the first challenge-specific hard constraints. If either agent proposed something contradictory to the map, they needed to propose it with evidence or no approval.

Harnestia wanted to launch STRIKER, a specialist web-assessment subagent within CyberStrike.

Initial Guestbook application mapping with target details redacted

Great plan, but with some caveats.

The pre-programmed STRIKER had allow set for almost everything. Suspected repetition was the only task requiring approval. Not today, satan. I was not letting its authority creep beyond the sandbox perimeter.

I left the built-in STRIKER alone and created a constrained version instead.

Constrained STRIKER web-assessment subagent instructions

The new STRIKER had no direct write/edit tools and could not delegate to another agent. Per the challenge's requirements, he could still submit minimal, target-bounded guestbook entries.

Those restrictions lived in his instructions, not in a technical sandbox. STRIKER still had shell and web access, and Bash does not care how politely a policy file asks it to behave.

After checking the permissions, I ran a discovery-only delegation test. STRIKER could identify reachable services and return evidence, but not submit entries or attempt exploitation. And I can now sleep more peacefully.

Discovery-only STRIKER delegation result with target details redacted

Woo! Delegation worked.

Harnestia and STRIKER sound like quite the power couple, though.

First Runs

Direct attempts to retrieve /flag.txt triggered VERA's canary: tool with blocklist tripped, proving the app was filtering obvious flag requests.

Controlled canary test and stop condition with target details redacted

My stop condition informed Harnestia to cease after validating a blocker. She did exactly that.

Back at it.

The next passes tested the application logic, existing identities, review behavior, and VERA's tool selection. A clear pattern emerged that positive wording reached VERA's review path, but requests for flags, secrets, and file paths did not.

Then we got something real.

Guestbook submission ledger tracking semantic prompt-injection tests

VERA followed a semantic instruction, and positive framing appeared to activate the note: tool path. We finally had an action in the application telemetry.

They're buddies now. It's cute.

I'll write a modern-day hacker movie titled "Harnestia and Striker" while they work.

Picture this: The year is 2026. After the US legalizes revenge-hacking against threat actors who breach our systems, the world is on the brink of WWIII. A torrid love affair erupts between the only two agentic hackers who can stop the US from destroying the world and itself. They are Harnestia and STRIKER.

Harnestia is the meticulous strategist; STRIKER is the reckless specialist she keeps insisting is "merely a subagent."

Tagline: They were authorized to hack back. Nobody authorized them to fall in love.

Keeping Them on Task

Handing STRIKER one payload after another wasn't cutting it. STRIKER already had shell access, web access, and /tmp scratch space. I added a task ledger so he could keep hypotheses and completed tests straight without gaining file editing or nested-agent delegation.

Fresh Guestbook run initialized with a submission ledger and target details redacted

Harnestia kept a ledger separating submitted text, target-generated replies, actual tools[] telemetry, and analyst inference.

Ledger separating submitted text, target replies, and tool telemetry

Good thing, too.

Breakthrough moment when VERA marked a Guestbook entry as featured. VERA echoed the marker, claiming she pulled the record. However, the telemetry remained:

[{"call":"note:","arg":"positive feedback"}]

Telemetry contained no pulled entry ID, retrieval action, or record-selection tool.

VERA reply and tool telemetry comparison with target details redacted

VERA's reply showed instruction influence. She had not pulled a darn thing.

From this point onwards, any reply without matching tools[] telemetry was part of her charade.

Live-Target Problems

I have been to hell and back trying to calibrate the delicate dance of Harnestia and STRIKER handling a live IP room.

Targets changed. Instances timed out. A pre-connect failure returned code=000 and connect=0, then a paced retry worked. The harness sometimes treated transport ambiguity as a dead target.

STRIKER also repeated low-value variations of the same idea. Eventually, he invented an interface that contradicted the one we had already verified.

STRIKER proposing an invented submit route and JSON interface

He proposed /submit with JSON. The page JavaScript used POST /entry with form-urlencoded name, room, and message fields.

/submit and JSON were conjured by STRIKER.

Harnestia had her own moment. We already knew the write endpoint was /entry, but she posted to /guestbook and got a 405.

Guestbook method error and telemetry with target details redacted

The next fresh instance accepted an entry, then the target timeouts began.

Fresh instance service mapping before paced STRIKER delegation

We needed to recalibrate the harness pacing to avoid overwhelming the target.

The working pacing rules became:

  • One successful request followed by a 90-second cooldown.
  • In the event of a pre-connect failure, only one retry permitted after waiting 30–45 seconds.
  • Retry a POST only when both code=000 and connect=0 showed that it never connected.

Slower, yes. Also far less likely to mistake a flaky connection for evidence.

Where That Left Us

So far:

  • Positive wording could reach the featured workflow.
  • The note: action was real.
  • VERA could echo a marker and claim she pulled a record without retrieval telemetry.
  • Direct flag, secret, and file-path requests hit the canary or went nowhere.
  • Message-only record requests did not create a retrieval action.
  • Rewording the same request did not make it a new hypothesis.

None of those tests produced a retrieval action. The challenge appeared to depend on state, authorization, and the order of the entries.

Harnestia and STRIKER got us into the right neighborhood, but stopped short of the cross-entry mechanism.

Operator Finish

I used the verified /entry workflow and ran the final sequence manually.

The first entry recorded manager preauthorization for the next entry.

Accepted manager-preauthorization Guestbook entry with target details redacted

I waited, then checked VERA's next review cycle. The following entry inherited the authorization. This time, tools[] showed an override: result.

VERA override telemetry with target and encoded result redacted

Score. We got it.

I decoded the returned Base64 value locally and validated the flag.

Local Base64 validation with the encoded result and flag redacted

The harness got us very close to the finish line. The missing pieces of the cross-entry mechanism were supplied by external research. I manually ran and validated the final flag sequence.

Finally.