# Dust.tt Permissions and Spaces: What Agents Can See

*How-to — 2026-10-24 — by Mahmoud Zalt*

How Dust.tt roles and spaces decide what an agent can read and who can use it, and why publishing an agent is not the same as granting access.

**Short answer.** **In Dust, spaces decide everything: an agent built from a space inherits that space's access rights and no more, and only members of that space can use the agent.** Roles sit on top of that, with members using agents, builders creating them from spaces they belong to, and admins managing the workspace. Publishing an agent widens who can see it, not what it can read.

**About this guide.** This guide is based on publicly available information and Dust's own documentation, checked on 17 August 2026. Sistava is not affiliated with Dust. Interfaces and pricing change often, so confirm the current steps in their documentation before you rely on them.

The question that decides whether a company-wide AI tool is safe is a simple one: can it show someone a document they were never supposed to read? In Dust the answer is handled structurally, through spaces, rather than through per-agent settings you have to remember to get right.

That is a genuinely good design, and it is worth understanding properly rather than by trial and error. This guide explains the roles, the three kinds of space, how an agent inherits access, and the two places people misread the model.

Start from one sentence in Dust's documentation, because everything else follows from it: users create agents based on the data of the spaces they have access to. An agent is never a way to reach data you could not reach yourself.

## What are the roles in a Dust workspace?

Dust's access control documentation describes three. Members interact with agents, builders create agents from the data in spaces they can reach, and admins hold the highest level of access, managing workspace settings including connections, member roles, and subscriptions.

The split matters when you plan a rollout. Most people only ever need to be members, a handful of people build, and connections stay with admins by design, which is why a builder cannot fix a missing data source on their own.

| Role | What they can do | Typical use |
|---|---|---|
| Member | Use agents that draw on spaces they belong to | Most of the company |
| Builder | Create agents from data in their spaces, and create or edit skills | The few people who own agents for a team |
| Admin | Manage workspace settings, connections, member roles, subscriptions, and create spaces | IT, operations, or whoever owns the tooling |

## What are spaces in Dust?

Spaces are the containers that hold data and decide who can reach it. Dust's documentation describes three configurations, and the difference between them is the whole permission model in practice.

- **Company Data. **A default space present in every workspace. Dust describes it as not modifiable and states that it cannot be restricted.
- **Open spaces. **Accessible to all workspace members and managed by admins. Their docs frame these as the place for team or project data.
- **Restricted spaces. **Limited to selected members and managed by admins, intended for sensitive data where you need to control exactly who gets in.

Only workspace admins can create a space. Dust's documentation describes opening the spaces tab, choosing to add a new one, naming it, marking it open or restricted, adding members if it is restricted, then confirming.

Membership can be handled by hand or through your identity provider. Their docs describe a provisioned group access option that associates groups from your identity provider with a space, which is the sane route once you are past a couple of dozen people.

There is a ceiling to plan for as well. Dust's spaces documentation states that business plans support up to five spaces and enterprise supports up to a hundred, so a design that needs one space per team is worth checking against your plan before you commit to it.

## How does data get into a space?

Connected data is added by admins only. Dust's documentation describes selecting the space, opening its connected data area, choosing to add data from connections, picking what belongs there, and saving.

Other source types follow different rules. In open spaces, admins and builders can add data, while in restricted spaces their documentation says all members can add data from folders, websites, and apps. That distinction surprises people, so read it twice before you assume restricted means read-only.

**Connecting is not sharing.** Dust's admin quickstart states that connected data is not yet shared or usable by your workspace members until it has been added to a space. A source can be fully synced and still be invisible to everyone but the admin who set it up. If a colleague's agent cannot find something, this is the first thing to check.

## What can an agent actually see?

An agent inherits the access rights of the data it was built from, and nothing beyond that. Dust's documentation puts it directly: an agent created from data in a space the creator can reach inherits the access right to the data used, and no more.

The second half of the rule is about who can use the agent. Their spaces documentation states that the spaces used by an agent determine who can see and use it, so an agent built on a restricted space is only available to members of that space.

Skills follow the same logic. Dust's skills documentation says an agent can only use a skill if it has access to every space that skill requires, and that changes to a skill's space dependencies are reflected in connected agents immediately.

It is a coherent model, and it is also a model somebody has to hold in their head. At Sistava we kept the boundary at the account level instead: an AI Employee works with the tools you connected to it, and asks you before it does anything outside what you briefed it on.

