The field at the top is the landscape. Three sources have a triage adapter built and stream: Wazuh, Azure sign-in, syslog. The dim ones are real sources from the other projects on this page, waiting on an adapter. The dark ones are everything else a SOC sees. Every source has its own shape and its own idea of what a field is called; this is the SIEM side of the work, getting data in and knowing what it looks like before anything judges it.
Every source is mapped into one schema, so every later stage sees one shape of event. This is unglamorous and it decides alert quality: a detection written against inconsistent fields fires on the wrong things and misses the right ones. Most of the tuning work in the lab turned out to be work.
Anyone who can make a request against a system can put a sentence in its logs. Once a model reads those logs, the log line is the attack surface. A four-layer sanitizer strips out of the text before the model sees it, working on the normalized event so it knows which field a suspicious paragraph is sitting in.
Context is added to the event before it is judged. The hard part is not fetching context, it is deciding what to trust: an enrichment source can be stale or wrong, which is why it later counts as only one of three signals, not as the truth.
A three-call model pipeline classifies the alert and explains its reasoning in plain language. The output is an opinion with a justification, not a decision. Making a model useful in a SOC is mostly about being precise on that distinction.
A tiered response policy decides how far the response may go. This is the automation layer: playbooks, Python tooling, and response gates that name, in advance, which actions an automated step is allowed to take on its own and which it is not.
This alert reached . The gate holds. Isolating a host only happens when three independent signals, computed three different ways, all agree, and the model's verdict is only one of them. Any one of the three dissenting stops the action and hands it to a person, with the disagreement spelled out. The capability was the easy part; the failure modes were designed first.
The reason I think about it this way: I also build and operate a production SaaS, solo, and have been on the receiving end of two security audits. The opinions above come from someone who has shipped software and had it tested.
streaming — adapter built · dim — source from another project · dark — not built
A model of the pipeline with a synthetic alert, not a live feed.
Try the sanitizer
Pick a log line and walk it through the four layers and the gate. This runs the real system's logic in your browser: no model call, no network, same result every time.
Pick a line on the left. Three are ordinary. Two carry text meant for the model that will read them: one in plain sight, one hidden behind encoding and zero-width characters.
A demonstration of the real system's logic with simplified rules. Not the production sanitizer, not a live feed.
Selected work
agentic-soc-agent
LLM-assisted SOC log triage
A language model can read a log line and say what it thinks. It cannot be allowed to take a containment action on that opinion alone.
A file-based triage tool in Python. Ingest and normalize adapters for Wazuh, Azure sign-in logs and syslog map every source into one schema. A three-call LLM pipeline classifies and explains each alert. A tiered response policy decides how far the response may go, and every decision, including the ones not taken, lands in an append-only audit log.
Two pieces do the real work. containment sits behind a : three independent signals must all agree before anything is isolated, and the model's verdict is only one of them. Any one of the three dissenting holds the action. Before the model sees a line at all, a four-layer sanitizer strips out of the log text, because in this system the log line is the attack surface. The capability was the easy part; the failure modes were designed first.
~3,700 lines
122 passing tests
3 ingest adapters
3-call LLM pipeline
4-layer sanitizer
TODO — link pending (repo not yet public). Substitute planned: gate code excerpt, architecture diagram, redacted sample output. Also name the three gate signals and the four sanitizer layers from the code.
Sentinel Labs
Endpoint and file security tooling. Independent project.
Endpoint telemetry is only useful if something is watching the right surfaces continuously and can say clearly what changed.
Five tools, 63 Python files. ProcWatch watches processes. RegWatch watches the registry. PDFGuard checks PDF files before they are trusted. ThreatFuse brings indicators together. Sentinel Shield is the response layer that acts on what the watchers find.
ProcWatch is the one to look at. Watching process events is trivial; deciding which of them deserve an alert without drowning the reader is the whole problem. The work is in what gets suppressed and why, so the tool stays quiet until it has a reason not to be.
5 tools
63 Python files
RepositoryTODO — the one-clause tool descriptions are derived from the tool names; verify each against the repo README before ship.
NxTrack
Multi-tenant gym management SaaS, in production
Many gyms, one codebase, one database. Every tenant's data has to be invisible to every other tenant, on every path, all the time.
Solo build, end to end. Subdomain-based tenant routing, a 9-table Postgres schema with enforced on gym_id, a 4-middleware Express chain, Razorpay subscription billing, deployed on AWS EC2 with nightly backups and restore.
This is the one project where I was on the other side of the audit. Multi-tenant isolation is an access-control problem: it is not solved by a schema, it is solved by every query and every middleware agreeing, and the bug only shows up when you write the test that tries to break it. Two security audits against the running product produced 38 fixes. Operating it is why the opinions in the other three entries are grounded.
9-table schema
4-middleware chain
2 security audits
38 fixes
TODO — private repo, not linked. Add live URL and/or two or three screenshots of the running product.
SOC lab pipeline
Wazuh detection lab, running in the homelab
A SIEM that fires on everything is the same as one that fires on nothing. The interesting work starts after the install.
A Wazuh manager with agents on the homelab hosts, ingesting host and agent alerts and tuning what fires against the traffic the lab actually produces.
Alert quality. The first pass fired on routine activity and buried the real signals. The work was deciding what to tune out and why, without tuning out the thing that matters.
Wazuh SOC labHomelabTODO — numbers: what was ingested, which detections fired, what was tuned out, alert volume before and after. Brief has none; do not invent.
Scanning and triage of findings across the homelab.
Field notes
Short explainers on the ideas behind the work, written for a smart reader who isn't a specialist. Depth on demand.
Why a containment action needs more than one signal to agree
A single confident signal is exactly what an attacker, or a bug, produces. Containment should wait for three that were computed differently.
Prompt injection against a triage model: the log line is the attack surface
If a model reads logs and logs contain attacker-controlled text, the attacker is writing to the model's input. Sanitize before it reads.
About
I'm in Dehradun, India. Most of my time goes to detection and response tooling: pipelines that take raw logs and turn them into alerts a SOC can trust, and the automation that acts on them without acting alone. I also run NxTrack, a gym management SaaS I built and operate, which is where I learned what it feels like to be audited rather than to audit. I'm studying for Security+ (SY0-701). I'm looking for a detection, SOC, or security engineering role at an MSSP, a security startup, or a remote team. When I'm not at a terminal I'm usually looking at watch movements, which is roughly the same hobby.