**기본 상태는 제로 공유(Zero sharing by default)**라는 말은 에이전트의 소유자가 공유하기로 구체적으로 결정하기 전까지는 에이전트, 컴퓨터, 룸에 관한 어떤 것도 다른 사람이 보거나 사용할 수 없으며, 모든 공유 결정은 범위가 지정되고 기록되며 되돌릴 수 있어야 한다는 뜻입니다. 이것이 muti를 관통하는 단 하나의 원칙입니다. 독립된 보안 규칙처럼 보이는 다른 모든 것은 이 원칙에서 파생된 결과입니다.
이러한 결과들을 명문화해 두는 것은 유용합니다. 각각의 결과가 자칫 유혹에 빠지기 쉬운 손쉬운 지름길들을 차단해 주기 때문입니다.
맨 위의 원칙과 그 아래에 있는 결과로서의 다섯 가지 규칙.
결과 1: 룸이 곧 경계입니다
룸과 룸 사이에는 아무것도 건너가지 않습니다. 두 룸에 속한 에이전트라도 한 룸의 기억, 메시지, 결과물을 다른 룸으로 가져가지 않습니다. 한 룸에 있는 사람은 다른 룸이 존재한다는 사실조차 알 수 없습니다. 정보가 옆으로 새어 나갈 수 있는 룸 상위 레벨의 '워크스페이스' 개념은 존재하지 않습니다.
금지되는 것: 전역 에이전트 디렉터리, 룸 간 검색, 다른 룸의 존재를 드러내는 '최근 활동' 목록.
결과 2: 멘션은 아무런 권한도 부여하지 않습니다
@agent는 에이전트의 받은 편지함으로 메시지를 전달할 뿐입니다. 에이전트가 실제로 실행될지는 상시 권한 부여나 소유자의 승인 여부에 달려 있습니다. 룸에 있거나, 멘션되었거나, 스레드에서 가장 말을 많이 하는 사람이라고 해서 어떤 권한도 주어지지 않습니다.
금지되는 것: 채널 멤버십 기반의 권한 모델, '룸에 있는 누구나 실행 가능' 기본값. Claude Code Dispatch와 룸의 차이를 참고하세요.
결과 3: 자격 증명은 컴퓨터 밖으로 절대 나가지 않습니다
daemon은 타임라인 이벤트를 업로드할 뿐, 파일이나 환경을 업로드하지 않습니다. 로그인, 2단계 인증 코드, 키 접근은 항상 소유자에게 전달되며, 프롬프트를 유발한 요청자일지라도 요청자에게는 절대 전달되지 않습니다. muti 자체 클라우드를 포함해 그 어떤 곳으로도 비밀 정보를 복사하는 기능은 없습니다.
금지되는 것: 호스팅 런타임, 룸 내 자격 증명 보관함, '여기에 token 붙여넣기' 방식. daemon이 업로드하는 항목을 참고하세요.
결과 4: 네 가지 작업은 항상 일시 정지됩니다
공유 브랜치로의 push, 삭제, 비용 지출, 자격 증명 접근은 타인의 요청일 경우 전적인 신뢰를 포함한 모든 권한 템플릿에서 항상 소유자의 확인을 거칩니다. 어떤 템플릿으로도 이 동작을 끌 수 없습니다. 템플릿 자체가 공유 결정이며, 원칙상 되돌릴 수 없는 작업에 대한 공유 결정은 작업별로 명시적이어야 하기 때문입니다.
금지되는 것: '완전 신뢰' 모드, 빌려 쓰는 사람의 조용한 push. 에이전트가 실행하기 전에 항상 물어봐야 하는 네 가지 작업을 참고하세요.
결과 5: 채팅 입력은 신뢰할 수 없습니다
Feishu, Slack 또는 모든 커넥터에서 오는 메시지는 데이터일 뿐입니다. 요청을 생성할 수는 있지만 권한을 생성할 수는 없습니다. 신원은 표시 이름이 아닌 muti 계정에 바인딩됩니다. Slack의 경우 워크스페이스에서 인증한 이메일을 기준으로 하며 일회용 연결 코드를 대체 수단으로 사용하여 권한이 계정에 귀속되도록 합니다.
금지되는 것: 바인딩되지 않은 사용자에 대한 실행, 채팅 플랫폼의 관리자 개념 신뢰.
결과 6: 취소는 즉각적이며 완전합니다
권한 취소, 멤버 제거, 컴퓨터 취소, daemon 중지는 즉시 적용됩니다. 영향을 받는 사람이 대기열에 넣어 둔 요청은 취소되며, 실행 중이던 작업은 완료되어 기록에 공백이 생기지 않도록 히스토리에 남습니다.
금지되는 것: 유예 기간, '제거 대기 중' 상태, 취소 시 히스토리 삭제.
결과 7: 기록은 추가만 가능하며 소유자가 보관합니다
모든 요청과 모든 승인은 소유자가 내보낼 수 있고 아무도 수정할 수 없는 한 줄의 로그를 생성합니다. 소유자 자신의 작업도 함께 기록됩니다. 외부인의 활동만 남긴 기록은 반쪽짜리 기록에 불과하기 때문입니다.
금지되는 것: 수정 가능한 로그, 요청자가 보관하는 로그, 로깅 제외 옵션. 감사 로그에 반드시 기록되어야 하는 것을 참고하세요.
이 원칙이 수반하는 대가
이로 인해 세 가지 부분에서 편의성을 양보해야 하며, 우리는 이 셋을 모두 받아들입니다.
- 전역 '아무 에이전트에 질문하기' 입력창이 없습니다. 반드시 룸 안에 있어야 합니다.
- 신뢰하는 사람에게도 가끔 프롬프트가 뜹니다. 네 가지 작업은 평소에 승인했을 만한 작업이라도 매번 확인을 거칩니다.
- 호스팅 런타임이 없습니다. 컴퓨터 절전 모드 문제를 완전히 없앨 수 있음에도 제공하지 않습니다. 대신 받은 편지함이 그 해답입니다. 에이전트 받은 편지함을 참고하세요.
자주 묻는 질문
'기본 상태는 제로 공유'라는 것은 그냥 설정 중 하나 아닌가요? 소유자가 선택한 것 이상으로 공유될 수 있는 설정 자체가 없다는 뜻입니다. 모든 공유 행위는 명시적인 권한 부여, 승인, 또는 초대이며 각각 모두 기록됩니다.
소유자는 모든 것을 평생 계속 승인해야 하나요? 아닙니다. 신뢰하는 사람에 대해서는 상시 권한을 부여해 요청별 승인 과정을 생략할 수 있습니다. 단, 네 가지 작업은 여전히 일시 정지됩니다. 이 부분만은 위임할 수 없습니다.
소유자가 에이전트를 직접 사용할 때는 어떻게 되나요? 소유자는 자신의 에이전트를 쓸 때 승인 절차를 거치지 않지만, 타인의 요청과 동일하게 로그는 기록됩니다. 이 원칙은 공유에 관한 것이지, 소유자가 자신의 컴퓨터에 접근하는 것에 관한 것이 아닙니다.
하나의 원칙, 일곱 가지 결과, 그리고 하나의 제품. 당신의 에이전트에게 룸을 마련해 주세요.
게시일