Configuring Dust Spaces and Role-Based Permissions: How Enterprise IT Prevents Cross-Department Data Leakage in AI Assistants

Enterprise IT administrators and security leaders face a critical dilemma when scaling conversational AI: employees gain immense productivity from natural language assistants connected to internal knowledge bases, but traditional generative architectures introduce catastrophic cross-department data leakage risks. If a standard employee asks an enterprise AI assistant, "What were the executive compensation adjustments approved last month?" or "Summarize the confidential litigation strategy regarding our vendor dispute," a naive Retrieval-Augmented Generation (RAG) system pulling from a shared vector store will happily retrieve and summarize those sensitive documents.

Prompt guardrails (such as system instructions telling the model "do not discuss payroll") fail under adversarial prompt injection, oblique questions, or semantic rephrasing. True enterprise data isolation must be architectural and deterministic, preventing unauthorized data from ever entering the model's context window.

Dust solves this problem through an infrastructure-level Dual-Layer Permission Model anchored by Spaces (isolated data containers), Role-Based Access Control (RBAC), SCIM-driven Identity Provider (IdP) directory synchronization, and connector-level scope isolation. This guide details how enterprise IT administrators can systematically configure Dust Spaces, manage workspace permissions, and deploy department-safe custom AI assistants that strictly respect organizational boundaries.

1. The Core Architecture: Dust’s Dual-Layer Permission Model

To understand how Dust prevents cross-department data leakage, IT administrators must separate how agents access data from how humans access agents. Traditional SaaS platforms use single-layer access control: can User X view Document Y? Generative AI assistants break this assumption because autonomous agents can synthesize, aggregate, and transform data on behalf of an end user.

Dust addresses this with a dual-layer permission model:

[ External Systems (Drive, SharePoint, Slack, Notion) ]
                        │
                        ▼ (Admin Scoping & Service Account)
              [ Dust Connections ]
                        │
                        ▼ (Admin-Assigned Data Subsets)
         ┌──────────────┴──────────────┐
         ▼                             ▼
  [ Open Spaces ]             [ Restricted Spaces ]
  (e.g., Company Data)        (e.g., Finance, Legal, HR)
         │                             │
         ▼                             ▼
  [ General Agents ]           [ Departmental Agents ]
         │                             │
         ▼                             ▼
  (All Workspace Members)      (Strict Group Members Only)
         ▲                             ▲
         └──────────────┬──────────────┘
                        │
              [ Human Users & Groups ]
              (Provisioned via IdP / SCIM)

Layer 1: Agent-to-Data Access (Deterministic Data Containment)

When an agent is created in Dust, its retrieval and tool capabilities are bound strictly to designated Spaces. An agent configured with knowledge only from the Engineering Space and Company Data Space has no programmatic route to query, index, or retrieve vectors stored inside the Finance Space or Legal Space. The boundary is enforced at the database and retrieval layer before the Large Language Model (LLM) is ever invoked.

Layer 2: Human-to-Agent Access ("Safety by Default" Visibility)

Dust enforces a strict rule: The spaces used by an agent determine who can see and use that agent. By default, an employee can only view, search, and invoke an agent if that employee is an authorized member of every single space referenced by the agent's knowledge sources and tools.

If an assistant requires access to the Restricted Finance Space, Dust automatically hides and disables that assistant for any user who is not explicitly a member of the Finance Space. This eliminates proxy leakage attacks: an unauthorized user cannot use a high-privilege agent as an intermediary to extract protected corporate data.

2. Spaces Strategy: Segregating Public and Restricted Data Domains

Dust organizes all workspace information into Spaces. Setting up spaces correctly is the foundational step for preventing cross-department leaks.

Open Spaces vs. Restricted Spaces

The Role of the "Company Data" Space

Every Dust workspace includes a default space named Company Data.

• This space is open to all workspace members and cannot be deleted, renamed, or made restricted.
• Data added to Company Data is discoverable by default enterprise agents (such as @dust).
• Governance Rule for Admins: Never attach sensitive, departmental, or regulated data (such as compensation spreadsheets, executive Slack channels, or confidential client matters) to Company Data. Treat Company Data as a public company billboard.

Workspace Space Capacities

• Business Plan: Supports up to 5 spaces. Suitable for smaller organizations requiring baseline separation (e.g., Company Data, Leadership, Engineering, Sales, Operations).
• Enterprise Plan: Supports up to 100 spaces. Designed for multi-department organizations requiring granular per-team, per-project, or per-client isolation (e.g., regional HR, internal audit, R&D patent filings).

3. Step-by-Step Implementation: Configuring Zero-Leakage AI Assistants

To implement an airtight, cross-department data governance policy in Dust, IT administrators should follow this six-step deployment workflow.

Step 1: Upstream Identity Provisioning via SCIM 2.0

Manual user management inevitably leads to permission drift and orphaned privileges. Enterprise plans should connect Dust to their central Identity Provider (Okta, Microsoft Entra ID, Google Workspace) using SCIM 2.0.

