Deterministic Agent Safety

· 2 min read

An agent needs only a few parts:

Agent
LLM thinks
Sandbox runtime runs code
attach
Attachable service outside agent
Service skills teach the model
Service actions fixed verbs
Credentials controlled here
Credentials never enter the agent.

That is nearly the whole system. The safety comes from keeping the parts separate.

The LLM thinks. The sandbox runtime gives it a place to read files, write code, and combine steps. But the sandbox has no ambient credentials and no open network. If the model gets confused, the confusion stays in the box.

An agent in a box is safe but not very useful. It needs to reach the outside world. That is what services are for. A service might be Gmail, a calendar, or a court-booking site. The user attaches one to a task in the same way they attach a file. Until then, it does not exist from the agent’s point of view.

Each service has actions. These are the verbs the agent can use: search_email, create_event, book_court. An action is fixed code with structured inputs. The model can request one, but it cannot invent a new one. The runtime checks that the service is attached, the action exists, and the inputs are valid. It can also ask the user before actions that send, spend, delete, or publish.

The service runtime, outside the agent, controls the credentials. They never enter the sandbox. So an agent that can call search_email does not thereby get a Gmail cookie or arbitrary access to the network. It gets exactly one verb.

Each service also has skills. A skill is just text that teaches the model how to use the service: which actions exist, what their fields mean, and how to combine them. This distinction matters. Skills change what the model knows. Actions change what the system can do. A skill has no authority of its own.

Suppose you ask the agent to book a tennis court. You attach the courts service. Its skill tells the model to search before booking. Its actions let the model search times and request a booking. The service holds the login. If booking requires approval, trusted code shows the court, time, and price from the proposed action. The action that runs is the action you approved.

The model can still be wrong. No architecture can fix that completely. But its mistakes now have a clear boundary. It cannot read cookies, call an unattached service, or turn instructions in a skill into new authority.

Trying to make the model itself enforce this boundary is a mistake. A prompt is advice. A sandbox and a short list of actions are facts.

That is deterministic agent safety: let the model decide what to ask for, and let ordinary code decide what is possible.


Resources

  1. Ziyuan Zhu, “A Technology for Free Will” (2026) - The broader argument for a local agent built around the user.
  2. Marc Brooker, “Agent Safety is a Box” (2026) - On putting deterministic control outside the agent.