​
The Golem Agent

Golem is the autonomous red-team operator that runs the deep phase of every audit. It is not a scanner. It plans its own attack chain, executes real commands in a real shell, observes the results, and iterates.

​
Operator semantics

Golem operates with the semantics of an external attacker:
  • External-attacker POV, enforced — the system prompt mandates it, and no customer-supplied stack hints, credentials, or environment files are ever sent to the sandbox
  • Outcome-oriented — engagement isn’t done until the objective is met or time runs out
  • Evidence-driven — every finding is backed by raw artifacts from successful execution
  • Persistent — won’t abandon an attack vector after one failed attempt

​
What the agent has access to

Inside the darkops sandbox, Golem has:
  • Bash — arbitrary shell execution with no allowlist
  • The full offensive toolkit — pre-installed at sandbox boot
  • Browser — Chrome + selenium for JavaScript-heavy targets and authenticated flows
  • Out-of-band callbacks — interactsh for confirming blind SSRF, XXE, and deserialization
  • Network access — outbound connectivity to attack any reachable target

​
The decision loop

For each engagement, Golem runs in a loop:
Findings are streamed into the audit as they’re confirmed — not batched at the end.

​
How findings are submitted and validated

Golem submits every finding through a dedicated report_finding() tool call — never by emitting text. This structured submission is validated in real time before the finding enters the audit:
  1. Execution ledger check — the cmd_id cited in the evidence must reference a real command the agent actually ran in this engagement, with exit code 0 and actual output. An agent cannot claim a finding based on a command it fabricated or one that produced no response.
  2. Stack fingerprint check — every bash output and observed URL is monitored throughout the engagement to confirm which technology stacks are present. If a finding claims a stack-specific vulnerability (e.g. Jinja2 SSTI, Firebase rules, WordPress RCE), that stack must have been fingerprinted from actual recon output. Claims about stacks that were never observed are rejected immediately.
  3. Post-hoc verifier — after the engagement ends, a second verification pass cross-checks each finding’s evidence against the full execution ledger and replays read-only curl commands to confirm live responses match what the agent claimed.
A finding that fails any of these checks is dropped, not downgraded. The pipeline is designed so that a false positive costs the model a [finding_rejected] response and nothing else — rejected findings never reach the audit.

​
How it plans

Golem’s planning is model-driven, not a fixed playbook. Its decisions are informed by:
  • The mission brief (mode plus security focus areas plus autonomous scope, if provided)
  • The full session history visible in its context
  • The output of every previous command
  • Stack-fingerprint state (what’s been confirmed on the target)
The agent will sometimes abandon a phase early if it’s not producing results, or spend disproportionate time on a single asset if it’s yielding findings. This is intentional — it mirrors how a real operator allocates attention.

​
Pressure injection

If the agent narrates without acting, the orchestration layer injects pressure prompts to keep engagements moving and prevent reasoning loops. Real operators don’t write essays — they execute.

​
Time discipline

The agent runs against a hard budget per mode and is force-stopped at ~92% of it, with a clear instruction to stop attacking and write the final report. Even on a forced stop, you receive everything confirmed before the cutoff — and the coverage summary records what was and wasn’t completed.

​
CVE intelligence is display-only

Golem maintains a live CVE catalog (see CVE Intelligence), but it is never fed into the agent. The agent doesn’t see CVE data in its prompt, CVE status never mutates finding severity, and known-CVE scanning never adds probes. Findings come from what Golem actually observes — not from a vulnerability database.

​
Next steps

Attack Methodology

The phased chain Golem follows.

Toolkit

Everything pre-installed in the darkops sandbox.