1. In Dust, navigate to Admin > Organization > Members > Groups > User provisioning > Set up Directory sync.
2. Select your IdP and complete the Directory Sync connection.
3. Configure group pushing for all department classifications (e.g., dept-finance, dept-legal, dept-people, exec-staff).
4. As employees join, transfer departments, or exit the company, their group memberships in Dust update in real time. When an employee leaves the finance department in Entra ID, their access to the Dust Finance Space—and all associated finance assistants—is revoked instantaneously.

Step 2: Establish Source-Level Scoping with Dedicated Service Accounts

Dust connectors (Google Drive, Microsoft SharePoint/OneDrive, Notion, Confluence, Slack) sync data directly from enterprise repositories. To prevent accidental over-indexing:

1. Avoid personal admin credentials: Never connect corporate repositories using an individual IT admin’s personal account. If that person leaves, sync breaks; worse, their personal drafts could be exposed.
2. Use dedicated service accounts:
   • Google Drive: Create a dedicated user such as dust-admin@yourdomain.com. Only grant this service account read and download permissions to the specific Shared Drives intended for AI indexing.
   • Microsoft SharePoint / OneDrive: Use an Entra ID App Registration with Sites.Selected application permissions, or a dedicated Microsoft 365 service account (dust-service@yourdomain.com). Use PowerShell (Grant-PnPAzureADAppSitePermission) or Microsoft Graph API to restrict the service principal exclusively to designated SharePoint site collections.
   • Slack: Only invite the Dust bot to public channels or specific restricted archive channels. The connector will only index channels where access has been deliberately authorized.
3. Select folder trees selectively: In Dust's connection setup modal, drill down into specific folders. Never sync an entire root Google Drive or root SharePoint tenant if sensitive sub-directories reside beneath them.

Step 3: Create Restricted Spaces and Map Provisioned Groups

Once data connectors are authenticated, data remains in a staging pool until an administrator explicitly binds it to a Space.

1. Navigate to the Spaces tab in Dust and click New.
2. Enter the Space name (e.g., Finance & Accounting).
3. Select Restricted.
4. In the membership configuration, select Provisioned group access and link the synced IdP group (e.g., dept-finance).
5. Open the newly created Space, navigate to Connected Data, and click Add data from connections.
6. Select only the specific folders, SharePoint document libraries, or Notion databases designated for this department.
7. Click Save. Dust will now index and isolate those documents specifically within this restricted container.

Dust Admin UI: Spaces Setup
┌─────────────────────────────────────────────────────────────┐
│ Create New Space                                            │
│ Name: [ Finance & Accounting                              ] │
│ Access Type: ( ) Open   (•) Restricted                      │
│ Member Assignment:                                          │
│   [ Provisioned group access                              ▼]│
│   Groups: [ dept-finance x ] [ exec-cfo x ]                 │
│                                                             │
│ Data Sources (Connected Data):                              │
│   [x] Google Drive: /Shared Drives/Finance/FY26_Budgets/    │
│   [x] SharePoint: /sites/FinanceOps/Financial_Statements/   │
│   [ ] Google Drive: /Shared Drives/Company_Wide/ (Excluded) │
│                                                             │
│ [ Cancel ]                                [ Create Space ]  │
└─────────────────────────────────────────────────────────────┘

Step 4: Configure Workspace Roles and Builder Governance

By default, new Dust workspaces permit all members to build and publish agents. In an enterprise environment, unmonitored agent creation can lead to compliance violations.

Navigate to Admin > Governance to configure the permission matrix:

1. Create agents & Publish agents: Change access from Everyone to Groups (e.g., an approved AI Builders group) or Admin only. This ensures custom assistants undergo review before appearing in the company catalog.
2. Create skills & Manage skill availability: Keep set to Admin only or delegated technical leads to prevent unauthorized external API or tool integrations.
3. Map Roles to Groups: In Admin > Members > Roles, map directory groups to Dust roles. Ensure only senior infrastructure engineers hold the Admin role. Department team leads can be assigned the Manager role or appointed as Group Managers to supervise credit spend and group memberships without granting them broad security controls.
4. Delegate Security & Billing carefully: Access to security controls and audit logs is not tied to the generic Manager role. It requires explicit delegation of the Access security features permission.

Step 5: Build Department-Isolated AI Assistants

When authoring custom assistants in Dust Agent Builder, knowledge tools must be pointed precisely at target spaces:

1. Under the agent's Instructions, define the scope, persona, and behavioral boundaries.
2. In the Knowledge / Tools section:
   • Select Search data sources.
   • Pick only the relevant Restricted Space (e.g., Finance & Accounting).
   • Avoid adding the default Company Data space unless the assistant genuinely needs company-wide policies alongside financial data.
3. Verify the Multi-Space Intersection Rule:
   • If an agent requires tools pointing to Space A (Finance) and Space B (Executive), a user must belong to BOTH Space A and Space B to see and execute the agent.
   • If a user only belongs to Space A, Dust hides the agent entirely.
   • Best Practice: Keep assistants single-space focused whenever possible to prevent unintentional lockout of authorized team members.

