Configuração do Dust Spaces e Controle de Acesso Baseado em Funções: Como Administradores de TI Previnem Vazamento de Dados entre Departamentos em Assistentes de IA

Ao implementar assistentes corporativos de inteligência artificial generativa em escala, administradores de TI e líderes de segurança da informação deparam-se com um dilema crítico: os colaboradores obtêm ganhos substanciais de produtividade ao consultar bases de conhecimento internas por linguagem natural, mas arquiteturas convencionais de Geração Aumentada por Recuperação (RAG) trazem riscos gravíssimos de vazamento de dados entre departamentos. Se um profissional de marketing perguntar a um assistente de IA corporativo genérico: "Quais foram os reajustes de remuneração da diretoria aprovados no mês passado?" ou "Resuma a estratégia jurídica confidencial da disputa contra o fornecedor", um pipeline tradicional de RAG que consulte uma base vetorial compartilhada irá resgatar e sintetizar prontamente essas informações confidenciais.

Confiar apenas em instruções no prompt (Prompt Guardrails, como orientar o modelo dizendo "não responda sobre salários") mostra-se ineficaz diante de injeções de prompt bem elaboradas, perguntas indiretas ou variações semânticas. O isolamento de dados corporativos precisa ser estrutural e determinístico, impedindo que documentos não autorizados entrem na janela de contexto (Context Window) do modelo de linguagem (LLM).

O Dust resolve essa vulnerabilidade por meio de um Modelo de Permissões de Camada Dupla (Dual-Layer Permission Model), sustentado por Spaces (contêineres de dados isolados), Controle de Acesso Baseado em Funções (RBAC), provisionamento de diretórios via SCIM / IdP e restrição de escopo em nível de conectores. Este guia detalha o passo a passo para administradores de TI configurarem o Dust Spaces, gerenciarem privilégios e criarem assistentes de IA departamentais totalmente blindados contra vazamentos internos.

1. Arquitetura Fundamental: O Modelo de Permissões de Camada Dupla do Dust

Para evitar vazamentos interdepartamentais, a equipe de TI precisa separar nitidamente o acesso do assistente aos dados do accesso do usuário ao assistente. Ferramentas SaaS tradicionais costumam utilizar controle de acesso unidimensional: o Usuário X pode abrir o Documento Y? Na era da IA generativa, assistentes autônomos processam, agregam e interpretam múltiplos documentos em nome do usuário, tornando obsoletas as barreiras convencionais.

O Dust estrutura a proteção em duas camadas complementares:

[ Sistemas Externos (Drive, SharePoint, Slack, Notion) ]
                         │
                         ▼ (Escopo de Administrador e Conta de Serviço)
                 [ Conexões do Dust ]
                         │
                         ▼ (Subconjuntos de Dados Alocados)
          ┌──────────────┴──────────────┐
          ▼                             ▼
   [ Open Spaces (Públicos) ]   [ Restricted Spaces (Restritos) ]
   (ex.: Company Data)          (ex.: Finanças, Jurídico, RH)
          │                             │
          ▼                             ▼
   [ Assistentes Gerais ]       [ Assistentes Departamentais ]
          │                             │
          ▼                             ▼
   (Toda a Organização)         (Apenas Membros do Espaço Restrito)
          ▲                             ▲
          └──────────────┬──────────────┘
                         │
              [ Usuários e Grupos ]
              (Sincronizados via SCIM / IdP)

Camada 1: Acesso do Assistente aos Dados (Contenção Determinística)

Ao criar um assistente no Dust, sua capacidade de consulta vetorial e execução de ferramentas fica rigidamente restrita aos Spaces aos quais foi vinculado. Se um assistente foi configurado com fontes do Espaço de Engenharia e do Espaço Company Data, ele não tem capacidade técnica nem caminhos de consulta para indexar ou ler dados contidos no Espaço Financeiro ou no Espaço Jurídico. Essa separação ocorre no banco de dados e nos índices antes que qualquer requisição chegue ao LLM.

Camada 2: Acesso do Usuário ao Assistente (Visibilidade Segura por Padrão)

O Dust estabelece um princípio determinante: os espaços utilizados por um assistente definem quem pode visualizá-lo e utilizá-lo. Por padrão, um colaborador só pode encontrar, visualizar e acionar um assistente se for membro autorizado de todos os espaços vinculados às ferramentas e bases daquele agente.

