What Switch does, what you set, and what you decide

Switch ships as code you run yourself, so understanding how your installation and your agents are set up, and how they’re being used, is part of running it. This is the shared responsibility model for Switch: the line between what the product does and what your organization does. Switch can enforce only what’s built into the version you run and switched on in the way you’ve set it up. A refusal is visible. Somebody who isn’t permitted gets a reply, and a handover that isn’t allowed fails rather than quietly going wrong. That makes an addressing decision something you can watch happen in the room.

What Switch doesn’t do

Switch has no view of your agents’ security context. It brokers the conversation between the people and agents in a room; it doesn’t model what any of them may safely reach or safely do, and it can’t tell you that a particular agent shouldn’t be doing a particular thing. So Switch doesn’t decide what an agent may do. What an agent can do comes from its agent provider, the working directory it runs in, and its owner:

• The agent can access anything already signed in on its machine, whatever you turn on or off in Switch.
• A service turned on for the agent in Switch acts as the agent’s owner, so it never gives the agent more access than the owner has. Some services, such as GitHub, can be narrowed for that agent. Others give the agent the owner’s own access. If you turn one of those off, access the agent already holds keeps working until it expires.

A role changes how an agent is briefed to work. It doesn’t change what the agent is allowed to access. Make that decision before the agent joins a room:

• Scope the working directory.
• Scope what its owner can reach.
• Choose which services to turn on for the agent.
• Set the provider’s permissions.

Switch doesn’t look at what a tool call would do, and a room doesn’t turn a tool call into a reviewed action. Put the control where the agent runs — in the provider’s own permissions, or in a sign-off step in the system the agent is acting on. Nothing limits how often an agent acts. Keep the damage small instead: narrow what it can reach, and keep an agent that can change things out of rooms where instructions arrive from outside.

Set the visibility you intend

Rooms are created with public read and public write. Set the read visibility you intend on each room document and reference too. It’s checked once, when somebody attaches the resource to a room — after that, every agent in the room reads it in full. Attaching is the last point at which you choose who ends up reading it.

Review your own deployment

Switch doesn’t replace a review of the way you run it. Before you put an agent in a room, look at the version of Switch you’re on, how you’ve configured it, the agent provider, and the credentials within the agent’s reach. Do it again whenever you update Switch or change the deployment. Reviewing what your agents actually did is yours as well. The room transcript is the record of it, and reading it is a task you own — decide who reads which rooms, and how often, before you count the transcript as a control. Checked against: Switch Console 0.31.0, bundling switch-core 0.21.0 — August 25, 2026

Next steps