Step 6: Configure Tool Credentials (Personal vs. Shared)

For assistants that execute external actions or live queries (via GitHub, HubSpot, Jira, Salesforce, or MCP servers), administrators must configure the credential mode in Knowledge > Tools:

• Shared Credentials: All users invoke the tool using a centralized service account configured by the Admin.
  • When to use: Internal utility tools querying common read-only reference databases where all permitted users possess identical authorization levels.
• Personal Credentials: The administrator completes the initial OAuth configuration to establish metadata (instance URL, tenant ID), but each employee must authenticate using their own personal account upon first invocation.
  • When to use: Tools interacting with systems containing internal row-level or object-level permissions (e.g., Salesforce CRM, GitHub private repositories, Jira issue tracking). If a marketing user triggers a Salesforce tool, the agent can only read records that the user's specific Salesforce account is permitted to access. This provides double-layer protection: Dust Space isolation plus origin-system RBAC.

4. Auditing, Compliance, and Lifecycle Management

Configuration is only half the battle; enterprise compliance teams require continuous proof that boundaries are holding.

┌──────────────────────────────────────────────────────────────┐
│                    Enterprise Event Stream                   │
└──────────────────────────────┬───────────────────────────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
   [ User-Initiated Event ]             [ AI Agent Action ]
   actor: "user"                        actor: "user"
   action: "agent.executed"             metadata.actor_type: "agent"
   targets: ["agent-finance-01"]        metadata.initiating_user: "..."
            │                                     │
            └──────────────────┬──────────────────┘
                               ▼
               [ Dust Enterprise Audit Engine ]
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
  [ Internal Tamper-Evident ]            [ SIEM Log Streaming ]
  (Admin > Security > Audit Logs)        (Datadog, Splunk, S3, GCS)

Audit Logs for Security Attribution

Dust Enterprise includes a tamper-evident audit log accessible under Admin > Organization > Security > Audit Logs (requiring the Access security features permission).

Every log entry captures:

• Who: Actor type (user, api_key, or system), user ID, email, IP address, and user agent.
• What: The precise event (agent.executed, space.created, space.deleted, data_source.updated, tool.executed).
• Originator Attribution: Crucially, Dust differentiates between human actions and AI-driven downstream actions. When an agent queries a data source or executes a tool, the log records metadata.actor_type: "agent", while preserving the human initiating_user_id and initiating_user_email. Security auditors can trace exact prompt provenance across multi-agent workflows.

SIEM Streaming

Enterprise environments can stream audit logs in real time to centralized security platforms, including Datadog, Splunk, AWS S3, Google Cloud Storage (GCS), or arbitrary HTTPS webhook endpoints. If your SIEM endpoint restricts inbound connections, whitelist the official WorkOS delivery IP range documented by Dust to ensure reliable telemetry delivery.

Automated Offboarding and Deprovisioning Safeguards

When an employee leaves the company:

1. SCIM directory sync automatically deactivates their Dust seat.
2. Their access to all Restricted Spaces is cut off immediately.
3. Dust permanently deletes all personal automations and triggers created by that user.
4. Admin Operational Check: Before deprovisioning key personnel, admins should review Programmatic Usage > Automations and reassign assistant editors. If an agent was unpublished and only edited by the departing user, admins can open the agent in Agent Builder and click Become an editor as an admin to maintain organizational ownership.

5. Architectural Matrix and Governance Checklist

Space & Permission Design Matrix

Pre-Deployment IT Admin Checklist

• Directory Sync Enabled: SCIM 2.0 active with department groups synced from Okta or Entra ID.
• Company Data Sanitized: Verified that no confidential spreadsheets, compensation data, or legal notes exist in the default Open Space.
• Dedicated Service Accounts Created: Google Drive and Microsoft SharePoint connections configured via non-human service identities with scoped folder rights.
• Restricted Spaces Configured: Sensitive departments isolated into dedicated Restricted Spaces with "Provisioned group access" selected.
• Connector Data Mapped: Sensitive connector folders assigned exclusively to their corresponding Restricted Spaces under Connected Data.
• Builder Roles Locked Down: Create agents and Publish agents restricted to authorized groups in Admin > Governance.
• High-Risk Tools Switched to Personal Credentials: Systems with user-specific permissions (Salesforce, GitHub, Jira) configured to require individual OAuth logins.
• Audit Logging Configured: SIEM log streaming connected to corporate security monitoring (Splunk/Datadog) and verified with test queries.

By combining Dust’s structural Space boundaries with upstream identity synchronization and source-level connector scoping, IT administrators can deliver cutting-edge conversational AI to every department while guaranteeing zero cross-department data leakage.

References

• Spaces management
• Workspace Governance: Roles, Groups & Permissions
• Access Controls and Permissions
• Users and groups provisioning
• Personal vs Shared Credentials for Tools & MCP Servers
• Agents management
• Audit Logs
• Google Drive
• Microsoft
• Dust Security: Enterprise-Grade Data Protection