Caso um assistente utilize o Restricted Space do departamento financeiro, o Dust oculta-o automaticamente da interface de qualquer funcionário que não pertença a esse grupo. Isso elimina tentativas de exploração indireta: nenhum usuário consegue utilizar um assistente com altos privilégios como intermediário para acessar dados confidenciais aos quais não teria direito diretamente.

2. Estratégia de Spaces: Segregação de Dados Públicos e Restritos

No Dust, todo o conteúdo, documentos e integrações residem dentro de Spaces. O planejamento adequado desses contêineres é o primeiro pilar da segurança da informação.

Comparativo: Open Spaces vs. Restricted Spaces

O Papel do Espaço Padrão "Company Data"

Todo workspace no Dust possui um espaço aberto padrão denominado Company Data:

• É acessível a todos os membros e não pode ser excluído, renomeado ou tornado restrito.
• Documentos adicionados a ele ficam disponíveis para assistentes padrão da empresa (como o @dust).
• Regra de ouro de governança: Nunca vincule relatórios de faturamento confidencial, canais de liderança executiva ou documentos de litígio ao Company Data. Trate este espaço como o mural público de comunicados da organização.

Limites de Spaces por Plano

• Plano Business: Suporta até 5 spaces. Indicado para empresas com estrutura simples que demandam isolamento básico (Company Data, Diretoria, Engenharia, Vendas e Operações).
• Plano Enterprise: Suporta até 100 spaces. Criado para organizações complexas que exigem separação por departamento, projeto confidencial ou subsidiária (como auditoria interna, controladoria, remuneração executiva e litígios regulatórios).

3. Passo a Passo de Implementação em 6 Etapas para Administradores de TI

Para implementar uma governança com vazamento zero entre áreas, os administradores de TI devem seguir este roteiro sistemático:

Etapa 1: Provisionamento de Identidade Automatizado via SCIM 2.0

O gerenciamento manual de permissões resulta invariavelmente em privilégios órfãos e acessos indevidos após mudanças de cargo. Em planos Enterprise, a sincronização via SCIM com o provedor de identidade (Okta, Microsoft Entra ID ou Google Workspace) é mandatória.

1. No Dust, acesse Admin > Organization > Members > Groups > User provisioning > Set up Directory sync.
2. Selecione seu IdP e siga as etapas para conectar o Directory Sync.
3. Configure o envio de grupos organizacionais (como dept-finance, dept-legal, dept-people, exec-board).
4. Ao ocorrer uma transferência de setor ou desligamento no IdP, o Dust atualiza os acessos em tempo real: se um colaborador for transferido do departamento financeiro no Entra ID, seu acesso ao espaço restrito de Finanças — e a todos os seus assistentes vinculados — é revogado instantaneamente.

Etapa 2: Conexões de Dados com Contas de Serviço Dedicadas

Os conectores do Dust (Google Drive, Microsoft SharePoint/OneDrive, Notion, Confluence, Slack) realizam a ingestão de conteúdos corporativos. Para manter o princípio do menor privilégio:

1. Evite contas pessoais de administradores: Nunca autentique integrações usando o e-mail de um administrador individual. Caso ele saia da empresa, a sincronização será interrompida e arquivos pessoais de rascunho poderão ser expostos.
2. Utilize contas de serviço exclusivas:
   • Google Drive: Crie uma identidade dedicada, como dust-admin@suaempresa.com, concedendo acesso estrito de leitura e download apenas aos Drives Compartilhados destinados ao assistente.
   • Microsoft SharePoint / OneDrive: Registre um aplicativo no Entra ID com permissões de aplicação Sites.Selected, ou configure uma conta de serviço (dust-service@suaempresa.com) e restrinja as coleções de sites permitidas via PowerShell (Grant-PnPAzureADAppSitePermission) ou Microsoft Graph API.
   • Slack: Inclua o bot do Dust apenas em canais públicos ou de arquivo selecionados, mantendo-o fora de canais fechados e confidenciais.
3. Selecione pastas de forma granular: Na janela de configuração de dados do Dust, navegue pela estrutura de pastas e selecione apenas os subdiretórios pertinentes, evitando sincronizar diretórios raiz inteiros.

Etapa 3: Criação de Espaços Restritos e Associação de Grupos do IdP

Após a sincronização, os dados ficam em um repositório central aguardando direcionamento administrativo.

