What is Dust? Pricing, EU Residency, and Best Alternatives in 2026

Connections. The admin governance docs describe them as "fully managed integrations that automatically sync data from external platforms (like Slack, Notion, Google Drive) to Dust, with granular admin control over what specific content is accessible to the workspace". The Business plan highlight names Slack, Notion, GitHub and Drive plus roughly twenty more, with anything else reachable through MCP; Enterprise adds "Unlimited connectors & MCP servers".

Spaces. The unit of access control. Same page, verbatim: "Spaces are containers in Dust that let admins organize and control access to data, coming in two types: open spaces accessible to all workspace members and restricted spaces limited to designated users." And the consequence: "users can create agents based on the data of the spaces they have access to", and "users can interact with agents created with the data of the spaces users are a member of".

Agents and workflows. Custom agents built on a workspace's skills, knowledge and tools, with multi-agent workflows that run on schedules and triggers. Credits are the meter: the docs state that "Token credits are proportional to the amount of AI processing involved in generating a response" and that "More complex queries, longer contexts, and more capable models consume more token credits."

There is no phone or voice channel on any published Dust plan. That is not a criticism of the product, which is not sold as one; it is the boundary of the category, and it is the reason a company whose work arrives by telephone ends up buying two things.

Access in Dust is re-declared after ingestion rather than mirrored from the source system per user at query time. Content syncs into Dust, an admin places it in a space, and membership of that space governs who can build on it and who can talk to the agents built from it. Nothing in Dust's admin documentation describes consulting a source system's per-user access control list when a question is asked.

That absence has a method behind it, which is the only thing that makes it worth stating. We read the full Dust documentation sitemap (354 URLs on 2026-09-06) and grepped the URL list for secur|privac|region|resid|retent|train|gdpr|data|permission|space|plan|pricing|credit|seats|eu|legal|trust|sso|enterprise. No page describing source-permission mirroring, data residency or retention appears in it. Documentation sites can be incomplete, so this is a statement about what is published, not about what the software does internally.

The design detail worth carrying into a security review is on the workspace governance page, verbatim: "Permissions are granted to groups rather than directly to individual people. To grant a permission to one person, create a manual group, add that person to it, and grant the permission to the group." And then: "Permissions are additive. If a person belongs to several groups, they receive the combined permissions granted by those groups. A group grant adds access and does not remove access granted elsewhere."

Additive-only means there is no deny rule. A group added to solve one team's access problem widens every member's reach and nothing narrows it back. This is a structural property of the model rather than a defect, and it is the same class of problem every assistant in this category has: what the assistant surfaces is what somebody could already technically reach, not what they were meant to see.

On retention, Dust publishes an Enterprise highlight reading "SCIM, audit logs & custom data retention". No default retention period is published for the Business plan, and no retention page exists in the documentation sitemap under the pattern above. We therefore state the absence and no number.