Dhara · Attack surface intelligence
Dhara is the audit engine we built when we wanted continuous, evidence-first attack surface monitoring without renting it from a multi-tenant scanner cloud. Passive by default, framework-mapped on output, and every completed scan feeds an intelligence graph that gets sharper with every target.
Self-hosted on a lab server we operate. Sovereign Ollama for AI-assisted analysis. Reports a CISO and a founder can both read.
Surface signal
Status
LIVE
Posture
Passive-first
Engine
dhara.eleven11.pro
Why this exists
An incident, a customer questionnaire, a competitor's recon email, a scanner report from the vendor doing the SOC 2 audit — that's usually how the conversation starts. By then the surface has already been mapped by people who weren't asked, and the team is reacting instead of choosing.
Dhara is the version of that mapping that you commission yourself, before the noise. Passive recon, evidence-first findings, mapped to the framework you're already being audited against — so the report a security buyer reads is the same one a founder can act on.
Self-sustained by design
A scanner you do not operate is a scanner that decides for you what is safe, what is in scope, and who gets to read the findings. Dhara is built so those answers stay on a server we administer — and so the surface map is yours to commission, share, and revoke.
01
Passive by posture, not by accident.
The default profile sends zero packets to the target origin. DNS posture, certificate transparency, takeover candidates, public asset lookups — every signal comes from records the internet already publishes. Permission-touching is gated behind a separate, signed authorization step.
02
Self-hosted, on a box we administer.
The audit engine runs on a dedicated lab server we operate, not a multi-tenant cloud sharing your scans with somebody else's tenants. SSH-only management plane, Cloudflare Access on the operator UI, scoped service tokens for server-to-server callers.
03
Sovereign Ollama for the AI parts.
When AI assists triage or report drafting, it runs on the Dhara Ollama endpoint — CPU-only inference on the same lab server, API-key gated. Your findings are not shipped to a frontier provider for analysis. BYOK is supported when you want a different model.
04
HMAC-signed offensive scope.
Anything beyond passive observation requires two gates: a daily-rotating HMAC token derived from a key only the lab server holds, and a scope.json the operator commits before the run. There is no UI button that escalates a recon into an exploit by accident.
05
Reports you actually own.
Every completed scan renders four HTML variants from a typed report.json — auditor-facing, developer-facing, plus the v2 Launch Design pair. PDFs ship alongside. Share links are HMAC-signed with revocation. Re-render and hard-delete are first-class operator buttons.
The primitive
Dhara is built on a small, opinionated trio — a scan to anchor the engagement, a finding to carry the evidence, and an intelligence webhook so every run compounds across targets. Everything else — profiles, share links, reports, exploit gates — is a function over those three.
01 · Recon record
POST /api/audit
A typed run against one target, anchored to a profile (recon, quick, standard, deep). Carries the scope, the engagement trail, and every artifact the kali container produced — not a black-box invocation, an addressable record.
02 · Evidence
report.json · jsonl evidence
Each finding is a row with severity, framework hits, and the raw evidence that produced it. The compliance summary is derived, not authored — what shows up under HIPAA or ABHA-FHIR is the projection of evidence onto controls, not a marketing claim.
03 · Cross-target signal
POST e11-discovery /v1/hooks/dhara
Every completed scan posts the full report into the discovery knowledge graph. Findings, tech fingerprints, and exposed assets accumulate across engagements — so each new target is read against the lessons of the previous ones, not from zero.
How it fits the fleet
Dhara is not a standalone scanner that prints a PDF and forgets. It is a producer the rest of Eleven11 reads from. Findings flow into discovery, events flow into alerts, recon teasers flow into outreach, widgets render into architect — the flywheel is the proof of accumulating engineering value.
discovery
Receives every completed scan via the dhara hook and upserts findings + tech fingerprints into a cross-target knowledge graph. The operator intelligence UI reads patterns, surface risk, and CVE rollups from there — making the next scan sharper than the last.
alerts
Worker fan-out fires scan.completed, scan.critical, scan.regression, and scan.failed into the alerts hub. Routes pick those up for sales-slack, on-call, or customer email — same event bus the rest of the fleet publishes against.
outreach
Outreach is the inbound consumer, not just a downstream. Its worker queues recon-profile scans against cold prospects, polls the job, and the teaser extractor reads the same passive top_findings + framework_hits dhara emits — so the first-touch email is grounded in real surface, not invented.
operator
The admin plane calls dhara as a server-to-server caller via x-api-key plus Cloudflare Access service tokens. Re-render, hard-delete, schedule managed monitoring, issue signed share links — every dhara surface a human touches has a typed operator counterpart.
architect
Architect renders dhara findings as widgets inside matter pages and the canvas. A surface concern that lands as evidence on the lab server shows up next to the prose where the team is actually deciding what to do about it.
ollama (sovereign)
AI-assisted triage and lab workbench calls route through the Dhara Ollama endpoint — same physical server, API-key gated, CPU-only. Other e11 tools (architect, pr) call the same endpoint when they want sovereign inference instead of a frontier provider.
Surfaces & contracts
One operator UI a human opens; a small set of typed routes the rest of the fleet calls. The smallest contract that does the job — no plugin marketplace, no integration wizard.
https://dhara.eleven11.pro/
Operator UI
The single-page console that runs scans, watches the queue, opens reports, and issues signed share links. Cloudflare Access at the edge — no multi-tenant login, no public dashboard.
POST /api/audit
Run a scan
Server-to-server entry. Profile + target in, job id back. The recon profile is safe to run against any target without prior authorization; quick, standard, and deep require explicit posture.
POST /api/scope/<target>
Authorize offensive
Commits a scope.json with include/exclude patterns and allowed actions. The exploit pipeline refuses to run without this row plus a daily-rotating HMAC token derived from a key only the lab server holds.
GET /s/<token>
Signed share link
Time-bounded, HMAC-verified, DB-backed revocation. The CISO-facing v2 report variant sits behind it with the v1 pair kept on disk so legacy links still resolve.
POST /v1/hooks/dhara
Discovery webhook
The fleet-side contract. Outbound from the audit worker after every completed scan; consumed by discovery's integrate queue. This is how the intelligence flywheel actually accumulates.
https://dhara.eleven11.pro/ollama
Sovereign Ollama
API-key-gated Ollama endpoint living on the same lab server. Used for AI-assisted analysis inside dhara and by adjacent e11 tools that want sovereign inference instead of a frontier provider.
Senior engineering, visible
Five decisions visible in the profile gating, the HMAC-token shape, the report renderer, the outbound headers, and the deploy choice — not adjectives, design choices.
Profiles, not knobs.
Recon, quick, standard, deep — four named postures, each with a baked-in legal stance and rate envelope. Recon explicitly skips the active stages (no naabu, no nuclei, no sqlmap) so the API can refuse the recon + offensive combination at the gate.
Two-gate offensive.
An exploit run requires both a daily-rotating HMAC token and a committed scope.json. Either missing, the run refuses to start. There is no path where a UI click escalates a passive engagement into an active one without a signed step.
Reports are derived, not edited.
report.json is the typed source. Four HTML variants — auditor v1, dev v1, audit-v2, dev-v2 — render from it; the v2 pair carries the Launch Design system shipped in 2026-04. Re-rendering a finished scan never re-runs the engine; it re-projects the evidence.
Outbound producers carry their UA.
Webhooks send User-Agent: dhara-worker/1.0 — Cloudflare silently 403s default urllib UAs with error 1010, and we paid that lesson once. Every new outbound caller in the fleet inherits the same hygiene.
Bare-metal deploy, by choice.
No GitHub Actions, no GHCR pull. Changes ship via SSH on port 77, files copied to ~/lab/audit/, services restarted under systemd. The audit engine is intentionally a separate trust zone with a different deploy shape from the rest of the fleet.
Who this is for
Dhara earns its keep when the cost of someone else mapping your surface first starts to exceed the cost of commissioning the read yourself.
FAQ
Recon profile is built around that question. It only reads records the internet already publishes — DNS, certificate transparency, public asset databases, historical URL archives — and sends zero packets to the target origin. The active profiles (quick, standard, deep) require explicit authorization and gate the offensive stages behind a signed scope.
Editorial broadsheet design, paper-first, Geist + Geist Mono — the same Launch Design system every customer-facing artifact in the fleet carries. CISO-facing variant for compliance, dev-facing variant for the team that has to fix things, both rendered from a single typed report.json. PDFs ship alongside. The 2026-04 v2 redesign is what dhara renders by default.
Every completed scan posts into the discovery knowledge graph. Findings and tech fingerprints accumulate across targets, so the same recon run against a new domain reads against the patterns we have already seen. Pattern, surface-risk, and CVE intelligence read off that graph, not a public CVE feed.
Today dhara runs as a single lab server we operate, with managed scans the default delivery. Self-hosted deployment for regulated and EU buyers is the next packaging — talk to us about your trust boundary and we will scope what that looks like.
Discuss Dhara
Dhara runs managed audits today. The recon profile is free to point at any domain you own; quick, standard, and deep require a short authorization step. Talk to us about the framework you are being audited against and the surface you want a read on.
Direct line
Consultation requests stay owned. We reply from e11 after reviewing fit and timing.
