Dust.tt Permissions and Spaces: What Agents Can See

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.

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.

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.

Sources

• Dust documentation, Access Controls and Permissions
• Dust documentation, Spaces management
• Dust documentation, Skills
• Dust documentation, What data do the agents have access to?
• Dust documentation, Managing Agents
• Dust documentation, Admin quickstart

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.