All projects

CrunchAtlas: AtlasCyber & PurpleHaze

Current work · 2025–

Reliable local AI where cloud assumptions break.

I build the systems that keep long-running security agents bounded, observable, and useful on local hardware. I also built PurpleHaze end to end.

This case study describes system boundaries and engineering mechanisms. It omits customer data, proprietary detection logic, exact offensive procedures, private prompts, and private source code.

01 · Operating constraint

The hard part was making local intelligence operable.

AtlasCyber has to run across cloud, on-premises, and air-gapped environments. That turns GPU capacity, long evidence sets, process failure, and provenance into product constraints—not infrastructure trivia.

  1. 01Evidence
  2. 02Durable work admission
  3. 03Governed local agents
  4. 04Inspectable analysis

02 · AtlasCyber

Deterministic scaffolding around fallible local models.

I built the serving, work-admission, execution, and agent-runtime layers as one operating system for AI-heavy security work. Each boundary exists because a worker count, a prompt, or a happy-path process tree is not a reliability strategy.

01

Prove the deployment before launch

Model serving is declarative and fail-closed. The deployment is rejected unless its declared context, concurrency, and memory shape fit the hardware budget.

02

Admit work by cost, not worker count

Postgres claims AI work under a shared token-domain budget, so task shape—not an arbitrary process count—determines whether scarce local inference capacity is available.

03

Keep agent failure visible

Workers, supervisors, child processes, streaming events, and a sweeper preserve an observable lifecycle through cancellation, crashes, process death, and abandoned work.

04

Bound fallible model behavior

Exact token accounting, tool-result eviction, compaction, parse recovery, and output-cap recovery keep long-running domain agents inside explicit operating limits.

Domain agents construct models through one boundary, while per-request serving ceilings remain separate from per-task context budgets. Generic middleware owns context policy; report and security semantics stay in their domain layers.

Per-run tool containers are read-only, network-disabled, resource bounded, and self-reaping. I do not describe that as perfect tenant isolation: narrowing the current read-only media aperture remains a separate security boundary.

03 · Product proof

The infrastructure ends in inspectable work.

Public marketing views show the boundary I can expose: evidence-backed assessment and an agent-generated report, not customer data or internal detection logic.

CrunchAtlas campaign assessment showing summarized network-security evidence and findings
Public CrunchAtlas marketing image: a campaign assessment turns collected evidence into an inspectable security result.
CrunchAtlas case view showing a structured report produced by a security analysis agent
Public CrunchAtlas marketing image: a domain agent's result is presented as a structured report rather than an opaque chat response.

04 · PurpleHaze

An autonomous engagement, built end to end.

PurpleHaze connected a local model to controlled offensive workflows while preserving the live execution state and report contracts the model could not be trusted to remember or invent.

  1. 01Scope
  2. 02Controlled execution
  3. 03Persistent session state
  4. 04Validated report
01

Engagement orchestration

Workflow and scan steps were chained into one controlled engagement rather than exposed as disconnected tools.

02

Persistent live state

Offensive-session state survived long runs and context compaction, preserving the execution state the model could not safely reconstruct.

03

Durable execution records

Tool execution and workflow state remained inspectable across the engagement instead of disappearing into an opaque chat transcript.

04

Validated reports

OWASP, NIST, executive, and supporting report structures were validated before generating final report artifacts.

05 · Delivery and edge

The same reliability boundary continues outside the agent.

Operational ownership

AtlasCyber in AWS

I own AtlasCyber's AWS footprint across GovCloud and commercial partitions: compute, object storage, IAM, VPC networking, content delivery, and the reverse-proxy and tunnel fleet that reaches deployed environments.

Completed rewrite foundation

CrunchSense v3

I rewrote the AtlasCyber edge sensor around a headless Rust daemon: BPF-filtered capture and atomic rotation, a persistent SQLite WAL upload queue, bounded retry, storage-pressure guards, machine-bound encrypted credentials, an authenticated loopback API, hardened systemd delivery, and Linux package/service smoke coverage. The UI is optional, so capture does not depend on its lifecycle.

This is a stability-oriented foundation with deliberate legacy parity still deferred.

Where it landed

Local models and security tools became one operable system with explicit admission, bounded execution, durable state, and inspectable results across cloud, on-premises, and air-gapped environments.