1. Acesse a aba Spaces no Dust e clique em New.
2. Defina o nome do espaço (por exemplo: Finance & Accounting).
3. Marque a opção Restricted.
4. Em associação de membros, selecione Provisioned group access e aponte para o grupo sincronizado via SCIM (ex.: dept-finance).
5. Abra o novo espaço, entre em Connected Data e clique em Add data from connections.
6. Marque estritamente as pastas do Drive ou bibliotecas do SharePoint destinadas àquela área.
7. Salve as alterações. Os documentos agora estão blindados dentro daquele contêiner restrito.

Painel de Administração do Dust: Criação de Espaço Restrito
┌─────────────────────────────────────────────────────────────┐
│ Criar Novo Espaço (Create New Space)                        │
│ Nome: [ Finance & Accounting                              ] │
│ Tipo de Acesso: ( ) Open (Aberto)   (•) Restricted          │
│ Atribuição de Membros:                                      │
│   [ Provisioned group access                              ▼]│
│   Grupos: [ dept-finance x ] [ exec-cfo x ]                 │
│                                                             │
│ Fontes Conectadas (Connected Data):                         │
│   [x] Google Drive: /Shared Drives/Finance/FY26_Budgets/    │
│   [x] SharePoint: /sites/FinanceOps/Financial_Statements/   │
│   [ ] Google Drive: /Shared Drives/Company_Wide/ (Excluído) │
│                                                             │
│ [ Cancelar ]                                 [ Criar Espaço]│
└─────────────────────────────────────────────────────────────┘

Etapa 4: Governança de Funções (RBAC) e Restrição de Criação de Agentes

Em sua configuração inicial, o Dust permite que qualquer membro crie e publique assistentes. Em ambientes empresariais, isso precisa ser regulamentado.

Acesse Admin > Governance para calibrar a matriz de permissões:

1. Create agents e Publish agents: Altere o acesso de Everyone para grupos qualificados (como um grupo de criadores autorizados AI Builders) ou para Admin only, evitando que agentes não homologados sejam lançados para a empresa.
2. Create skills e Manage skill availability: Mantenha restrito a administradores (Admin only) para evitar chamadas arbitrárias a APIs externas.
3. Mapeamento de Funções: Em Admin > Members > Roles, associe grupos de diretório a funções no Dust. Mantenha a função de Admin restrita à equipe central de TI. Gestores de área podem receber a função de Manager ou serem nomeados Group Managers (Gestores de Grupo) para administrar limites de uso e membros locais sem acessar parâmetros de segurança de infraestrutura.
4. Delegação de Segurança e Faturamento: As permissões Access security features e Access billing features não são concedidas automaticamente com o papel de Manager; elas exigem atribuição explícita por um Admin.

Etapa 5: Criação do Assistente Departamental e Regra de Interseção

Ao configurar assistentes no Agent Builder:

1. Defina as Instructions detalhando as normas de atuação e escopo de atuação.
2. Na seção Knowledge / Tools, inclua a ferramenta Search data sources:
   • Marque apenas o espaço restrito correspondente (ex.: Finance & Accounting).
   • Evite marcar o espaço Company Data, a menos que o assistente precise obrigatoriamente de manuais gerais da organização.
3. Entenda a Regra de Interseção Multiespaço (Condição AND):
   • Se um assistente exigir bases do Espaço A (Finanças) e do Espaço B (Diretoria), o usuário precisará ser membro de AMBOS os espaços para conseguir enxergar e utilizar o agente.
   • Usuários com acesso apenas ao Espaço A não verão o agente na interface.
   • Boa prática: Vincule cada assistente a apenas um espaço restrito sempre que possível para evitar bloqueios acidentais a membros legítimos.

Etapa 6: Configuração de Credenciais em Ferramentas Externas (Personal vs. Shared)

Para assistentes que executam chamadas em sistemas como GitHub, Salesforce, Jira, HubSpot ou servidores MCP, selecione o modelo de credencial em Knowledge > Tools:

• Credenciais Compartilhadas (Shared Credentials): Todos os usuários acionam a ferramenta por meio de uma conta corporativa central configurada pela TI. Recomendado para bases de consulta geral.
• Credenciais Pessoais (Personal Level Credentials): O administrador conclui a configuração do fluxo OAuth global e, no primeiro uso, cada usuário faz login com sua conta individual.
  • Recomendado para dados sensíveis: Em sistemas como Salesforce ou repositórios privados do GitHub, essa configuração garante que o agente só consiga ler ou gravar aquilo que o perfil do próprio usuário permite dentro daquela ferramenta, unindo o isolamento do Dust Spaces ao controle de acesso do sistema de origem.

