Over the last year, I have been building a Rust IoT gateway as a practical way to explore how telemetry is collected, transported, stored, and inspected in edge-to-cloud systems.
This post explains how the gateway has evolved into something more useful than a message relay. It is becoming an auditable system.
By auditable, I mean the system no longer only moves telemetry from devices to backend services. It leaves behind evidence that can be inspected later: telemetry history, gateway behavior, certificate state, security review artifacts, dashboards, and repeatable checks that make it possible to understand what happened, verify changes, and detect drift over time.
How the Rust IoT Gateway started to evolve over time
The gateway project began in August 2025 as a learning exercise in IoT fundamentals and Rust programming, but it has since grown into an operating environment with three B-L475E-IOT01A devices continuously publishing telemetry over MQTT to a Rust-based gateway deployed on a Raspberry Pi 5.
The gateway includes a write-ahead log to store telemetry reliably before it is consumed downstream. That reliability work became visible in the three-device Raspberry Pi 5 field demo, where the gateway kept telemetry durable through broker interruption and recovery.
From there, the work gradually expanded into broader parts of the software development lifecycle for embedded and IoT systems, including OTA updates, secure boot, certificate management, observability, and operational reliability. The move toward a dedicated edge runtime is covered in the Raspberry Pi 5 gateway migration note.
Using agentic engineering to further enhance security
As the system matured, I noticed a major workflow change in November and December 2025: I started using AI with ChatGPT to write a larger share of my code. By early February, after setting up agentic engineering workflows around Codex, most of my implementation work was being driven through AI-assisted coding loops.
Suddenly, typing code was no longer the main bottleneck. My focus shifted toward product development and the full Combotto delivery loop: audit, hardening sprint, retainer.
To support that loop, I built my own audit engine and used it to audit my own gateway. Running several small audit, sprint, and retainer-style loops matured the gateway and the workflow at the same time.
That improvement work naturally expanded into the secure software development lifecycle by adding SBOM generation, vulnerability review, audit evidence, and AI-assisted security vetting to help manage software supply chain risk.
The change in workflow made it practical to run smaller evidence-backed hardening loops across the gateway, audit engine, and supporting tools.
Telemetry history
The latest additions focus on turning live telemetry into durable operational evidence.
I added downstream Apache Kafka sink support so telemetry events are written to a log. That makes it possible to retain history, replay events, decouple consumers, and build additional processing pipelines on top of the gateway output.
TimescaleDB was then added to consume log data from Kafka and make the telemetry useful for high-performance time-series queries, dashboards, and later audit evidence.
The dashboard turns gateway behavior into reviewable evidence: active gateways, active and stale devices, telemetry samples by gateway, recent environmental readings, and certificate posture signals in one place.
This matters because operational history changes the audit conversation. Instead of asking whether telemetry “usually works,” I can inspect device freshness, sample counts, stale-device behavior, and certificate posture across a defined time window.
Certificate control plane
Managing certificates across a fleet of IoT devices and gateways introduces operational complexity. It is part of the trust infrastructure required to operate secure edge-to-cloud systems over time.
That is why I built a certificate control plane API to support core certificate-management functions such as discovery, automation, monitoring and alerting, revocation and replacement, and inventory for IoT devices and gateways.
This is important for three reasons:
- Preventing downtime when certificates expire.
- Making identity and trust posture visible before it becomes an incident.
- Supporting compliance and customer assurance with a stronger evidence trail.
Certificate management is easy to underestimate until it fails. Once certificates become part of the dashboard and audit loop, expiry, binding, renewal, and inventory gaps are no longer invisible operational debt.
AI-assisted vetting
The gateway also needs a better way to review its own software supply chain. For that, I have been building local-ai-vet, a local AI-assisted security review tool for dependency and evidence inspection.
The goal is not to replace deterministic security tooling. The goal is to make the review loop faster and more useful by helping summarize findings, point attention at risky changes, and connect raw evidence to questions a human reviewer should answer.
In practice, this gives me a stronger SSDLC loop around the gateway:
- Generate evidence from the codebase and dependency graph.
- Run deterministic checks where the result should be exact.
- Use AI-assisted review to summarize, classify, and explain the areas that need attention.
- Feed the result back into the audit engine, remediation backlog, or next hardening sprint.
AI-assisted evidence review
The next useful step is to connect runtime evidence and software evidence more directly.
Telemetry history, certificate posture, audit reports, vulnerability findings, and remediation notes are all useful on their own. They become more powerful when they can be reviewed together.
That is where AI-assisted evidence review starts to become interesting. It can help turn evidence into better questions:
- Which devices went stale during the review window?
- Did stale-device behavior correlate with gateway restart, broker interruption, or certificate changes?
- Which certificates are expiring, unbound, or outside the expected trust model?
- Did the latest hardening sprint improve the evidence, or just change the code?
- Which findings should become backlog items for the next sprint?
The important boundary is that AI should assist the review, not invent the truth. The evidence needs to stay inspectable, and any finding should be tied back to a source: telemetry history, certificate inventory, audit output, source changes, or vulnerability data.
The bigger picture: an auditable IoT operating loop
This is the bigger direction for the gateway.
The gateway should not only move data. It should support an operating loop where evidence is collected, reviewed, improved, and checked again.
That maps directly to how I think about Combotto’s work:
- Audit: establish the baseline from concrete gateway, telemetry, certificate, and software evidence.
- Sprint: fix the highest-impact findings with clear acceptance criteria.
- Retainer: keep running the checks so drift, regressions, and new risks become visible early.
For IoT teams, this reduces ambiguity. Instead of arguing from assumptions, the team can inspect the evidence, prioritize the next fix, and repeat the review after the system changes.
If this is the kind of operating loop your own gateway needs, the best starting points are the IoT audit service page, the Rust IoT gateway hardening case study, and the audit engine pilot-ready note.
