--- title: "A reference list without Debian: choosing a base for SI" url: "https://kyberlinux.com/blog/a-reference-list-without-debian" description: "NVIDIA's reference architecture for agent security names Canonical, SUSE, Red Hat and Windows, not Debian. What that says about choosing a base for agents." --- # A reference list without Debian: choosing a base for SI October 29, 2026·4 min read·Editorial team Four identical rounded green units with blank metal tags hanging from their handles, and a bare single-board computer lying in front of them Your team has been running its agents on Debian for a year. It is stable, the people who maintain it are careful, and you can read every line of it. Then someone from security forwards the new [NVIDIA reference architecture for agent security](https://nvidianews.nvidia.com/news/openshell-reference-architecture), published on 21 October, and asks one question in the meeting: why are we not on the list? The list names Canonical, SUSE and Red Hat for Linux and Kubernetes, Windows through Microsoft Execution Containers, and the three big clouds. Debian is not there. We think that is a pity, because Debian is one of the best-maintained bases there is. It is also a useful lesson, because the reason it is missing has nothing to do with the quality of its code. ## The real cause: a reference list is a list of who signs A reference architecture is a promise that a specific combination has been put together, tested and will be answered for: this kernel, these drivers, this container runtime, on this hardware, with someone you can call when an update breaks it. The names on it are companies that validate, sell support and carry responsibility. Debian is a community project with no single company behind it that does all three. Open code is a necessary condition for a base you can trust. It is not a sufficient one. Code you can read is not the same thing as someone who has tested your combination and picks up the phone. This matters more for agents than for most workloads. An agent that runs for hours on your behalf has your access, reads untrusted text and acts on it. When something goes wrong, “the code was open” is the start of an investigation, not an answer. ## Where choosing a base goes wrong **Reading the list as a ranking.** A missing name means nobody signed for that combination, not that it is insecure. Moving off a well-run base just to match a list trades known behaviour for a logo. **Treating open code as support.** You can audit it, rebuild it and patch it yourself. All three are work, and someone has to own that work before the night it is needed. **Picking a vendor and stopping there.** A validated base covers the base. It says nothing about what your agents may read, where they may connect or who approves their writes. NVIDIA’s own [Secure Agent Workspace design](https://docs.nvidia.com/enterprise-reference-architectures/secure-agent-workspace-reference-design/latest/abstract.html) calls its phases “additive control outcomes, not deployment-status labels”: having the right system does not tick any of them. **Trusting controls inside the guest to protect the guest.** The same design is blunt about this: runtime controls only hold while the mechanism that enforces them is trusted, and protection against someone taking root or the kernel of the guest has to run outside the guest. **No owner for rebuild and revocation.** Nobody can say how fast a compromised machine is rebuilt from a known image, or how fast a leaked credential stops working. ## What to ask of a base instead Separate the four things a name on a list bundles together, and ask for each one on its own. 1. **Validation:** has someone tested this system on your hardware and drivers, and can you repeat that test yourself? 2. **Support:** is there a named person or company who answers when an update breaks the machine? 3. **Responsibility:** who answers for a failure in writing, and what happens when they stop? 4. **Readability:** can you read, rebuild and verify what runs, without asking permission? Then use the maturity model from the Secure Agent Workspace design as a checklist for the system underneath, because it describes what a system that keeps a swarm in cells has to do. **Phase 0, the foundation.** Known configuration, patches and vulnerability management, workload protection, managed images, telemetry a security team can read, rebuild and revocation. In KyberLinux this is the ground floor: an image that is [immutable, verified and boring](https://kyberlinux.com/blog/immutable-verified-boring), with [atomic updates](https://kyberlinux.com/blog/atomic-updates-for-machines-you-cannot-visit) you can roll back. **Phase I, the perimeter.** Each agent in a space belonging to one user, on an approved image; single sign-on and an access broker; a list of allowed destinations; a person reviewing writes; an audit at the edge. In the Kyber design, one person’s agents run in their own cells, and KyberBot asks you before anything sensitive. **Phase II, enforcement around the agent.** Process, file and network control inside the system, outbound traffic blocked by default, signed policies checked when a tool is called, credentials brokered so the agent never holds them, inference only through approved paths, and policies written, signed and distributed centrally and verified before they take effect. This is what [a KyberCell is meant to be](https://kyberlinux.com/blog/how-kyberlinux-keeps-a-swarm-in-cells): fixed at creation, network closed, secrets injected at the endpoint, every step logged. KyberAgent explains the cell from the agent’s side in [KyberCell explained](https://kyberagent.com/blog/kybercell-explained). Be honest about the gap, because we are. KyberLinux is not on that list either. It is pre-launch, it has not been validated by anyone, and nothing here can be installed today. Readability is the part we can promise by design. Validation, support and responsibility come from people, and in the Kyber family that is the job of KYBERTIS, which describes [what an SLA on an open-source stack can honestly mean](https://kybertis.com/blog/what-an-sla-on-open-source-means). More on the system is on [the homepage](https://kyberlinux.com/). ## A test you can run today Take the machine your agents run on now and write three columns: Phase 0, Phase I, Phase II. Under each, list the items above and mark every one with yes, no, or a name: the person or company that makes it true. Then answer the question that decides the base: it is three in the morning, a kernel update has just broken the GPU driver and the agents have stopped. Who do you call? If you can write down a name, you have a base. If you can only write down a URL to the source code, you have excellent code and an open position. - distributions - agents - KyberCell - support ## Keep reading - [Agent factories will leave IT for machines nobody runs](https://kyberlinux.com/blog/agent-factories-on-machines-nobody-runs) - [The Kyber I/O scheduler in Linux: what it does and when to use it](https://kyberlinux.com/blog/the-kyber-io-scheduler-in-linux)