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 (5)
"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.