---
title: "03. Permissions & connections | Kylon partner learning path"
description: "Understand who can see the work, call an agent and use a connected account. Each has a separate access boundary."
url: "https://kylon.io/partner/learn/permissions"
language: "en"
---

[STEP 03 OF 07](https://kylon.io/partner/learn/what-kylon-is)

# Permissions & connections

Understand who can see the work, call an agent and use a connected account. Each has a separate access boundary.

[A walkthrough of a Kylon workspace: what an agent reads, who can see a Room, what updates an App, and who can use a connected account.](https://static.purework.app/files/34e710c0958145da5bfae331a0e6f549/kylon-permissions-explained.mp4)

The four layers in this step, shown in the product.

## 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.

Thread context, Room search and agent access are three separate settings.

AGENT ACCESS LISTS

### Who can call each agent?

One workspace, three examples of who is allowed to call an agent.

**Atlas**General assistant · shared

Only members listed here can talk to Atlas

**Maya Chen**Team member

✓

**Leo Grant**Team member

✓

N

**Nora Blake**Team member

✓

3 members

**In a Room**“Summarize the team brief.”

**Clio**Personal assistant

Only members listed here can talk to Clio

**Maya Chen**Team member

✓

1 member

**Direct message**“Help me prepare for my meeting.”

**Fin**Finance specialist

Only members listed here can talk to Fin

**Maya Chen**Finance team

✓

**Leo Grant**Finance team

✓

2 members

**In #finance**“Review this supplier invoice.”

Illustrative Access lists, not fixed agent types. Room, App and Connection access are checked separately.

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.

Two points of view on the same Room list: what a person can find, and what an agent can search.

## 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.

Connections, then the options menu, then Manage access.

## 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.

Members, then the agent, then Access. Only the people listed there can talk to it.

### 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](https://external-agent-setup-guide.kylon.app/) 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.

Explore how a contract, review and payment stay in one Thread.[Open the full demo ↗](https://kylon-general-deck.kylon.app/#slide-15-step-2)

## 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

The two-person confirmation shown is this team’s example process. It is not a built-in payment gate, amount limit or payee restriction.

The Airwallex workflow shown is this team’s setup, not a built-in Kylon payment control. Confirm the connection path before promising it for a client. App publishing and email sending have platform approval flows; arbitrary payment API calls do not automatically gain those controls.