기업 전사적으로 생성형 AI 어시스턴트(AI Assistants / Agents)를 도입할 때, IT 관리자와 정보보안·컴플라이언스 책임자는 중대한 보안 과제에 직면합니다. 사내 지식 기반과 연동된 대화형 AI는 임직원의 생산성을 극대화하지만, 기존의 검색 증강 생성(RAG) 아키텍처는 부서 간 데이터 유출(Cross-Department Data Leakage)이라는 치명적인 보안 허점을 초래할 수 있기 때문입니다. 만약 마케팅팀 직원이 일반 전사 AI 어시스턴트에게 *"지난달 이사회에서 승인된 임원 급여 인상 내역을 알려줘"*라거나 *"공급업체와의 분쟁에 관한 법무팀의 비공개 소송 대응 전략을 요약해 줘"*라고 질문한다면, 단일 벡터 데이터베이스를 조회하는 단순한 시스템은 권한이 없는 민감한 문서를 그대로 검색하여 답변을 생성해 버립니다.
시스템 프롬프트 지침(Prompt Guardrails, 예: "급여 관련 질문에는 답변하지 말 것")에만 의존하는 방식은 악의적인 프롬프트 인젝션이나 우회 질문, 문맥 재구성에 매우 취약합니다. 엔터프라이즈 환경에서의 데이터 격리는 비인가 데이터가 대규모 언어 모델(LLM)의 컨텍스트 윈도우(Context Window)에 물리적으로 진입하지 못하도록 아키텍처 수준에서 결정론적(Deterministic)으로 강제되어야 합니다.
Dust는 데이터 격리 컨테이너인 Spaces, 역할 기반 접근 제어(RBAC), SCIM 기반 IdP(Identity Provider) 디렉터리 동기화, 그리고 커넥터 수준의 세부 범위 설정이 결합된 독자적인 **이중 계층 권한 모델(Dual-Layer Permission Model)**을 통해 이 문제를 완벽하게 해결합니다. 본 가이드에서는 엔터프라이즈 IT 관리자가 Dust Spaces와 권한 매트릭스를 체계적으로 구성하여 부서 간 정보 유출을 원천 차단하는 방법을 상세히 설명합니다.
1. 핵심 아키텍처: Dust의 이중 계층 권한 모델
부서 간 데이터 유출을 차단하려면 먼저 에이전트의 데이터 접근 권한과 인간 사용자의 에이전트 사용 권한을 명확히 분리해야 합니다. 전통적인 SaaS 플랫폼은 "사용자 X가 문서 Y를 볼 수 있는가?"라는 단일 계층 접근 제어 방식을 사용합니다. 그러나 생성형 AI 환경에서는 자율 에이전트가 사용자를 대신해 여러 문서를 취합하고 분석하므로, 단일 계층 모델은 쉽게 우회될 수 있습니다.
Dust는 이를 해결하기 위해 이중 계층 권한 모델을 적용합니다:
[ 외부 데이터 소스 (Google Drive, SharePoint, Slack, Notion) ]
│
▼ (관리자 범위 제한 및 전용 서비스 계정)
[ Dust Connections (연결) ]
│
▼ (관리자가 할당한 특정 데이터 서브셋)
┌──────────────┴──────────────┐
▼ ▼
[ Open Spaces (공개 공간) ] [ Restricted Spaces (제한 공간) ]
(예: Company Data) (예: 재무, 법무, 인사)
│ │
▼ ▼
[ 전사 공용 에이전트 ] [ 부서 전용 제한 에이전트 ]
│ │
▼ ▼
(워크스페이스 전원 사용 가능) (해당 제한 Space 구성원만 조회/실행)
▲ ▲
└──────────────┬──────────────┘
│
[ 사용자 및 그룹 ]
(IdP / SCIM으로 자동 동기화)
계층 1: 에이전트와 데이터 간 접근 (결정론적 데이터 격리)
Dust에서 에이전트를 생성할 때, 해당 에이전트의 검색 도구와 지식베이스는 지정된 Spaces에만 엄격히 바인딩됩니다. 예를 들어 '기술 지원 Space'와 전사 공용 'Company Data Space'에만 연결된 에이전트는 '재무 제한 Space'나 '법무 제한 Space'의 벡터 인덱스를 기술적으로 탐색하거나 조회할 수 있는 인터페이스 자체가 존재하지 않습니다. 이 경계는 데이터베이스 및 벡터 검색 계층에서 사전에 강제되므로, 권한 없는 문서 청크가 LLM 추론에 사용될 가능성이 원천 차단됩니다.
계층 2: 사용자와 에이전트 간 접근 ("기본 안전" 가시성 제어)
Dust는 확고한 보안 원칙을 따릅니다: "에이전트가 사용하는 Spaces가 해당 에이전트를 보고 사용할 수 있는 사용자를 결정한다." 기본적으로 사용자는 에이전트가 참조하는 모든 Spaces에 대한 접근 권한을 보유하고 있어야만 워크스페이스 내에서 해당 에이전트를 검색하고 호출할 수 있습니다.
재무팀 전용 Restricted Space를 참조하는 에이전트가 있다면, 재무팀 구성원이 아닌 직원의 Dust 화면에는 해당 에이전트 자체가 전혀 노출되지 않습니다. 이를 통해 권한이 없는 직원이 고권한 에이전트를 대리인(Proxy) 삼아 기밀 데이터를 캐내는 간접 권한 상승 공격을 완벽하게 방어합니다.
2. Spaces 전략: 공개 데이터 영역과 제한 데이터 영역의 분리
Dust의 모든 데이터, 문서, 통합 도구는 Spaces라는 컨테이너 내에서 관리됩니다. 올바른 공간 아키텍처 수립이 데이터 유출 방지의 출발점입니다.
Open Spaces와 Restricted Spaces 비교
| 구분 | Open Spaces (예: Company Data) | Restricted Spaces (제한된 공간) |
|---|---|---|
| 구성원 범위 | 워크스페이스의 모든 구성원이 자동 참여 | 지정된 특정 사용자 또는 SCIM 연동 IdP 그룹 |
| 관리 권한 | 워크스페이스 관리자(Admin) 전용 | 워크스페이스 관리자(Admin) 전용 |
| 연결 데이터 | 관리자가 지정한 전사 공통 파일 및 채널 | 관리자가 부서별로 선별하여 격리한 기밀 파일/채널 |
| 자체 업로드 데이터 | 관리자 및 빌더(Builder)만 추가 가능 | 해당 제한 공간의 모든 구성원이 추가 가능 |
| 에이전트 가시성 | 전사 임직원 모두가 확인 및 호출 가능 | 해당 제한 공간의 승인된 구성원에게만 노출 |
| 주요 활용 사례 | 전사 사규, 복리후생 가이드, 제품 매뉴얼 | 급여 명세, 이사회 회의록, 미공개 소송 문서, M&A 자료 |
Company Data 공간의 역할과 관리 철칙
모든 Dust 워크스페이스에는 기본적으로 Company Data라는 Open Space가 생성되어 있습니다:
- 이 공간은 전사 임직원에게 항상 개방되어 있으며, 삭제, 이름 변경, 접근 제한 설정이 불가능합니다.
- Company Data에 포함된 데이터는 전사 기본 에이전트(예:
@dust)가 즉시 검색할 수 있습니다. - IT 관리자의 운영 철칙: 급여 내역, 임원 전용 Slack 채널, 비공개 계약서 등 민감한 문서를 절대 Company Data에 연결해서는 안 됩니다. 이 공간은 전사 게시판에 공개할 수 있는 수준의 정보만을 보관해야 합니다.
플랜별 Spaces 생성 한도
- Business 플랜: 최대 5개의 Spaces 생성 가능. 조직 구조가 비교적 단순하고 기본적인 분리(Company Data, 경영진, 개발, 영업, 운영 등)만 필요한 중소규모 기업에 적합합니다.
- Enterprise 플랜: 최대 100개의 Spaces 생성 가능. 법무 검토, 감사, 인사 보상, 인수합병 등 부서별·프로젝트별로 엄격한 물리적 격리가 요구되는 대기업 및 글로벌 조직에 적합합니다.
3. IT 관리자를 위한 6단계 세부 구축 가이드
부서 간 데이터 유출 위험이 없는 안전한 AI 에이전트 환경을 구축하기 위해 IT 관리자는 다음의 표준 절차를 이행해야 합니다.
1단계: SCIM 2.0 기반 IdP 디렉터리 동기화 연동
수동으로 사용자를 초대하고 권한을 관리하면 부서 이동이나 퇴사 시 권한 누수가 반드시 발생합니다. Enterprise 플랜 고객은 사내 ID 제공자(Okta, Microsoft Entra ID, Google Workspace)와 SCIM 2.0 연동을 구성해야 합니다.
- Dust 콘솔에서 Admin > Organization > Members > Groups > User provisioning > Set up Directory sync로 이동합니다.
- 사용 중인 IdP를 선택하고 안내에 따라 디렉터리 동기화를 설정합니다.
- 부서별 사용자 그룹(예:
dept-finance,dept-legal,dept-people,exec-board)을 Dust로 푸시하도록 설정합니다. - 인사 이동이 발생하면 IdP 설정이 Dust에 실시간으로 반영됩니다. 직원이 Entra ID 상에서 재무팀을 벗어나는 즉시, Dust 재무 Restricted Space 및 관련 재무 에이전트에 대한 모든 접근 권한이 즉각 차단됩니다.
2단계: 전용 서비스 계정을 통한 소스 시스템 접근 범위 최소화
Dust의 데이터 커넥터(Google Drive, Microsoft SharePoint/OneDrive, Notion, Confluence, Slack)는 외부 저장소와 직접 연동됩니다. 원본 시스템에서의 데이터 과다 수집을 방지하려면 다음 수칙을 준수해야 합니다.
- 개인 관리자 계정 연동 금지: 특정 직원의 개인 업무 계정으로 커넥터를 인증하면 안 됩니다. 해당 직원의 퇴사 시 연동이 끊어질 뿐만 아니라, 개인 비공개 문서까지 인덱싱될 위험이 있습니다.
- 전용 시스템 서비스 계정 활용:
- Google Drive:
dust-admin@yourdomain.com과 같은 전용 서비스 계정을 생성하고, AI 인덱싱 대상인 공유 드라이브(Shared Drives)에 대해서만 읽기 및 다운로드 권한을 부여합니다. - Microsoft SharePoint / OneDrive: Entra ID에서
Sites.Selected애플리케이션 권한이 부여된 앱 등록을 사용하거나, 전용 서비스 계정(dust-service@yourdomain.com)을 만들어 PowerShell(Grant-PnPAzureADAppSitePermission) 또는 Microsoft Graph API를 통해 승인된 SharePoint 사이트 모음으로만 접근을 제한합니다. - Slack: Dust 봇을 전사 공개 채널이나 특정 아카이브 채널에만 초대하고, 비공개 기밀 채널에는 참여시키지 않습니다.
- Google Drive:
- 폴더 트리 단위 선택: Dust 연동 모달 창에서 최상위 루트 드라이브를 일괄 선택하지 말고, 필요한 하위 폴더만 개별 체크하여 동기화합니다.
3단계: Restricted Space 생성 및 프로비저닝 그룹 매핑
외부 데이터가 Dust로 동기화된 후에는 관리자가 특정 Space에 명시적으로 연결하기 전까지 에이전트가 이를 조회할 수 없습니다.
- Dust의 Spaces 탭에서 New를 클릭합니다.
- Space 이름을 입력합니다(예:
Finance & Accounting). - 유형으로 Restricted를 선택합니다.
- 구성원 설정에서 Provisioned group access를 선택하고, SCIM으로 동기화된 IdP 그룹(예:
dept-finance)을 지정합니다. - 생성된 Space 상세 화면에서 Connected Data로 이동한 뒤 Add data from connections를 클릭합니다.
- 데이터 선택 트리에서 해당 부서용으로 동기화한 전용 폴더나 SharePoint 라이브러리만 체크합니다.
- Save를 클릭합니다. 이제 해당 민감 데이터는 이 격리된 제한 공간 내에 안전하게 보관됩니다.
Dust 관리자 콘솔: Restricted Space 설정 화면
┌─────────────────────────────────────────────────────────────┐
│ 새 Space 생성 (Create New Space) │
│ 이름: [ Finance & Accounting ] │
│ 접근 유형: ( ) Open (공개) (•) Restricted (제한) │
│ 구성원 할당: │
│ [ Provisioned group access (IdP 그룹 연동) ▼]│
│ 할당된 그룹: [ dept-finance x ] [ exec-cfo x ] │
│ │
│ 연결 데이터 (Connected Data): │
│ [x] Google Drive: /Shared Drives/Finance/FY26_Budgets/ │
│ [x] SharePoint: /sites/FinanceOps/Financial_Statements/ │
│ [ ] Google Drive: /Shared Drives/Company_Wide/ (제외됨) │
│ │
│ [ 취소 ] [ Space 생성하기]│
└─────────────────────────────────────────────────────────────┘
4단계: 워크스페이스 역할 및 빌더 권한 통제 (RBAC)
초기 기본 설정 상태의 Dust 워크스페이스에서는 모든 구성원이 에이전트를 자유롭게 생성하고 전사에 배포할 수 있습니다. 기업 통제를 위해 Admin > Governance에서 권한을 제한해야 합니다:
- Create agents 및 Publish agents: 권한을 Everyone에서 사전 승인된 전담 조직(예: 사내 보안 교육을 이수한
AI Builders그룹) 또는 Admin only로 변경하여 비공인 에이전트의 난립을 방지합니다. - Create skills 및 Manage skill availability: 외부 도구 실행 및 API 연동을 수반하는 스킬 생성은 Admin only로 유지하여 승인되지 않은 외부 연동을 차단합니다.
- 역할 매핑: Admin > Members > Roles에서 디렉터리 그룹별로 역할을 부여합니다. 핵심 인프라 담당자에게만 Admin 역할을 부여하고, 각 부서장에게는 Manager 역할 또는 Group Managers(그룹 관리자) 권한을 부여하여 보안 설정을 변경하지 못하게 하면서 부서 내 사용량과 멤버만 관리하도록 위임합니다.
- 보안 및 결제 권한 위임 주의: 감사 로그 및 보안 설정에 접근하는 Access security features 권한은 Manager 역할에 기본 포함되지 않으므로, 정보보안팀에만 별도로 부여해야 합니다.
5단계: 부서 전용 맞춤형 에이전트 구축 및 가시성 검증
Agent Builder에서 부서 전용 에이전트를 구성할 때는 최소 권한 원칙을 엄수합니다:
- Instructions 항목에 업무 범위, 페르소나, 규정 준수 지침을 기술합니다.
- Knowledge / Tools 항목에서 Search data sources 도구를 추가합니다:
- 지식 소스로 해당 부서의 Restricted Space만 체크합니다(예:
Finance & Accounting). - 전사 사규를 함께 참조해야 하는 특수 사례가 아니라면
Company Data는 체크하지 않습니다.
- 지식 소스로 해당 부서의 Restricted Space만 체크합니다(예:
- 다중 Space 교집합 원칙(Multi-Space Intersection Rule) 숙지:
- 에이전트가 *Space A(재무)*와 *Space B(임원)*를 동시에 참조하도록 설정된 경우, 사용자가 Space A와 Space B 모두에 대한 권한을 보유하고 있어야만 해당 에이전트를 조회하고 실행할 수 있습니다.
- 한쪽 권한만 있는 사용자에게는 에이전트가 숨겨집니다.
- 모범 사례: 정당한 권한을 가진 사용자의 접근이 차단되지 않도록, 개별 업무 에이전트는 단일 Restricted Space에만 바인딩하는 설계를 권장합니다.
6단계: 외부 실행 도구의 인증 모드 설정 (Personal vs. Shared)
에이전트가 외부 시스템(GitHub, Salesforce, Jira, HubSpot, MCP 서버 등)과 실시간 연동하여 데이터를 조회하거나 작업을 수행해야 하는 경우, Knowledge > Tools에서 인증 방식을 지정합니다:
- 공유 인증 (Shared Credentials): 관리자가 등록한 공용 서비스 계정으로 모든 사용자가 도구를 호출합니다. 전사 공통 조회용 시스템에 적합합니다.
- 개인별 인증 (Personal Level Credentials): 관리자가 전역 OAuth 연결을 승인한 뒤, 사용자가 에이전트를 통해 해당 도구를 처음 호출할 때 본인의 외부 계정으로 개별 로그인합니다.
- 민감한 업무 시스템의 필수 설정: Salesforce나 GitHub 프라이빗 레포지토리처럼 사용자별 세부 권한이 적용된 시스템에 필수적입니다. 마케팅 직원이 에이전트를 통해 영업 기회를 조회하려 해도, 해당 사용자의 Salesforce 계정 권한이 적용되므로 데이터 접근이 자동 차단됩니다(이중 방어막 구축).
4. 감사 로그, 실시간 모니터링 및 퇴사자 관리
완벽한 보안 구성을 유지하려면 권한 적용 상태를 상시 감시하고 추적할 수 있는 거버넌스 체계가 필요합니다.
┌──────────────────────────────────────────────────────────────┐
│ 엔터프라이즈 실시간 이벤트 스트림 │
└──────────────────────────────┬───────────────────────────────┘
│
┌──────────────────┴──────────────────┐
▼ ▼
[ 사람의 직접 호출 ] [ AI 에이전트 파생 동작 ]
actor: "user" actor: "user"
action: "agent.executed" metadata.actor_type: "agent"
targets: ["agent-finance-01"] metadata.initiating_user: "..."
│ │
└──────────────────┬──────────────────┘
▼
[ Dust Enterprise 감사 엔진 ]
│
┌──────────────────┴──────────────────┐
▼ ▼
[ 내부 위변조 방지 콘솔 ] [ SIEM 실시간 스트리밍 ]
(Admin > Security > Audit Logs) (Datadog, Splunk, S3, GCS)
감사 로그를 통한 책임 추적: 인간과 AI의 행위 주체 분리
Dust Enterprise 감사 로그(Admin > Organization > Security > Audit Logs)는 위변조가 불가능한 시계열 기록을 제공합니다:
- 주체(Actor): 실제 행위가 사용자(
user), API 키(api_key), 자동화 프로세스(system)인지 구분하며 IP 주소와 클라이언트 정보를 기록합니다. - 수행 작업(Action):
agent.executed,space.created,space.deleted,data_source.updated,tool.executed등의 핵심 이벤트를 상세 기록합니다. - AI 행위의 인과관계 규명: 에이전트가 데이터 검색이나 외부 도구를 실행한 경우, 로그의
metadata.actor_type에"agent"로 표시되는 동시에 이를 촉발한 실제 사용자의 식별 정보(initiating_user_id및initiating_user_email)가 영구 보존됩니다. 이를 통해 사고 발생 시 완전한 소명 체계를 보장합니다.
SIEM 실시간 스트리밍 연동
엔터프라이즈 보안팀은 Dust 감사 로그를 Datadog, Splunk, AWS S3, Google Cloud Storage(GCS) 또는 자체 HTTPS 웹훅 엔드포인트로 실시간 전송할 수 있습니다. 사내 방화벽이 엄격한 경우 Dust 공식 문서에 명시된 WorkOS의 전송 IP 대역을 인바운드 허용 목록에 등록해야 합니다.
퇴사자 발생 시 권한 회수 절차
직원이 퇴사하거나 전보 조치될 때:
- 사내 IdP에서 계정이 비활성화되면 SCIM 동기화를 통해 Dust 계정이 즉각 정지됩니다.
- 모든 Restricted Space 및 부서별 에이전트에 대한 접근 권한이 그 즉시 소멸합니다.
- 해당 직원이 생성했던 개인용 자동화 트리거(Triggers)는 영구적으로 자동 삭제됩니다.
- 관리자 사전 인계 절차: 퇴사 처리 전 Programmatic Usage > Automations에서 유지해야 할 자동화 작업이 있는지 확인하고 소유자를 변경해야 합니다. 퇴사자가 단독으로 생성하고 배포하지 않은 업무 에이전트의 경우, 관리자가 Agent Builder에서 Become an editor as an admin을 클릭하여 편집 권한을 인수할 수 있습니다.
5. 아키텍처 매트릭스 및 IT 관리자 자가 점검 체크리스트
부서별 Spaces 및 권한 설계 매트릭스
| 부서 / 데이터 영역 | Space 유형 | 접근 권한 소스 | 커넥터 범위 전략 | 도구 인증 방식 | 추천 에이전트 활용 예시 |
|---|---|---|---|---|---|
| 전사 공통 지식 | Open (Company Data) | 전사 구성원 자동 참여 | 사규, 사내 인트라넷 Notion, 공용 매뉴얼 | 공유 인증 | 전사 질의응답, 신규 입사자 온보딩 (@dust) |
| 재무 및 회계 | Restricted | SCIM: dept-finance | 전용 드라이브/SharePoint 결산 폴더 | 공유 인증 (조회용) | 월간 결산 지원, 예산 집행 차이 분석 어시스턴트 |
| 법무 및 컴플라이언스 | Restricted | SCIM: dept-legal | 계약서 아카이브, 비공개 소송 서류 | 개인별 / 엄격 제한 | 계약 조항 검토, 규제 준수 실사 분석 에이전트 |
| 인사 및 노무 | Restricted | SCIM: dept-hr | 직급별 급여 테이블, 성과 평가표 | 개인별 인증 | 성과 평가 캘리브레이션 지원, 인사 공지문 작성 |
| 영업 및 고객 관리 | Restricted | SCIM: dept-sales | CRM 커넥터, 영업 제안서 라이브러리 | 개인별 인증 (OAuth) | 딜 인텔리전스, 파이프라인 요약 어시스턴트 |
| 개발 및 인프라 | Restricted / Open | SCIM: dept-eng | GitHub 토론, 아키텍처 설계 RFC | 개인별 인증 (GitHub) | 코드 아키텍처 해설, 릴리스 노트 생성 에이전트 |
배포 전 IT 관리자 자가 점검표
- 디렉터리 동기화 활성화: SCIM 2.0 연동이 정상 작동하며, Okta 또는 Entra ID의 부서 그룹이 Dust로 올바르게 푸시되고 있다.
- Company Data 무결성 검증: 전사 공개 공간에 급여 명세, 재무 추정치, 법무 상담 등 기밀 문서가 포함되어 있지 않음을 확인했다.
- 전용 서비스 계정 적용: Google Drive 및 SharePoint 연동에 개인 계정을 사용하지 않고 권한이 최소화된 전용 시스템 계정을 적용했다.
- Restricted Space 격리 완료: 민감 부서별로 전용 제한 공간을 생성하고 'Provisioned group access'를 통해 IdP 그룹을 연결했다.
- 연결 데이터의 정확한 매핑: 동기화된 중요 폴더가 해당 Restricted Space의 Connected Data에만 선별적으로 할당되었다.
- 에이전트 생성·배포 권한 회수: Admin > Governance에서 에이전트 및 스킬 생성 권한을 승인된 빌더 그룹 또는 관리자로 제한했다.
- 고권한 도구의 개인 인증 적용: Salesforce, GitHub 등 사용자별 권한이 나뉘는 도구에 Personal Level Credentials가 적용되었다.
- 감사 로그 SIEM 전송 검증: SIEM(Splunk / Datadog)으로 감사 로그가 실시간 스트리밍되는지 확인하고 테스트 알림을 검증했다.
체계적인 Dust Spaces 구조와 엄격한 RBAC 통제를 확립함으로써, IT 관리자는 기업의 핵심 기밀 데이터를 완벽하게 보호하는 동시에 안전하고 강력한 생성형 AI 환경을 전사적으로 배포할 수 있습니다.