Capabilities.
Bedim Security runs a complete security operations capability as one autonomous system — a Wazuh sensor fabric, an agentic AI analyst, machine-speed DISA STIG compliance, and hardened infrastructure. It runs continuously on our own estate, and every claim on this page is backed by a live screenshot or an unedited recording from that environment.
The premise
Most security programs buy a SIEM and staff it. We built the inverse: a small, fully open-source stack in which software does the watching, the triage, and the checking — while a human sets policy and reviews the exceptions. The estate it defends is real: Proxmox VE clusters, Linux and Windows hosts, mail and web services, lab targets. The result is a security operation that exercises itself every day and keeps the evidence to prove it.
Sensor fabric — Wazuh
Every machine in the estate runs a Wazuh agent feeding a central manager over an encrypted channel. Log data, file integrity monitoring, vulnerability detection, and Security Configuration Assessment stream into the indexer — currently holding more than 1,040,000 alerts from a fleet spanning Linux, Windows, and macOS, bare metal to containers.


Configuration compliance is measured, not assumed: the Security Configuration Assessment engine runs DISA-mapped policies per platform — Ubuntu, RHEL 9, Windows, vSphere, Proxmox VE — and feeds those scores straight into the compliance pipeline.
The analyst — agentic AI on duty
Alerts don’t keep business hours, and neither does the analyst. Our SOC runs six registered specialist agents under a single coordinator — alert triage, IOC enrichment, incident review, report narration, reply drafting, and communications. Findings become tasks; tasks become remediations; remediations become evidence.

The task board tracks every automated scan, remediation ticket, and accepted-risk exception — 100+ records, each with an owner, a finding reference, and a resolution path. An append-only audit log ships off-host every five minutes.
Every alert decided in-house — the Laya decision engine
Alert dispositions used to ride on a language-model call per alert: a 90-second ceiling, 65 percent of decisions hitting it, and a 21-second median on the calls that did land. That path is retired. Each alert now passes a deterministic gate on the SOC host and receives exactly one local inference from Laya, our typed-decision model — bound to loopback, so nothing about the alert stream leaves the machine. Median decision: 1.1 seconds. P95: 1.6 seconds. The same alert always receives the same disposition, and every decision lands in the audit log with its duration and outcome attached — measured over the live decision log, not a benchmark.
The gate changed what reaches a human, too. Noise-class alerts fold into the daily digest instead of firing a narration turn each — the last 150 consecutive dispositions were digest-only, and the per-alert email flood that used to cost a model turn per alert is gone. Genuine escalations still page, still open tickets, and still get the full agentic stack behind them.
The full engineering record is published: the Laya 300 status & power report (measured: −74% GPU energy, 16× decision latency, 94.6% agreement over a 452-decision soak), the practical usage guide, and the setup & validation demo guide. A second-host replication run (2026-09-28) is documented in the eval-host comparison report: same 300-state eval on a Ryzen 7 7800X3D — 1.6× faster, 100% identical answers, −20% energy per decision.
All Laya reports, guides, and the control-plane repo are indexed at laya/.
Local by default, cloud on reserve
The model inventory lives on the SOC host — Qwen, Llama, Gemma, Mistral, and a local embedding model — so the SOC’s routine management runs on hardware we own, and the alert path keeps deciding even if the internet doesn’t. Standing cloud access is configured but dormant: when a job genuinely needs more agentic power — a deep investigation, a large-context analysis — the coordinator escalates that one task to hosted models and pays only for what runs. Reserve, not baseline: nothing in the alert path dials out, and losing the cloud link parks the optional bursts, not the decisions.
A note on the name. Executive Order 14434 (“Inaugurating the Era of Super Intelligence,” September 29, 2026) directs federal agencies to write “Super Intelligence” and “SI” in place of “Artificial Intelligence” and “AI” — and defines SI as the same technologies the existing statutory “artificial intelligence” definition already covers. That is a renaming of vocabulary, not a change in capability. Our work stays what it is: agentic automation for security operations — measurable, deterministic, and logged, a different realm from what “super intelligence” implies. The full text: Executive Order 14434 at the White House, and the Federal Register notice of October 2.
Compliance at machine speed — stig-baselines
stig-baselines is our open-source DISA STIG engine: checklists (CKL) generated from vendor XCCDF for 22 platforms, live OpenSCAP evaluation of running systems, bulk CSV dispositions applied in seconds, and multi-STIG merges into a single checklist. The same engine scores compliance continuously against NIST 800-53 families.
Live OpenSCAP evaluation → populated DISA CKL
An actual OpenSCAP STIG scan of a Rocky 9 VM, converted to a fully populated DISA checklist — executed autonomously, unedited.
Recording: gist 23d66481 · tooling: stig-baselines
Bulk dispositions & multi-STIG merge
Eight CSV dispositions applied into a DISA RHEL9 checklist, then a second STIG merged into one multi-STIG checklist — the assessment workflow end to end.
Recording: gist e355b12d · tooling: stig-baselines (csv2ckl, merge_ckl)
Hardened infrastructure — Proxmox VE
The same discipline applies to the hypervisor layer. The PVE-STIG kit ships an assessment scanner, a dry-run remediation tool, a governed exception mechanism, and continuous SCA auditing of cluster nodes. High availability is exercised, not asserted: when a node dies, the cluster fences it and relocates the workload — recorded live.
Automated PVE-STIG hardening
A real run on a Proxmox VE 9.2.20 cluster node — baseline scan, dry-run, remediation, idempotency verification, and the post-hardening scan.
Recording: gist 7ee7c4b1 · tooling: stig-baselines (baselines/proxmox)
Live HA failover
A cluster node is killed. The cluster detects the loss, fences the node, relocates the workload, and moves it back after the node rejoins.
Recording: gist 80c10e27 · build & HA guide: stig-baselines (docs/proxmox)
Patch & exposure watch — what needs attention, and when
The newest member of the platform joins three sources into one standing report: the vulnerability detector’s live findings tracked against installed software and hardware (92,556 findings indexed at publish), the Wazuh agent enrollment state, and a per-device sweep for pending operating-system updates. It runs on a fixed schedule (06:20 UTC) and the operations console re-reads the same report on every load — no cache to go stale.
The point is not a wall of data. The report identifies what and when attention is needed: this morning’s automatic run flagged 205 pending package updates across 17 enrolled devices (34 security-classified), put one host on a reboot-required list, and aged every open finding — how long since a device was last patched, since a finding was first seen. Ages make drift impossible to miss, and a dated history line per device per run is written to evidence storage, so the patch-age trend builds over time.

