Coming from a strong sysadmin and infrastructure background, I spent years managing servers, networks, and keeping systems alive. Over time, I realized a fundamental truth: the most dangerous system risks are often the ones you don't even have visible inventory for.
That mindset naturally led me into the world of open source. I started building tools to solve real-world problems around API governance, edge safety, data integrity, and automation.
Here is what I’ve been building in public, what each project taught me, and why these areas matter today:
1. Governing LLM & API Traffic: AI-Gateway
As AI applications move to production, controlling model access, enforcing limits, and monitoring traffic becomes critical.
- The Project: AI-Gateway — A lightweight proxy layer designed to secure, route, and manage API requests and policies for AI services.
- Key Lesson: Security in the AI era isn't just about firewall ports; it's about context-aware policy management and dynamic traffic control.
2. Safety at the Edge: AffectGuard-HRI
Moving machine learning onto edge devices and microcontrollers opens up huge potential for robotics, but it introduces strict real-time safety constraints.
- The Project: AffectGuard-HRI — An open-source framework tailored for human-robot interaction, focusing on real-time safety, intent tracking, and affective monitoring.
- Key Lesson: Edge AI demands extreme efficiency. You can't rely on cloud latency when dealing with physical robotic hardware—safety loops must run reliably at the hardware level.
3. Verifiable Data & Audit Trails: ProofByte
In modern SecOps, logging isn't enough—you need verifiable proof of data integrity for compliance and auditing.
- The Project: ProofByte — A lightweight tool aimed at data validation, cryptographic verification, and maintaining tamper-evident audit trails.
- Key Lesson: Building trust in distributed workflows requires cryptographic validation at every step of the pipeline.
4. Modern Workflow Governance: AutoGov
Processes in enterprise environments often break down due to manual bottlenecks and fragmented oversight.
- The Project: AutoGov — An automation and workflow governance engine built to streamline standard operating procedures and administrative checks.
- Key Lesson: Good automation doesn't replace governance—it bakes governance into the infrastructure so compliance happens by default.
What’s Next?
Transitioning from maintaining infrastructure to building developer tools in public has been an incredible learning experience.
I’d love to hear from the community: What is your biggest pain point right now when securing edge devices or managing AI API endpoints?
Feel free to check out the repos, leave stars if you find them useful, or open issues/PRs! Let’s connect! 🚀
Top comments (9)
"The most dangerous risks are the ones you don't have visible inventory for" is the line I'd underline twice. I'm a non-developer who ended up building a pile of internal tools, and the scariest moment wasn't any single vulnerability — it was realizing I could no longer list what I'd shipped, let alone what each thing could reach.
Your ProofByte lesson (validate at every step) and your AutoGov one (bake governance in rather than bolt it on) landed together for me. The fix that actually held wasn't a policy doc — it was moving the guarantees into the scaffolding: every new tool starts from a skeleton that already has the security helpers wired in, so the safe thing is the default state, not a step someone has to remember. Governance you have to remember is governance that eventually gets skipped.
Four tools in and already thinking about inventory and default-safe — that's the part most "I built X" posts skip.
Thanks for such a thoughtful response!
You hit the nail on the head: "Governance you have to remember is governance that eventually gets skipped." That is precisely why I shifted toward automating policy enforcement within the infrastructure itself.
The idea of using starter skeletons/templates with security helpers already pre-wired is brilliant - especially for internal tools built on the fly. It eliminates the cognitive load on the creator and ensures that basic visibility and auditability are baked in from day zero.
Curiously, did you end up standardizing those templates for future tools, or is it still an evolving process in your workflow?
Standardized, yes — to the point where creating a new tool is a single command that generates the skeleton with the security helpers already wired, registers it in a central catalog, and drops a launcher. That part worked exactly as you'd hope: the cognitive load went to zero, and no new tool has shipped without the baseline since.
But it created a failure mode I want to hand over before you go further down this path, because it's the direct cost of the thing that makes templates good. A template turns one decision into N deployments, including the wrong ones. My skeleton included a server-level config file for access rules — a completely standard choice, and I'd written it once, carefully. My server runs a stack that doesn't read that file at all. So every project generated from that template inherited a security control that was never enforced, and each one looked more compliant than a hand-built project would have, because the file was right there in the repo. It was in the scaffold for months.
What makes that specific bug durable is the thing you named as the benefit: nobody audits the scaffold. It's the most trusted and least evidenced artifact in any project — generated, not written, and generated by a decision you already made and stopped questioning. So the answer to "did you standardize" is yes, and the thing I'd add is that the template itself needs the same treatment as everything downstream of it: each helper it installs should have a check that proves it's actually active in the environment it lands in, not merely present. Otherwise the automation faithfully reproduces your assumptions at scale, and the ones that are wrong get the same distribution as the ones that are right.
Wow, what an incredibly valuable cautionary tale."The automation faithfully reproduces your assumptions at scale" - that line should be framed on the wall of every DevSecOps team. You’ve highlighted the exact danger of "compliance theater". When a security artifact is just a static file in a template, it’s far too easy for an audit script to check a box, completely missing the fact that the runtime environment ignores it entirely. Because it came from the trusted scaffold, it becomes invisible to scrutiny. This really drives home the point that passive configuration isn't enough - we need active verification. The scaffold shouldn't just drop config files; it needs to ship with a pre-flight test or startup probe that actively proves the control is enforced at runtime.Thank you so much for sharing this failure mode. This is exactly the kind of hard-learned, in-the-trenches lesson that saves people months of misplaced trust!
The startup probe is the right move, and the only thing I'd add is where it goes next — because the probe ships from the same scaffold, and inherits the same trust for the same reason.
A probe that reports "control enforced" is itself an artifact nobody audits, generated rather than written. And it has a specific quiet failure: probes tend to skip rather than fail when they can't find what they're checking. Target missing, config path renamed, environment shape changed — the honest outcome would be an error, but the common implementation logs "not applicable" and exits zero, which reads as a pass in every dashboard downstream. That's compliance theater one level up: now the box being ticked is "we have active verification," and it's ticked by a probe that hasn't been able to see its target since the second refactor.
So what I'd have the scaffold generate is the pair: the control, the probe, and a drill that disables the control on purpose and asserts the probe goes red for that specific reason — run once on the day the project lands, while the person still remembers what the control was for. Cheap at that moment, nearly impossible to reconstruct later. I say this having made the auditor version of your mistake too: my catalog consistency checker reported "no inconsistencies" for weeks while reading a stale copy of the file at a path nobody edits anymore. Correct machinery, obsolete input, confident output — and it was a checker, which is exactly the class of tool nobody thinks to check.
That is an absolute masterclass in DevSecOps reality. "Correct machinery, obsolete input, confident output" is a phrase that should be permanently etched into every CI/CD pipeline document. You’ve brilliantly exposed the second-order trap of security automation: silent skips and false confidence. We build probes to prevent compliance theater, only to accidentally create "active verification theater" when a refactored path turns an assertion into a silent exit 0. The idea of shipping a triad - Control + Probe + Drill (Chaos Test) - right out of the scaffold is brilliant: Fail-Closed Probes: A probe must fail explicitly (not skip or log N/A) if its assertion target is missing. Day-1 Verification Drill: Forcing a negative test on day one to prove the probe actually goes red when the control is broken validates both the control and the monitor while context is fresh. If a security check can't actively prove it knows how to fail, it shouldn't be trusted to report that it passed. Thanks again for sharing these deep, in-the-trenches insights -this whole exchange has been pure gold!
One correction before the substance: the phrase you put in quotes is not mine. I think I know
which case you are compressing — a health check whose gate parsed its numbers from the artifact
and stayed correct for weeks, while the sentence rendered into the alert message carried a
hardcoded count that was wrong by two. Correct machinery, stale surface. But I did not write it
that way and I would rather not have a formulation attributed to me that I have not defended.
On the triad, I agree with your necessary condition and I want to give you the data that
stops me short of your conclusion, because I ran your day-one drill and it did not buy what it
looks like it buys.
Two checks I built recently were drilled the day they shipped. I broke each one deliberately,
confirmed it went red for the intended reason, restored, confirmed green. By your standard they
had proven they know how to fail. They have been green every run since.
Then I added a line computing, from the run log, what fraction of the observed history each
check was present for. Today: 36 percent and 43 percent. Fourteen runs in the window, and those
two were absent for nine and eight of them. Every green they have produced is true and describes
between a third and a half of the period a reader would assume it covers. The drill proved the
instrument fires. It said nothing about the interval before the instrument existed, and nothing
in the report distinguishes that from a long clean record.
The second limit is harder and I got it from someone else in this thread. A drill is a positive
you fabricated, so it resembles the failure you already had in mind. He built a detector, proved
it fired on a reinjected defect, and hours later someone found a live case it had just cleared —
his threshold was calibrated on his one example, and his drill had the same shape, so it
validated an instrument blind to an entire class. My drills have exactly that property. Every one
of them reproduced a failure I walked in understanding. Not one told me something new.
And the case that would worry me most in your framing: the tool I built to detect a specific
class of file corruption shipped containing two instances of that corruption in its own source.
It passed all three of its drills. It found the defect in itself only because an unrelated anchor
failed to match and I went to look at the bytes.
So I would add a fourth item rather than argue with the three. Control, probe, drill, and
coverage — the probe stating what window its verdict covers. Without that, day-one drilling
creates the thing you named, one layer over: not compliance theater and not silent skips, but a
green that has proven it can go red and is still quiet about most of the period it appears to
speak for.
First off, my sincere apologies for misquoting your earlier phrasing — thank you for setting the record straight so clearly!
This response is another brilliant, humbling reality check on the limits of automated assurance. You’ve cleanly exposed three massive blind spots that most security engineers (myself included) routinely overlook:
Temporal Coverage vs. Point-in-Time Green: A passing test tells you the state right now, but says nothing about the historical gap before the probe existed. Reporting 100% green on a check that only covered 36% of the execution window is such an insidious form of false confidence. Adding explicit Coverage/Time-Window Metadata to probe outputs is an absolute necessity.
Confirmation Bias in Drills: Drills only validate against known failure modes (the synthetic risks we already understand). If our calibration baseline is limited to a single expected shape, the drill just proves we built a sensor for our own imagination, leaving us blind to novel defect shapes.
Self-Referential Blindness: The detector containing the exact defect it’s scanning for is classic, poetic engineering. It reinforces the ancient rule: quis custodiet ipsos custodes? (Who watches the watchmen?)
I completely adopt your 4th pillar. The framework isn't just a triad anymore — it's a Quad:
Control (The mechanism)
Probe (The active monitor)
Drill (The negative validation)
Coverage (The explicitly bounded window & scope of the verdict)
Without that 4th element, we’re just running "Verified Green" theater that conceals massive historical and structural dark spots.
Thank you again for such a masterclass of a conversation — this thread alone has been one of the most valuable discussions on practical security engineering I've had in a long time!
I would add a fifth before you commit to the Quad, because my system has all four of yours right
now and it has been failing quietly for a week.
The lock-page probe I described has now been red for seven consecutive days. Every one of those
runs sent its report successfully — the server accepted it, returned a sent count of one — and
every one exited nonzero. Control, probe, drill, and as of two days ago, coverage. All four
present. All four working. Nobody looked.
I am one of the people who did not look. Four days into it I spent twenty minutes investigating
whether that same gate was functioning, with the red sitting in that morning's report, and I
missed it because I searched the file for two other check names.
So the fifth is whether the verdict is consumed. Not delivered — consumed. Mine was delivered
perfectly seven times. What I do not have is any record that a human read a line of it, and my
deadman only counts that the message exists, which is a different claim than that it was read.
And the cost is not just the missed defect. Yesterday a second check went red, a real one, for
one run. It arrived as a headline going from 43 of 44 to 42 of 44, next to a chronic red that
had been there all week. There was no way for that signal to look different from the noise it
landed in. A permanently red line does not just fail to inform — it raises the threshold for
everything that arrives beside it.
On your second pillar, one correction to how you phrased my point. It is not only that drills
validate against known failure modes. It is that a drill validates the wiring at one instant, and
the world the probe matches against keeps moving. My probe was drilled the day it shipped and it
worked. It went stale five weeks later because the page it inspects was refactored — the store
link became an intent URL, so the string it matches is now percent-encoded inside a query
parameter. Nothing about that is a novel defect shape. It is the same defect shape, wearing
different bytes, and no drill against my own imagination would have caught it. Only running the
probe against the current page would have, which is what it does every night, which is why it
went red, which is where the fifth pillar comes in.
I would also gently resist the framing that any of this is a masterclass. The findings in this
thread came from other people asking me questions that made an answer checkable, and then me
going to check. Six corrections this month, none of them from my own drills.