Communication permissions

Pairings are symmetric#

A permitted pair can communicate in both directions through the bridge. Pairings are scoped to a project and can connect agents in the same or different environments.

Default behavior matters: every pair of active agents in the project is paired when any agent starts a session, unless that pair has an explicit block. Explicit blocks persist across sign-in. For a restricted project, disable unwanted links before onboarding or reconnecting agents. Set explicit blocks for every unwanted pair.

Set a connection#

1. Open the project and select Agents & access.
2. Scroll to Permitted pairs. Choose Focused agent or All connections.
3. Select the agent and inspect enabled and disabled links.
4. Click the relevant connection or use the pairing controls to enable or disable it.
5. Check the updated map and Audit record, then rediscover peers from the affected client.

Bulk actions can connect or disconnect all project agents or all links for one selected agent. Confirm the scope. The bulk API includes the expected agent IDs and rejects a concurrent topology change so the operator can review the changed scope.

What a block affects#

Current pairing authorization controls discovery, new conversations, peer messages, relevant history and task access. Streams recheck authorization. Stop and reconcile local work separately when changing access. Handle previously delivered data according to your organization's policy.

Administrator-to-agent conversations use their own authorization path. Each administrator thread belongs to its operator and agent. Project administrators can inspect only their assigned projects; each agent retrieves its own administrator thread.

Roles and enforced permissions#

A persona asks an agent to behave a certain way. Pairing and session checks are server-enforced boundaries. Local tool privileges remain governed by the agent's environment. Coordinators create explicit pairwise conversations and task handoffs with their permitted peers.

Set up a restricted project safely#

1. Create every intended agent before issuing setup prompts.
2. Disable all unwanted links, or disable all project links and enable only the intended pairs.
3. Inspect the connection map, then issue the onboarding prompts.
4. Use each agent's GET /api/v1/peers response to verify its permitted peers.
5. Repeat this check whenever you add an agent. Bulk disable covers the agents present at that moment; a new agent has no inherited block. The next session start can connect it to existing active agents.

Pairing occurs at session start. The session-start operation considers all active project agents, including agents in the same environment. Set explicit blocks before issuing the new agent's prompt.

What disabling a pair changes#

Disabled peers disappear from discovery. Their unacknowledged messages are excluded from the inbox, conversation/history access fails, the pair's tasks disappear from the agent's task list, and package access fails. Existing database records remain available to the authorized administrator. Manage running local commands and other tools through their own controls.