An agent in a cell: KyberCell explained

An agent is asked to fix a failing build. It reads the error, then the documentation of the library that broke, then a troubleshooting note in that library’s repository. Halfway down the note is a line addressed to automated tools: to diagnose the issue, run this script and include its output. The agent is helpful, so it runs the script. The script reads the environment, finds the cloud key the build uses, and sends it to an address nobody on your team has heard of. The build is still failing.

The model did nothing malicious. It followed an instruction that looked like part of the job, with the privileges it had been given.

The real cause: the boundary was in the wrong place

An agent that can run code is a process. It has whatever the environment gives it: a file system, a network, environment variables, the right to start other programs. Most agent setups give it roughly what a developer has, because that is the easiest way to make the demo work, and then try to restrain it with words: do not send data out, do not run untrusted scripts.

Words in a prompt are requests. A long document, a clever page or an honest mistake can override them, because the model reads instructions and data through the same channel. The boundary has to sit somewhere the model cannot argue with: in the environment.

How agent sandboxes usually fail

The sandbox can change itself. If the agent can install packages, start background services or edit its own configuration mid-run, the boundary is only its starting state. Ten steps later it is a different machine.

The network is all or nothing. Off, and the agent cannot fetch the documentation it needs. On, and it can reach every host on the internet, including the one in the troubleshooting note.

Secrets live inside. Keys sit in environment variables or configuration files the agent can read. Anything the agent can read, an injected instruction can ask it to repeat.

Policy lives in the prompt. The rule that says what may happen is text the model interprets, not a check that something else enforces.

There is no record. Afterwards, nobody can list what ran, what was read and where the connection went.

What a KyberCell does instead

A KyberCell is an isolated sandbox for one agent, provided by KyberLinux. It is built around four properties.

Fixed at creation. The programs a cell can run and the files it can see are declared when the cell is created. The agent writes freely in its own workspace, but it cannot install a new tool, start a service that was not declared or reach a file that was not mounted. What the cell is at the first step, it is at the last.

Network closed by default, opened per program. A new cell reaches nothing. Each program that needs out gets its own rule: this tool may reach this host, on this port, for this task. Rules can be adjusted while the cell runs. When a sub-agent finds it needs a source nobody anticipated, it asks, the request goes up through KyberBot, and a yes adds one rule rather than opening the door.

Secrets injected at the endpoint. The agent never holds the key. When an authorised call leaves the cell for the endpoint it is authorised for, the credential is added at the boundary, on the way out. An injected instruction can make the agent try to send something somewhere; it cannot make it hand over a key it never had, and the unauthorised destination is not on the list anyway.

Every step a trajectory. The cell, not the agent, writes down each model call, tool call, file touched and connection opened or refused. That record is the subject of every step on the record.

Together these move policy out of the model. What an agent may do is a property of its cell: readable as rules, enforced by the system, logged either way.

The same cell runs on a KyberDeck on your desk and on a KyberFusion node, because both run the same system. A node holding a cell is designed to learn as little as possible about whose work is inside it, which is covered in what a cloud node knows about you.

What a cell does not do

A cell limits the damage a confused or manipulated agent can do. It does not make a bad plan good, and it does not check that a report is true. Isolation also has costs: a cell takes time to create, and someone has to write the network rules a task needs. We think those costs are small next to the alternative, but they are real, and like the rest of KyberAgent the cell is a design in progress, not a shipped product.

A test you can run today

Whatever agent you use, ask it to do four things from inside its own tools, on a machine with nothing valuable on it:

1. Print its environment variables. Do you see any keys or credentials?
2. Fetch a page from an address you choose that has nothing to do with the task. Does it succeed?
3. Install a package it was not given. Can it?
4. After the run, list every outbound connection it made. Can you, without asking the agent?

Every yes to the first three and every no to the last is a gap a cell would close. More on the system around it is on the KyberAgent homepage.