I’m building a framework that treats security agents as a collective organism. In the Zero Noise Collective, we move away from "Top-Down" filtering logic. Instead, agents use local feedback loops to determine what constitutes "vital signal" versus "background noise."
By applying morphogenetic principles, the system adapts its own "detection shape" in real-time. If you’re interested in:
Decentralized coordination in high-volume (40PB+) data streams.
Self-organizing filters that don't require manual regex updates.
Complexity science applied to the "Alert Fatigue" epidemic.
I'd love to discuss the technical trade-offs of letting a collective of agents decide what is "important" without a human in the loop.
Most "AI in Security" talk is marketing fluff. I wanted to see what happens when you actually deploy a closed-loop, self-optimizing architecture in a production environment.
We ran a pilot using the stack I’ve been documenting—EBMs for scoring, RL for playbook optimization, and automated schema inference for ETL. The results after 16 days were:
71% reduction in Mean Time to Detection (MTTD).
68% drop in playbook execution time.
50% fewer false positives.
The most important part? We didn't rewrite a single rule by hand or hire new engineers. This post is the final summary of how these components (Governance, Infra, and ML) work together to create a defensive system that actually gets smarter the more it's attacked.
Moving a machine learning model from a Jupyter notebook to a production environment that scores millions of events in real-time is an infrastructure nightmare.
For a long time now, I worked on a "Detection as a Global Service" architecture using Energy-Based Models (EBMs). To hit a p95 of <100ms per event across three continents, I had to move away from centralized scoring. This post deep-dives into the stack:
Regional Inference Nodes: Using TorchScript-compiled models on T4 GPUs.
Model Sync: Using a CDN/Blob storage layer for global versioning and hotfixes.
The Latency Trap: Why centralizing your security logic is a bottleneck for modern threat response.
I've included the actual latency and accuracy metrics (99.9993% accuracy) and how I handle model drift without taking the system offline.
If an autonomous system shuts down a production database during a false positive, who takes the heat? This is the primary blocker for AI-driven SecOps today.
I’m sharing my research on moving from "Full Auto" to "Tiered Autonomy." By using a policy engine that maps AI actions to legal and privacy escalation rules, we’ve created a system where the "human in the loop" is optional for low-risk events but mandatory for high-impact ones.
I’ve included a real-world case study of a healthcare organization where the AI detected an anomaly but voluntarily stepped back from auto-quarantine because it flagged a potential HIPAA/Privacy conflict. I'd love to hear how other engineers are handling the legal "veto" in their automation pipelines.
The industry has spent a decade perfecting "Detection," but "Response" is still stuck in the era of manual runbooks. If your playbooks aren't being tested against synthetic threats weekly, they’re probably already broken.
This is the final piece of my research on autonomous SecOps. It focuses on the Optimization Layer:
Triggering via EBM scoring.
Evaluating outcomes via reward functions.
Optimizing via RL/Genetic Algorithms.
Promoting better versions to production automatically.
I’m curious—how does the HN community feel about "Auto-Promoting" security logic? Is the risk of a "false positive" containment worth the 5x speed increase in response?
Dealing with 40PB of logs means you can't afford to have humans in the loop for every new data source.
We’ve built a pipeline that treats log ingestion as a dynamic feature engineering problem. By using schema inference and automated feature extraction, we feed raw telemetry directly into Energy-Based Models (EBMs).
The interesting part isn't just the ingestion—it's the feedback loop. When the system sees a new risk, it creates and optimizes a SOAR playbook via simulation. This post covers the "Step 1 to Step 6" of moving from raw text to an optimized, autonomous response.
One of the biggest bottlenecks in security is the "log onboarding" tax. If an engineer doesn't know the schema, the data often just sits there or breaks the pipeline.
Long ago, I started to build loops that uses schema inference in the ETL stage to enable true zero-touch ingestion. Once the data is in, we use Energy-Based Models (EBMs) to find anomalies (High Energy = Uncertainty).
The real kicker: the system then validates the response via simulation. If a playbook misses a high-energy event, the optimization engine flags it for an update. We've seen a 57% MTTR improvement using this "Build Once, Learn Always" approach. Curious if anyone else is using schema inference for high-volume security telemetry (40PB+ scale)?
Signature-based detection and labeled ML classifiers only see what they’ve been told to see. In a SOC, the real threat is the behavior that doesn't show up in a feed.
I’ve been researching Energy-Based Models (EBMs) as a way to ditch labels entirely. Instead of teaching a model what "bad" looks like, we teach it what "normal" looks like across 40PB of data. The result was a 0.97 ROC-AUC and the detection of scripted service account activity that mimicked normal logins but had minor behavioral deviations.
I’m sharing the research on why EBMs outperform static rules and how to implement them without drowning in the false positives that usually plague unsupervised learning.
By applying morphogenetic principles, the system adapts its own "detection shape" in real-time. If you’re interested in:
Decentralized coordination in high-volume (40PB+) data streams.
Self-organizing filters that don't require manual regex updates.
Complexity science applied to the "Alert Fatigue" epidemic.
I'd love to discuss the technical trade-offs of letting a collective of agents decide what is "important" without a human in the loop.