{"slug": "deterministic-agent-safety", "title": "Deterministic Agent Safety", "summary": "A new approach to agent safety, called deterministic agent safety, separates the LLM's reasoning from its actions by placing the model in a sandbox with no credentials or network access, and exposing only predefined actions through attached services. This ensures that even if the model makes mistakes, it cannot access unauthorized resources or invent new capabilities, with safety enforced by code rather than prompts.", "body_md": "An agent needs only a few parts:\n\nThat is nearly the whole system. The safety comes from keeping the parts separate.\n\nThe 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.\n\nAn 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.\n\nEach service has actions. These are the verbs the agent can use: `search_email`\n\n, `create_event`\n\n, `book_court`\n\n. 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.\n\nThe service runtime, outside the agent, controls the credentials. They never enter the sandbox. So an agent that can call `search_email`\n\ndoes not thereby get a Gmail cookie or arbitrary access to the network. It gets exactly one verb.\n\nEach 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.\n\nSuppose 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.\n\nThe 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.\n\nTrying 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.\n\nThat is deterministic agent safety: let the model decide what to ask for, and let ordinary code decide what is possible.\n\n## Resources\n\n- Ziyuan Zhu,\n[“A Technology for Free Will”](/a-technology-for-free-will)(2026) - The broader argument for a local agent built around the user. - Marc Brooker,\n[“Agent Safety is a Box”](https://brooker.co.za/blog/2026/01/12/agent-box.html)(2026) - On putting deterministic control outside the agent.", "url": "https://wpnews.pro/news/deterministic-agent-safety", "canonical_source": "https://ziyzhu.com/deterministic-agent-safety", "published_at": "2026-06-18 00:00:00+00:00", "updated_at": "2026-07-12 23:05:55.169197+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "large-language-models"], "entities": ["Gmail", "Marc Brooker", "Ziyuan Zhu"], "alternates": {"html": "https://wpnews.pro/news/deterministic-agent-safety", "markdown": "https://wpnews.pro/news/deterministic-agent-safety.md", "text": "https://wpnews.pro/news/deterministic-agent-safety.txt", "jsonld": "https://wpnews.pro/news/deterministic-agent-safety.jsonld"}}