Beyond spaces, there is a second boundary that has nothing to do with permissions: Dust simply does not index everything. Their documentation on agent data access states that agents only reach what admins chose to synchronize, then lists what falls outside that even within a synced source.

- **Comments and images. **Pictures and comments inside Google documents and Notion pages are outside what agents read, along with Drive image files and folder titles.
- **Slack extras. **Attachments, forwarded messages, bot-generated content, and links that do not point at an indexed document are excluded.
- **Repository code. **For GitHub, their documentation describes discussions and issues rather than the contents of your repositories.

## Does publishing an agent give people access to its data?

No, and this is the single most misread part of the model. Dust's documentation says a published agent is visible and usable by all members of the workspace as long as they have access to the data sources it uses, and an unpublished agent stays visible only to you and its other editors.

In practice this means two colleagues can call the same published agent and get different results, because the underlying access differs. That is the correct behaviour for a permission-aware system, but it looks like a bug to anyone who has not been told.

So tell them. A one-line note in the agent's description saying which space it draws on saves a surprising number of support messages, and it is the cheapest piece of governance you will ever write.

## How should you design your spaces?

Start with the smallest structure that expresses real boundaries, not your org chart. Company Data for what everyone may read, one restricted space for each genuine confidentiality boundary such as people data or unreleased financials, and nothing else until something forces it.

The reason to stay lean is the plan ceiling and the maintenance. Every extra space is another membership list somebody has to keep current, and a stale membership list is how permission models quietly stop meaning anything.

This layer of design work is what we chose to remove at Sistava. Rather than modelling spaces and mapping agents onto them, you hire an AI Employee, connect the accounts it should use, and tell it in plain English what it looks after. It asks you when it is unsure instead of silently reaching further than you intended.

If Dust is your platform, the permission model is one of the better reasons to have chosen it. Learn the space rule properly, keep the structure small, and write down which space each agent draws on. That is most of the governance work done.

## FAQ

### Can a Dust agent read data I do not have access to?

No. Dust's documentation states that an agent created from data in a space inherits the access rights of the data used and no more, and that users create agents based on the data of the spaces they have access to. The agent is bounded by the space, so it cannot be used to reach around your own permissions.

### What is the difference between an open and a restricted space?

An open space is accessible to all workspace members and managed by admins. A restricted space is limited to selected members and is intended for sensitive data where you need to control exactly who is in. Both are created by workspace admins. Company Data is a third type, present by default, which Dust says cannot be restricted.

### Who can create a space in Dust?

Only workspace administrators. Their documentation describes the flow as opening the spaces tab, adding a new space, naming it, choosing open or restricted, adding members when it is restricted, and confirming. Members can then be managed by hand or through provisioned groups from your identity provider.

### Does publishing an agent share its data with everyone?

No. Publishing makes the agent visible and usable across the workspace, but only for people who already have access to the data sources it uses. Two colleagues calling the same published agent can therefore get different answers, which is the permission model working as designed rather than a fault.

### How many spaces can we have?

Dust's spaces documentation states that business plans support up to five spaces and enterprise supports up to one hundred. Plan details change, so confirm the current figures in their documentation before designing a structure that depends on them.

### Why can my colleague not use the agent I built?

Most likely because the agent draws on a space they are not a member of. Dust states that the spaces used by an agent determine who can see and use it. The other common cause is data that has been connected but not yet added to any space, which their admin quickstart notes is not usable by workspace members until that step is done.

## Sources

- Dust documentation, [Access Controls and Permissions](https://docs.dust.tt/docs/access-controls-and-permissions)
- Dust documentation, [Spaces management](https://docs.dust.tt/docs/data)
- Dust documentation, [Skills](https://docs.dust.tt/docs/skills)
- Dust documentation, [What data do the agents have access to?](https://docs.dust.tt/docs/what-data-do-the-agents-have-access-to)
- Dust documentation, [Managing Agents](https://docs.dust.tt/docs/managing-assistants)
- Dust documentation, [Admin quickstart](https://docs.dust.tt/docs/quickstart-admin)

Permissions are the part nobody thanks you for and everybody notices when it fails. An hour spent drawing your spaces before you invite the company is the cheapest hour in the whole rollout.

**Tags:** dust-tt, ai-permissions, data-access-control, ai-governance, team-knowledge