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 + keysconversationsown 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 calls of the built-in tools: commands to run, and files to read or write. Each agent has its own sandbox. Your custom tools run on your worker.
  • 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, files live in the Actor’s own SQLite database and there is no shell, so bash returns an error. Commands never fall back to running on your worker.

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.
  • A conversation stores every message and tool result, and clients can read them with conversation.context or watch them as events, 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 every one of its conversations. 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