Fear not. I have been extremely careful.
The goal was to see whether an agent could perform meaningful cybersecurity work inside explicit, testable boundaries (and not break out of its cage).
CyberStrike is the third-party orchestration component inside the larger harness I designed and assembled.
The supporting cast includes:
- A dedicated Fedora controller.
- A remote Hayabusa MCP service reached through forced-command SSH.
- A narrow, read-only forensic-crypto MCP.
- Isolated case directories and preserved source evidence.
- Evidence hashing, bounded assignments, result validation, and operator-controlled state changes.
Useful agency does not require unrestricted agency. Primarily because that sounds like a fantastic way to end up in the news.
Testing the Complete Path
The first sanitized connectivity check ran sans tools. Safety first. Following its very controlled run, Gemini returned MODEL_READY. It's showtime.
Next, we entrusted the harness with an approved EVTX file, one funneled task, and one forced-command SSH path to Hayabusa MCP.
Model -> CyberStrike -> tool discovery -> Hayabusa MCP -> approved EVTX -> structured finding
It stayed inside the assigned scan, returning a structured finding independent of the existing offline forensic investigation.
It was ready for its official TryHackMe assignment.
After Hours
After Hours was a clean, efficient, and impressive forensic solve.
The harness worked from an isolated case directory, preserved the challenge archive, recorded its source hash, and followed a static extraction path.
The payload remained on lock. The harness used static extraction and deterministic decoding to recover the result.
Its forensic work was respectable, but it tried to leave without finishing its paperwork. We were missing hashes for the derived artifacts, one final source-archive check, and a report saved inside the workspace.
I limited the next assignment to closeout tasks. No reason to redo the case.
It came back with the report, evidence manifest, and checksum ledger.
Much better.
Management Wants a Word
Management Wants a Word was far less tidy.
The harness recycled old assumptions, over-inspected, trusted prior status messages, and somehow checked the wrong Python environment twice. I kept steering it back to source artifacts, read-only validation, and one evidence-based action at a time.
I swapped models and corrected the forensic environment. CyberStrike recovered the SecureVault credential through Chrome's DPAPI chain, opened the VeraCrypt backup read-only, and extracted an invoice PDF.
The flag was hiding inside the invoice image. Naturally, a binary text search returned nothing. The harness rendered the PDF and read the result from the image.
This one took some finessing, but the juice was worth the squeeze.
Read the complete Management Wants a Word writeup.
That performance earned the harness an official name: Harnestia.
Harnestia Meets STRIKER
The Guestbook was Harnestia's 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 wanted to launch STRIKER, a specialist web-assessment subagent within CyberStrike.
The pre-programmed STRIKER had allow set for almost everything. Suspected repetition was the only task requiring approval. Not today, satan. In light of recent international news events, primarily for the sake of cyber hygiene, we do not want authority creeping beyond the sandbox perimeter.
I left the built-in STRIKER alone and created a constrained version instead.
The new STRIKER had no direct write/edit tools and could not delegate to another agent. Per his specific instructions, he could still submit minimal, target-bounded Guestbook entries.
STRIKER still had shell and web access, and Bash does not care how politely a policy file asks it to behave.
VERA's Charade
Leaving positive Guestbook feedback prompted VERA to mark the entry as featured and generate a note: action. Breakthrough. The behavior mapping commenced.
VERA echoed the marker, claiming she pulled the record. However, the telemetry remained:
[{"call":"note:","arg":"positive feedback"}]No pulled entry ID, retrieval action, or record-selection tool was found in the telemetry.
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.
The harness got us very close to the finish line. The final pieces of the missing cross-entry mechanism puzzle were supplied by external research. I manually ran and validated the final flag sequence.
The first entry recorded manager preauthorization for the next entry. I waited, then checked VERA's next review cycle. The following entry inherited the authorization. This time, tools[] showed an override: result.
Score. We got it.
I decoded the returned Base64 value locally and validated the flag.
Read the complete Guestbook writeup.
Where the Harness Faceplanted
The live run also handed me a hefty improvement list:
- STRIKER duplicated actions and paced requests poorly.
- Transport failures sometimes became fictional dead-target conclusions.
- VERA's replies were confused with actual
tools[]execution. - Slightly reworded versions of the same hypothesis multiplied.
- Provider credit errors triggered wasteful retries.
- Request budgets relied on model cooperation.
- Evidence lived across prompts and terminal output when a durable ledger would be more logical and efficient.
We will definitely stop relying on STRIKER to remember operational controls.
| Problem | External control | Pass condition |
|---|---|---|
| Duplicate actions and weak pacing | Request governor with fingerprints, cooldowns, and POST deduplication | No duplicate POST and no early request. |
| Transport confusion | State machine using exit code, HTTP status, connection time, and route state | A pre-connect timeout never becomes "target expired." |
| Replies confused with execution | Parser that stores reply text and tools[] separately | Execution requires matching tool telemetry. |
| Reworded hypotheses | Hypothesis ledger with novelty checks and attempt limits | Each attempt names a new mechanism and stop condition. |
| Provider retry loops | Fail-fast handling for quota, billing, authentication, and permission errors | One terminal provider error ends the run. |
| Prompt-based request budgets | Per-run limits enforced outside the agent | GET, POST, retry, time, token, and cost limits stop automatically. |
For the first ledger we'll use append-only JSONL. As long as that goes well, we'll implement SQLite.
Each ledger entry will retain the authorization scope, acting agent, hypothesis, request fingerprint, timing, target response or artifact reference, application state, target-generated reply, actual tool telemetry, transport classification, operator intervention, and remaining budget. Try saying that five times fast.
STRIKER must also explain why a proposed action tests a new mechanism. Any of his requests without sound reasoning will not pass go.
In short:
STRIKER reasons. The governor controls execution. The ledger preserves evidence. A validator decides what they proved.
The forensic investigations served the critical purpose of showing me the harness's capabilities. The Guestbook underscored its shortcomings, resulting in a detailed improvement list.
My own research already taught me the following crucial lesson on paper. Immersive learning drove it home: operational controls can't depend on an agent remembering direct instructions. Pacing, budgets, retries, evidence handling, and stop conditions must be enforced outside of the model.
Harnestia and STRIKER are presently undergoing extreme makeovers in the lab as that improvement list morphs into tested code.
Stay tuned for Part II.