Supporting technical project · Security engineering

Reconductor

A safety-first reconnaissance copilot for authorized labs and CTFs, built around explicit scope, typed actions, human approval, evidence provenance, and a read-only review workspace.

Reconductor read-only service inventory showing synthetic scoped hosts, normalized services, and evidence provenance.
The read-only workspace keeps scope, observations, and artifact provenance in the same review surface. All displayed data is synthetic.
For
Security practitioners who need to review reconnaissance evidence without allowing an assistant or browser interface to act outside an authorized scope.
Role
Product architecture, control design, API and dashboard implementation, and validation
Evidence
Curated public case study with reviewed local artifacts

The problem

Why this needed to exist.

Reconnaissance tooling becomes unsafe when authority, target scope, evidence provenance, and the boundary between a recommendation and an executed action are left implicit.

Defining decision

Make authorization, scope, typed actions, and human approval part of the product model rather than relying on operator intent alone.

Approach

How the system was shaped.

  1. Made authorization and scope first-class records, then revalidated targets before any supported action.
  2. Restricted active work to typed actions and a human approval gate; model output can propose but cannot execute.
  3. Normalized imported evidence, retained provenance, and exposed a read-only workspace for reviewing services, findings, and supporting artifacts.

Tradeoffs

What the design chooses—and gives up.

  • Narrow typed actions reduce flexibility in exchange for an inspectable safety boundary.
  • The default deterministic provider favors reproducibility over broad real-world inference.

Evidence

What can be inspected.

  • The default demonstration is deterministic and does not scan a network.
  • Imported evidence is scope-checked, normalized, and linked to SHA-256 provenance.
  • The dashboard is read-only and cannot start, approve, queue, or execute a run.

Limitations

What this does not claim.

  • Real execution is opt-in and limited to a policy-checked internal Docker network.
  • The case workspace remains a local development foundation, not a production multi-user application.

Lessons

What carries into the next system.

  • A credible security copilot needs a visible distinction between observation, recommendation, approval, and execution.

Open to the right conversation

Want to connect this technical example to the professional work?

Use the case study as a supporting example, then start with the customer, commercial, or operating decision that matters for the role.

Start a conversation