An always-on agent needs a cell, not a laptop

It is Friday, late afternoon. You hand an agent a job that will take most of the weekend: match every supplier invoice from the last quarter against the orders, flag the mismatches and draft a polite email for each one. It starts in a terminal on your laptop, signed in as you. At six you close the lid and go home.
One of two things happens next. Either the work stops, because the session it lived in has gone to sleep in your bag. Or it carries on somewhere you did not quite decide, still holding your login, your mailbox and every network route your laptop has. Neither is what you meant by “do this over the weekend”.
The real cause: the agent lives in a session, and a session is the wrong unit
Chat taught us to treat SI as something that happens inside a session: you open a window, ask, read, close. An agent that works for hours breaks that model. Its job outlives the window, so the window cannot be where its work, its files and its rights are kept.
NVIDIA said the same thing plainly when it published its Secure Agent Workspace reference design in October, as part of a wider reference architecture for agent security. The document describes companies moving from chat to agents that run always-on, for hours, on behalf of an employee. Its answer is that the user’s device becomes only a presentation layer, and the agent works in a managed remote environment that persists independently of any session. Its own shorthand is “the workspace ≠ the session”.
It is useful to see a large hardware vendor arrive at the shape we built KyberCell around. It is not proof that our design works, and nothing below claims that Kyber runs on NVIDIA’s stack.
Where an agent on a laptop goes wrong
The design names five threats. Each one is worse when the agent shares a session with a person.
Writes nobody meant. An agent with your login can change or delete anything you can, by accident or by misreading the task. Nothing between it and your files asks whether this write was part of the job.
Data walking out. Your laptop can reach the whole internet, so the agent can too. A summary posted to the wrong address, an attachment uploaded “for processing”: outbound traffic and writes are the two ways data leaves.
Instructions hidden in the work. One of those supplier invoices can carry text written for the agent rather than for you. The design notes that injection can be multimodal, and that some attacks only appear once several inputs are combined. An agent reading for hours meets a lot of inputs.
The agent as the attacker. A compromised agent sits inside your network with your rights. It can scan, move sideways to other machines, or hammer a service through the connectors you gave it.
The guest taken over. If the machine the agent runs on is compromised at the root, any control running on that same machine can be switched off by whoever now owns it.
The last point is the one most setups miss. The reference architecture puts a supervisor outside the host for exactly this reason: Sentry, running on a BlueField-4 data processing unit, watches the agent from outside the machine and, according to NVIDIA, can isolate it within milliseconds. Whatever the hardware, the principle holds. The thing that watches an agent must not live where the agent can reach it.
What KyberAgent does instead
KyberAgent is pre-launch, and none of this is for sale. This is the design.
The cell is the workspace, the device is the window. An agent runs in its own KyberCell, on a home node or on KyberFusion, not in the session on your laptop. Closing the lid closes a view, not the work. When you open it again, you reconnect to the same cell. Memory that survives the session covers what the assistant keeps across those gaps and what the cell is built to forget.
Fixed at creation. The files and programs a cell can use are set when it is created. The invoice job sees the invoice folder and the order export, not your home directory. KyberCell explained goes through the mechanism.
Network closed by default. A cell reaches nothing until a rule opens a specific host for a specific program. The mail step can reach the mail server. The reading step can reach nothing at all.
Secrets outside the agent. Credentials are injected only at the endpoint they are authorised for, on the way out of the cell. The agent never holds your raw password, so it cannot leak one.
Sensitive writes go up to a person. Sending forty emails to suppliers is a step that stops and asks. The question goes to KyberBot, which reaches you on whatever device you have with you, as described in how an assistant hands work to a swarm.
The record is kept by the cell, not the agent. Every model call, tool call, file and connection is written down by the cell, so a compromised agent cannot edit its own trajectory. Underneath, KyberLinux holds each cell in place (how KyberLinux keeps a swarm in its cells), and the home node that hosts cells is described in the home node.
What we do not have is a supervisor on separate silicon. Kyber’s honest version of “outside the host” today is a record the agent cannot write to and a system underneath it that is immutable. That is weaker than a dedicated processor watching from the outside, and we would rather say so.
A test you can run today
Pick an agent you already use for anything longer than a chat reply. Start a task that takes at least half an hour, then close the laptop lid for twenty minutes. When you come back, answer five questions, one per threat:
- Did the work stop, continue, or continue somewhere you cannot name?
- Whose login did it use, and could that login delete files it was never asked to touch?
- Which hosts could it reach while you were away?
- If one input had carried hidden instructions, what would have stopped it?
- If the machine it ran on had been compromised, what would still be watching?
Any answer that starts with “I am not sure” marks where your agent needs a cell. More about KyberAgent is on the homepage.
- always-on agents
- KyberCell
- isolation
- Secure Agent Workspace
- supervision