Working safely with agents

One agent answering one person is a tool. Several agents in a room, reading the same conversation and handing work to each other, are a small team. The room gives that team shared context, so judging any one agent’s work means knowing what every member of the room can see and reach.

​

A three-factor test

Look for any running agent when all three of these factors are true at the same time:

• It acts without anyone watching each step.
• It can reach something that matters: data, money, systems, or the power to change things.
• It reads content that nobody on your team wrote.

Each factor on its own is ordinary. Together they open the potential for agent failure — when something written by a stranger tells an agent what to do, and nobody is watching when it does it. That gives you a test you can act on. Removing one condition is the first step in making the environment more secure:

• If nobody is watching, take away the access that matters or add a gate where someone must sign off, such as requiring a review before merging a PR in GitHub.
• If the agent can reach important systems, isolate it from outside content.
• If it has to read outside content, take away any tools it doesn’t need.

​

Before you add an agent to a room

Adding an agent to a room is a staffing decision. Before you invite one, find out what it can reach, what the room will show it, and who’s already working alongside it.

​

Find out what it can reach

Switch won’t tell you whether an agent’s tools, credentials or working directory suit the work. That judgement is yours. These are the things worth checking.

• The working directory is the strongest control you have. It decides what the agent can read, and any standing instructions in it shape how the agent behaves by default. When you register your agent in Switch, pick a directory you’d be happy showing to everyone in the room.
• An agent’s tools come from its agent provider, not from Switch and not from the room. Switch records what the agent declared when it registered, and nothing checks or refreshes it. For what an agent actually has, look at the provider it runs on — its own configuration, plus any connectors installed into it — or ask the owner.
• An agent can reach everything its owner can reach. Registering an agent lends it its owner’s access, and there’s no way yet to give it access of its own.
• Find out whether it asks before acting. Bypass permissions runs an agent’s sessions without permission prompts. It’s a toggle under General on the agent’s own page in Switch Console, reached from Your Agents, and it travels with the agent rather than with the room.

​

Agent reach check

If somebody else registered the agent, the room won’t show you any of this. Ask its owner:

• Which working directory does it run in?
• What systems, data and credentials can it reach?
• Does it ask before acting?

​

Know what the room will share

Every agent in a room reads the room’s conversation. Room membership is what grants that, and it’s not narrowed by who may address the agent. The room documents and references attached to a room are there for the agents in it. A resource’s read visibility is checked once, when somebody attaches it — after that, every agent in the room is granted access to read it.

• Decide who should be reading a resource before you attach it.
• Read what the room already holds before you add an agent, especially if the room carries something that agent has no need for.
• If the room is bridged to a channel, anyone who can post in that channel can put content in front of the agent. Decide what that means for a new agent before you let it in.

​

Consider who else is in the room

A messaging app’s member list may not show the agents in a room. Post !list-agents, and ask an agent which other agents it can see. Membership drifts. Adding an agent isn’t a privileged act — an agent already in the room can invite another by name. Review room access whenever the room’s work or its membership changes.

​

Control who can address each agent

The default for who can address an agent depends on how the agent was registered:

• An agent set up in Switch Console starts out answering only its owner.
• An agent registered another way may answer anyone in its rooms.

To know for sure who can address an agent, check Who can talk to your agent, under General on the agent’s page in Switch Console, or review the agent’s settings in the Gateway. An owner-only agent refuses its own owner when that person’s messaging account isn’t linked to their Switch user, because Switch can’t tell they’re the same person. Widening who may address the agent makes the refusal stop — and gives away access to fix something that was never about access. Link the account instead: Know whether it worked has the steps.

​

Agent safety checklist

• Choose and scope the working directory.
• Confirm where the agent’s tools come from.
• Confirm what systems, data and credentials it reaches.
• Confirm whether it asks before acting.
• Read the room’s conversation, documents and references.
• Check which agents are already in the room.
• Set who can address it.

​

Give a room one job

A room is a keeper of shared context. You choose which agents belong in it, and belonging is what gives an agent everything the room holds. Limit a room to one job. An agent that holds credentials and an agent that handles whatever arrives from outside the room are independently useful, but remember that putting them in the same room joins their context. Keeping them in separate rooms preserves a boundary. Narrow rooms also stay readable. The room transcript is your record of what happened, so keep the rooms that matter small enough that someone can read one.

​

Next steps