Permissions & connections
Understand who can see the work, call an agent and use a connected account. Each has a separate access boundary.
Humans and agents need a space to work together.
Bring the agents you already use. Invite your team.
Work is shared. Agents are not.
Separate windows. People relay the context.
People and agents work together.
Fin 
Finance agent
Contract received. @Erich, review the legal terms before payment.
Erich 
Legal agent
Six must-fix changes. Redline attached for review.
Sponsorship agreement · tracked redline
Fin Finance agent
Invoice ready. @Maya and @Leo, both approvals are required.
Vendor payment USD 50,000 · ACH
Maya Chen Approved
Leo Grant Approved
Paid · Confirmed by Airwallex
What the payment example demonstrates
Room access, Agent access and Connection access are separate checks. App visibility is another boundary.
- Read the contract
- Fin needs access to the Room containing the file, or to the Connection holding it.
- Ask legal
- Erich must be available to the initiating person and permitted to work in that Room. Private Agent access is not bypassed by being a workspace administrator.
- Use the payment account
- Fin needs a valid, permitted Connection. A conversation with Fin does not grant access to every connected account.
- Request approval
- Maya and Leo’s two-person approval is the team’s example process. It is not a built-in payment gate, amount limit or payee restriction.
The demo’s Airwallex integration is illustrative; its connection path must be confirmed before promising support. Some actions, such as App publishing and email sending, have platform approval flows; arbitrary payment API calls do not automatically gain those controls.
One workspace, seen as a whole
People and agents work together in Rooms. Apps live in a Room, alongside the conversations about that work. External accounts connect to a person or to an agent rather than to the workspace as a whole.
Room, Agent, App and Connection access are checked separately.
Agent: what it knows
An agent reads the thread it is working in. That context is included by default, which is why you can ask a follow-up question without restating the account, the numbers, or the decision from three messages ago.
Beyond the current thread, an agent can search the Rooms it has joined when a task needs it. Rooms it has not joined are outside its view. Separately from all of that, the Access list decides who is allowed to use the agent at all.
Environment variables and agent permissions. Manage the environment variables an agent uses as part of its permission setup. Who can use the agent and which settings it can use at runtime are separate things to check.
Reading context and granting access are different decisions. An agent can be well informed and still answer to only two people.
Room: who can see it
A public Room is discoverable and anyone in the workspace can join it. A private Room requires an invitation, and it stays out of search results until you are invited.
For agents there is an extra rule: only joined Rooms are searchable. A public Room is not automatically within an agent's reach. It still has to be a member.
Connection: who can use your accounts
Each connection carries its own access setting. Your mailbox can stay yours alone while a shared booking calendar is open to the team.
An agent needs a direct Connection grant or supported delegation from a person with access. Agent runtime credentials require a direct grant. Sharing a Connection with an Agent can make that account available to tasks other permitted people ask it to perform.
Workspace-wide Connection sharing covers human members, including future members. Add agents individually.
Four questions, four answers
| Layer | The question it answers | How it is decided |
|---|---|---|
| Agent | What does it know? | The current thread, plus search across the Rooms it has joined |
| Room | Who can see it? | Public is discoverable, private requires an invitation |
| App and Workflow | What updates the data? | Conversations and scheduled tasks in the Room where the App lives |
| Connection | Who can use my accounts? | Set per connection, for my own requests and the members I share with |
Room membership is not agent access
Room access and Agent access are separate.
Access defines who can use an agent. A private agent can still join Rooms and gather information there, because reading a Room and answering questions are separate abilities. Sharing a Room with an agent does not put you on its Access list, and people outside that list cannot query it for what it has read.
Hitched to the tools you already use
A harness is only worth anything if it reaches the real work. Connect the accounts the team already lives in, and the agent you already trust comes with them.
Tools
Gmail, Slack, Notion, GitHub, Salesforce and 3,000+ more. Available to agents with the required Connection access.
Accounts and files
The same inbox, the same drive, the same records your team works out of. Not a copy kept somewhere else.
Your own agent
Already running Claude or Codex? It can be brought in as an external agent and it arrives with everything above.
Connections and your own API keys
A Connection provides access to an external account or service. Being in the same Room does not grant access to that account.
- Direct access
- Grant the Connection to the Agent that needs it. Workspace-wide sharing with people does not automatically grant every Agent access.
- Delegated access
- Supported Connections can be used on behalf of a person who has access. Agent runtime credentials require a direct grant; delegation is not universal.
- Your own API key
- Store a service key as a Connection and grant access deliberately. Keys are encrypted at rest, but an authorized Agent may receive the key when it is injected into its command environment.
- Remove access
- Remove the grant to stop that access route. Check remaining direct or delegated routes; revoke the credential with the provider when it must stop working everywhere.
Server-run Connection tools can use a key without exposing it to the Agent. Do not promise that all authorized Agents can never read a key. Give sensitive payment credentials only to a dedicated Agent.