Skip to main content
Sign In
Agent

Security Model

What reaches the sandbox, where secrets live, and who can connect to an agent.

CLIENTSYOUR BACKEND · TRUSTEDSANDBOX · UNTRUSTEDClientsAgent ActorSQLiteShell + filesModel providerauthenticatedagent loop + keyssessionown environmenttool callsno secretsmodel calls

The agent loop runs in an Actor on your backend, and the commands the model chooses run in a sandbox. Everything that needs a secret stays in your backend.

What reaches the sandbox

  • Only tool calls: commands to run, and files to read or write. Each agent has its own sandbox.
  • Not your worker’s environment. Commands run with the sandbox’s own environment.
  • File tools reject paths outside the working directory. Shell commands can reach anything inside the sandbox, so the sandbox itself is the boundary.
  • Without a sandbox, the agent has no file or shell tools. They never fall back to running on your worker.
  • An agentOS VM keeps its files after the agent is destroyed, so delete them with the rest of a user’s data.

Where secrets live

  • Model keys, sandbox provider keys, and the secrets your custom tools use stay on your worker. The model and the sandbox never see them.
  • User subscription logins stay in your credentials Actor. The agent never receives a refresh token.
  • The session stores every message and tool result, and connected clients receive them, so keep secrets out of tool results and error messages.
  • Traces never record prompt text, tool arguments, or tool results.

Who can connect

  • Anyone who can connect to an agent can prompt it and read its whole session. Add authentication and check that the caller may use the agent’s key. Keys aren’t secret.
  • Protect the credentials Actor the same way, because its actions return provider tokens.
  • Give a browser a short-lived token for one agent instead of your Rivet credentials. See Client SDK.
Edit this page