Live tooling — KEV × STIG coverage checker
A live routing table between CISA's known-exploited vulnerabilities catalog and the DISA STIG baselines we maintain — per-CVE checks, a platform scoreboard, and the honest uncovered gap, with a public API. Refreshed daily by an automated job. Open the checker.
Out-of-band SOC — two machines no one can reach
The operations center itself, rebuilt out of band: two VMs — Rocky Linux 9.8 and Ubuntu 24.04 — on the lab bridge that boot with no NAT device and no default route: zero internet path, by design. Cloud-init seeds install the Wazuh agent on first boot; both agents enroll on their own and report to a dedicated wazuh-manager 4.14.8 container on its own bridge IP, and its findings land on the store disk.
Everything the build consumes is gathered, sha256-verified, and served from a storage container on the same bridge first — the OS media (645,988,352 and 625,612,288 bytes, verified), the agent packages (11,151,656 and 13,227,800 bytes, verified), and the signing key. The full procedure is published as two gists: stage 1 — the store + serving container, stage 2 — the VMs + the manager.
The proof
- Continuous, not annual. The healthcheck suite runs 31 automated checks across the stack hourly — all green at the latest hourly run. The compliance grading refreshes daily, mapped to NIST 800-53 families.
- Decided in-house. Every alert disposition is computed on the SOC host by a local decision engine — 1.1 s median — with cloud capacity held in reserve. Alert handling never waits on a remote API.
- Governed exceptions. Every accepted risk carries a reason, a finding reference, and an expiry — exceptions are visible evidence, not silent gaps.
- Evidence by default. An append-only audit log ships off-host every five minutes; every scan, ticket, and exception is tracked on the board.
- Open source, self-hosted. stig-baselines, soc-openclaw, and the automation that ties them together are public on GitHub — nothing here depends on a vendor appliance.