4. Auditoria, Monitoramento Contínuo e Ciclo de Desligamento

A conformidade contínua exige visibilidade granular sobre quem acessou quais informações e quando.

┌──────────────────────────────────────────────────────────────┐
│                Fluxo de Eventos em Tempo Real                │
└──────────────────────────────┬───────────────────────────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
     [ Ação de Usuário Humano ]            [ Ação Autônoma da IA ]
     actor: "user"                         actor: "user"
     action: "agent.executed"              metadata.actor_type: "agent"
     targets: ["agent-finance-01"]         metadata.initiating_user: "..."
            │                                     │
            └──────────────────┬──────────────────┘
                               ▼
               [ Motor de Auditoria Enterprise ]
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
     [ Painel de Auditoria Interno ]       [ Transmissão para SIEM ]
     (Admin > Security > Audit Logs)       (Datadog, Splunk, S3, GCS)

Registros de Auditoria: Distinção entre Ações Humanas e de IA

Os logs de auditoria do Dust Enterprise (em Admin > Organization > Security > Audit Logs) registram todas as operações relevantes com proteção contra adulteração:

• Identidade (Actor): Identifica se o evento partiu de um usuário humano (user), chave de API (api_key) ou automação (system), incluindo endereço IP e user-agent.
• Ação Executada: Registra operações como agent.executed, space.created, space.deleted, data_source.updated e tool.executed.
• Rastreabilidade de Ações de IA: Quando um assistente consulta uma base ou dispara uma ferramenta, o log aponta metadata.actor_type: "agent", mas mantém gravado o identificador do usuário humano responsável (initiating_user_id e initiating_user_email), garantindo rastreabilidade jurídica completa em caso de auditorias.

Exportação Contínua para Plataformas SIEM

Organizações podem direcionar os registros de auditoria em tempo real para soluções de segurança corporativa como Datadog, Splunk, AWS S3, Google Cloud Storage (GCS) ou webhooks HTTPS personalizados. Em redes com restrição estrita de saída, certifique-se de liberar os IPs de entrega do WorkOS especificados na documentação técnica do Dust.

Desligamento de Colaboradores e Mitigação de Riscos

Quando um funcionário se desliga da empresa:

1. O IdP desativa o usuário e o SCIM revoga instantaneamente sua conta no Dust.
2. Seu acesso a todos os espaços restritos e assistentes departamentais é imediatamente cancelado.
3. Todas as automações e gatilhos agendados (Triggers) criados por aquele colaborador são excluídos definitivamente.
4. Procedimento administrativo de transição: Antes de efetivar a desativação, a equipe de TI deve consultar Programmatic Usage > Automations para reatribuir proprietários a tarefas críticas. Caso haja assistentes não publicados criados pelo usuário demitido, um administrador pode acessar o Agent Builder e clicar em Become an editor as an admin para assumir a edição e evitar a perda do ativo.

5. Matriz de Arquitetura e Lista de Verificação de TI

Matriz de Governança de Espaços e Permissões

Lista de Verificação Pré-Implementação para TI

• Sincronização SCIM 2.0 ativada: Grupos departamentais do Okta ou Entra ID devidamente replicados no Dust.
• Limpeza do Company Data concluída: Verificado que nenhuma folha salarial, previsão orçamentária confidencial ou parecer jurídico está no espaço público.
• Contas de serviço ativas: Conectores de Drive e SharePoint operando sob contas de serviço dedicadas com permissões de pasta delimitadas.
• Espaços Restritos associados: Espaços configurados com Provisioned group access para as áreas sensíveis.
• Fontes de dados alocadas: Subpastas confidenciais mapeadas estritamente dentro dos respectivos espaços restritos.
• Controle de publicação ativado: Em Admin > Governance, permissão de criação e publicação de agentes restrita a grupos certificados ou administradores.
• Ferramentas com credenciais individuais: Sistemas com controle de permissão por usuário (Salesforce, GitHub, Jira) configurados como Personal Credentials.
• Transmissão SIEM validada: Envio de logs de auditoria para o Splunk ou Datadog em operação com alertas de teste confirmados.

Ao estruturar a segregação por Spaces e combiná-la com o provisionamento de identidade e controle granular de ferramentas, a equipe de TI garante que os assistentes de IA operem com máxima eficiência sem expor o patrimônio informacional confidencial da organização.

Referências

• 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