보안 모델
Multica 작업이 실행 머신에서 접근할 수 있는 범위와 실제 격리 경계가 어디인지 설명합니다.
에이전트가 작업을 맡으면 데몬은 AI 코딩 도구(Codex, Claude Code 등)를 자식 프로세스로 실행합니다. 이 프로세스가 무엇에 접근할 수 있는지 이해하는 것이 보안 모델의 전부입니다.
경계는 데몬을 실행하는 사용자
기본적으로 작업은 데몬을 실행하는 운영체제 사용자의 모든 권한으로 동작합니다. 해당 사용자가 읽고 쓸 수 있는 파일은 모두 읽고 쓸 수 있으며, 그 사용자의 자격 증명을 사용할 수 있고, 네트워크에도 제한 없이 접근합니다.
Multica는 파일 시스템 샌드박스를 보장하지 않습니다. 현재 예외는 하나뿐으로, Windows에서 Codex의 네이티브 샌드박스를 명시적으로 활성화한 경우입니다. 게다가 어떤 플랫폼과 설정 조합에서 샌드박스가 적용되는지는 도구 버전에 따라 달라지는 호환성 세부사항입니다. 모든 작업을 샌드박스가 없는 것으로 간주하고, 경계는 데몬 바깥에 두세요.
Multica는 파일 시스템 샌드박스를 제공하지 않습니다. 데몬을 개인 계정으로 실행 중이라면 작업이 SSH 키를 읽고, 셸 설정을 수정하고, 문서를 삭제할 수 있습니다. 격리는 데몬 바깥에 직접 마련해야 합니다.
이는 의도된 설계입니다. 에이전트는 의존성 설치, 빌드 실행, 클라우드 CLI 사용을 요구받으며, 이런 도구들은 정상적인 홈 디렉터리를 전제로 동작합니다. 불완전한 파일 시스템 샌드박스는 이런 작업을 진단하기 어려운 방식으로 망가뜨립니다(도구가 "로그인되지 않음"이라고 하거나, 조용히 잘못된 계정을 사용). 그러면서도 정작 가장 중요한 것은 보호하지 못합니다. 작업이 자격 증명을 읽어 네트워크로 내보내는 것은 막을 수 없기 때문입니다.
그래서 Multica는 스스로를 경계라고 주장하지 않습니다. 바깥에 경계를 두세요.
권장 구성
인프라에 맞는 것을 선택하세요. 가벼운 순서대로 나열했습니다:
- 전용 Unix 사용자.
multica사용자를 만들고 에이전트에 필요한 저장소와 자격 증명만 부여한 뒤 그 사용자로 데몬을 실행합니다. 본인 계정은 영향을 받지 않습니다. - 컨테이너. 필요한 마운트와 시크릿만 제공한 컨테이너에서 데몬을 실행합니다.
- 가상 머신. 가장 강력한 격리이지만 머신을 따로 준비해야 합니다.
어떤 방식을 선택하든, 그 환경에서 접근 가능한 자격 증명은 에이전트가 사용할 수 있는 자격 증명으로 간주하세요. 토큰 권한은 최소로 좁히고, 개인 SSH 키 대신 용도별 배포 키를 사용하며, 무관한 프로덕션 자격 증명을 해당 사용자의 홈에 남겨두지 마세요.
Multica가 실제로 격리하는 것
아래는 실제로 존재하는 격리이지만 편의성과 영향 범위 축소를 위한 것이며, 능동적으로 탈출을 시도하는 작업에 대한 보안 경계는 아닙니다:
- 작업별 작업 디렉터리. 각 작업은
~/multica_workspaces/아래에 전용 workdir를 가지므로 동시 실행 작업이 같은 체크아웃에서 충돌하지 않습니다. - 작업별 에이전트 상태. Codex 작업은 설정, 세션, 스킬을 담는 작업 범위
CODEX_HOME을 가지므로~/.codex/를 오염시키지 않습니다. - 작업 범위 API 토큰. 작업에 전달되는
MULTICA_TOKEN은 서버가 해당 에이전트와 작업에 바인딩하므로, 작업이 Multica API에서 사용자나 다른 에이전트로 행세할 수 없습니다.
경계가 아닌 것
- 코딩 도구 자체의 샌드박스와 승인 설정. Multica는 에이전트를 무인으로 실행하므로 승인 요청은 자동 응답됩니다. 기본 경로에서는 파일 시스템 샌드박스도 꺼져 있어 Codex는
sandbox_mode = "danger-full-access", Claude Code는--permission-mode bypassPermissions로 동작합니다. 예외는 Windows입니다. Codex의 네이티브 샌드박스(windows.sandbox = "unelevated"또는"elevated")를 명시적으로 설정하면 Multica는 그 옵트인을 존중해 해당 작업에workspace-write를 유지합니다. 적용 가능한 환경에서는 권장하지만, 한 플랫폼의 한 도구에 국한된 이야기이며 데몬 사용자의 권한을 얼마나 좁혀야 하는지는 달라지지 않습니다. HOME디렉터리 구성. 작업은 데몬 사용자의 실제HOME과XDG_*변수를 그대로 상속합니다. 덕분에gh,aws,kubectl,gcloud,glab같은 호스트 CLI가 셸에서와 동일하게 작업 안에서도 동작합니다. 동시에 그 홈 아래의 모든 것에 접근할 수 있다는 뜻이기도 합니다.
Linux에서 Codex 작업은 이전에 workspace-write 샌드박스와 작업별로 리디렉션된 HOME 아래에서 실행되었습니다. 이 방식은 제거되었습니다. 호스트 CLI가 작업 안에서 미설정 상태가 되는 데다, 쓰기만 제한했기 때문에 자격 증명을 읽어 유출하는 것은 애초에 막지 못했기 때문입니다. 이제 Linux는 macOS 및 Windows의 기본 동작과 같습니다.
작업이 실제 어떤 모드로 실행되었는지 확인하기
작업이 샌드박스 없이 시작되면 데몬이 warn 레벨 로그를 남깁니다:
multica daemon logs --lines 200 | grep "codex sandbox"Codex의 실제 적용 설정을 확인하려면 해당 작업의 CODEX_HOME 아래 config.toml에 있는 관리 블록을 보세요. # BEGIN multica-managed와 # END multica-managed 사이의 내용은 실행할 때마다 데몬이 작성합니다.