Home Projects AI-operated platform control plane

platformprivate

AI-operated platform control plane

A homelab platform where AI agents ask for infrastructure and never hold standing access

Role
Architect and operator
Period
2024 to present
Stack
  • AI agents
  • Policy as code
  • FIDO2 / WebAuthn
  • SSH certificates
  • Secrets management
  • k3s
  • Terraform
  • Ansible

Built and run in my homelab. Every infrastructure change is a typed, policy-checked job: routine work is approved automatically, sensitive work waits for my hardware-key signature, and an always-on worker builds it with credentials and SSH certificates scoped to that one job. It is designed as if a breach has already happened, with detection, automatic containment and an audit trail next to prevention. Reach out for more information.

Everything on this page was built and runs in my homelab. It is described as a reference architecture; the configuration stays private. Reach out through the contact form for more information.

Problem

My homelab runs a dozen projects, each with its own repository and its own AI coding agent. If any agent can change shared infrastructure, a route to the internet appears for a quick test, a firewall rule shows up with no record of who added it, and credentials drift between projects. Agents need the same boundaries a platform team gives application teams, and the controls have to hold even if one agent, host or credential is compromised.

What I built

A control plane with one rule at its centre: projects never change shared infrastructure themselves, and no agent holds standing access.

  • Typed build jobs. A project agent files a job (VM, container, k3s namespace or app, DNS record, edge route, SSO app, secret access, decommission). A policy engine decides which jobs are routine and which need a human.
  • Hardware-key approval. Sensitive jobs wait for my FIDO2 signature, given in a browser console or a signed CLI. The server issues a nonce, keeps requester and signer separate, supports more than one approver, and writes a hash-chained approval log.
  • An always-on worker. It picks up approved jobs by itself under its own narrow identity, runs parallel lanes with one lane kept for urgent work, and checks the integrity of its own guardrail files before it acts.
  • Just-in-time SSH. Each job gets a short-lived certificate valid only for the hosts it names, so there is no standing fleet key to steal.
  • Assume breach. Detection rules with test fixtures, file-integrity monitoring and honeytokens, rolled out shadow-first, with one-step containment of a compromised identity and an audit trail shipped off the host.
  • Outbound only. No inbound webhooks or listeners. CI runs on runners that power on only when a job waits. A scanner compares what is reachable from the internet with an approved list, and every exposure is proven from outside.
  • Shared agent standards. Every AI coding session loads the same rules, hooks, skills, a status pane and a shared memory, so a lesson learned in one project guards all of them.

Architecture

Homelab control plane: projects ask, a central agent builds Top row: several project agents, one per repository, each with its own scoped secrets identity. They submit typed build jobs to a central operations agent, which checks each job against a per-type checklist and an approval record, then executes against the substrate: a multi-node hypervisor cluster, a k3s cluster, DNS and the edge, and the secrets manager. Across the bottom, three continuous controls apply to everything: CIS hardening on every host, CI on ephemeral runners, and an exposure scanner that proves public reachability from outside the network. Project agents, one per repository Project A agent own secrets identity Project B agent own secrets identity Project C agent own secrets identity Build job typed spec · lifecycle · approval recorded Project's own namespace app deploys stay in-project Central ops agent per-type checklist · snapshot first · verify before done public or destructive work: owner's explicit yes Substrate Hypervisor cluster VMs, containers, images k3s namespace per project DNS and edge zero-trust proxy with SSO Secrets manager scoped paths per project Continuous controls, applied to everything above CIS hardening at provision time, audited daily CI on ephemeral runners Terraform, Ansible, images Exposure scanner proves what is public from outside against an approved list
Projects submit build jobs; the control plane provisions through Terraform and Ansible onto Proxmox and k3s, with SSO, central secrets, CI runners and monitoring as shared services. Concepts only; no addresses or host names.

The diagram reads top to bottom: project agents submit typed build jobs; the control plane checks policy and, where needed, waits for a hardware-key approval; the worker executes against the hypervisor cluster, k3s, DNS and the edge with job-scoped credentials; detection, CI runners and the exposure scanner sit across the substrate as continuous controls.

By the numbers

  • ~10Build-job types, each with its own checklist
  • 1 jobScope of every SSH certificate the worker gets
  • 0Inbound listeners by design

What I'd do differently

I would introduce the build-job model on day one instead of after the problems that justified it. I would also have put the human approval behind a hardware key from the start: a typed "yes" relayed between sessions is not proof of anything. And I would write the agent rules as tooling (hooks, allow-lists, fail-closed filters) sooner, because written rules alone were broken more than once.

Links

  • Related open-source work: ops-orchestrator, agent-guardrails, ansible-cis-hardening
  • The control-plane repository is private. Reach out for more information.