Msty Go · 글 22편Msty Go
  1. Msty Go 시작하기 — 설치부터 첫 실행 검증까지
  2. Msty Go 에이전트 만들기와 관리
  3. Msty Go Working Styles — 다섯 가지 작업 방식 고르기
  4. Msty Go 모델 제공업체 설정과 Model Assignments
  5. Msty Go Managed Services — 로컬 AI와 부가 서비스를 앱이 대신 준비하기
  6. Msty Go 보안 설정 — 발신자, 폴더, 네트워크, 승인
  7. Msty Go Airlock — 에이전트가 접속할 웹사이트 정하기
  8. Msty Go 도구 설정 — MCP 서버, 웹 검색, Skills Hub, Computer Use
  9. Msty Go Context Scout — 보내기 전에 관련 파일 찾아 붙이기
  10. Msty Go Extensions — 확장 기능 찾기, 설치, 만들기, 공유
  11. Msty Go Mission Control — 도우미 에이전트와 승인을 한곳에서 보기
  12. Msty Go Pulse — 일을 시작하기 전에 받는 브리핑
  13. Msty Go Side Chat — 주 대화를 건드리지 않고 짧게 묻기
  14. Msty Go Memory Bank — Working Brief와 Memory Pack으로 맥락 이어 가기
  15. Msty Go 작업 공간 프로필 파일 — SOUL.md, IDENTITY.md, USER.md
  16. Msty Go Playbooks — 잘된 실행을 반복 가능한 절차로 만들기
  17. Msty Go Tasks — 프롬프트, 알림, 감시, Playbook 예약하기
  18. Msty Go Shortcuts — 자주 쓰는 지시를 슬래시 명령으로 만들기
  19. Msty Go Rules — 이벤트에 따라 안내하고, 막고, 점검하기
  20. Msty Go 채널 — Discord, Telegram, WhatsApp, 모바일로 에이전트와 주고받기
  21. Msty Go Cloud Sync — 기기 간 암호화 동기화와 휴대전화 연결
  22. Msty Go General Settings — 앱 전체 기본값 정하기

이 글에서 다루는 것Go의 Settings > Security에서 Sender Groups, Allowed Folders, Blocked Patterns, Network Guard, 승인, Rules를 겹쳐 쓰는 방법과 문서가 권하는 보안 기준을 설명합니다.

Go의 보안은 세 가지 질문이다

에이전트는 파일을 읽고 쓰고, 명령을 실행하고, 인터넷에 접속할 수 있습니다. 그래서 Go의 보안 설정은 세 가지 질문에 답하는 구조로 되어 있습니다.

  1. 누가 에이전트를 움직일 수 있는가
  2. 에이전트가 어떤 파일에 접근할 수 있는가
  3. 에이전트가 어디에 접속할 수 있는가

문서는 목표를 “쓸모 있는 작업을 막지 않으면서 안전하게 실행하는 것”이라고 적습니다. 설정 위치는 Settings > Security입니다.

제품 개요 수준의 요약은 Msty Go 자세히 보기에 있고, 이 글은 각 통제를 어떻게 쓰는지를 다룹니다.

여섯 가지 통제를 겹쳐 쓴다

통제 답하는 질문
Sender Groups 누가 에이전트와 채널 프리셋을 호출할 수 있는가
Allowed Folders 에이전트가 어디를 읽고 쓸 수 있는가
Blocked Patterns 허용된 폴더 안에서도 막아야 할 민감한 경로는 무엇인가
Network Guard 밖으로 나가는 네트워크를 어디까지 허용하는가
Approvals 위험한 행동 전에 사람의 확인을 받는가
Rules 특정 이벤트에서 안내, 차단, 후속 조치, 점검을 하는가

이 통제들은 함께 쓸 때 효과가 큽니다. 한 겹에만 의존하면 피할 수 있었던 틈이 생긴다는 것이 문서의 설명입니다. 여기에 웹사이트 단위 정책인 Airlock이 더해집니다.

Sender Groups — 누가 호출하는가

Sender Groups는 누가 무엇을 실행할 수 있는지 정합니다.

  • 재사용할 수 있는 그룹을 만듭니다. 문서의 예는 팀, 서비스 계정, 신뢰하는 운영자입니다.
  • 그룹을 에이전트와 채널 프리셋에 배정합니다.
  • Anyone은 의도적으로 열어 둔 환경에서만 씁니다.

문서의 지침은 두 가지입니다.

  • 운영용 에이전트는 기본적으로 제한해 둡니다.
  • 넓게 열린 그룹을 권한이 큰 에이전트에 재사용하지 않습니다.

에이전트가 민감한 일을 한다면 넓게 쓰기 전에 발신자 정책이 명시적이고 나중에 확인할 수 있어야 합니다. 발신자 정책은 채널을 붙일 때 특히 중요해집니다. 메신저 대화방에 있는 누구나 에이전트를 부를 수 있게 되기 때문입니다.

폴더 정책 — Allowed Folders와 Blocked Patterns

두 설정을 함께 씁니다.

  • 허용 루트는 에이전트가 일할 수 있는 경계입니다.
  • 루트마다 읽기·쓰기 또는 읽기 전용으로 정할 수 있습니다.
  • 차단 패턴은 허용 루트 안에 있는 민감한 자료를 보호합니다.

문서가 든 흔한 차단 패턴은 다음과 같습니다.

패턴 흔히 들어 있는 것
.ssh SSH 키와 설정
.gnupg GnuPG 키
.aws AWS 인증 정보
.env 환경 변수 파일
credentials 인증 정보 파일
private_key 개인 키
id_rsa, id_ed25519 SSH 개인 키 파일

오른쪽 열의 설명은 이해를 돕기 위해 필자가 붙인 것입니다. 문서는 패턴 이름만 나열합니다.

지침은 좁게 시작하는 것입니다.

  • 홈 폴더 전체가 아니라 프로젝트 폴더를 루트로 잡습니다.
  • 참고용 자료는 읽기 전용으로 둡니다.
  • 확신이 없으면 좁게 시작하고, 필요가 확인된 뒤에만 넓힙니다.

예를 들어(필자가 든 예입니다) 계약서 검토 에이전트에는 계약서-초안 폴더를 읽기·쓰기로, 법무팀-표준조항 폴더를 읽기 전용으로 열어 주고, 조직에서 쓰는 비밀 파일 이름을 차단 패턴에 추가하는 식입니다.

Network Guard — 어디로 접속하는가

프리셋은 네 가지입니다.

프리셋 문서의 안내
Recommended 여기서 시작합니다
Privacy 더 엄격한 프리셋 가운데 하나
Strict 더 엄격한 프리셋 가운데 하나
Approved Only 운영 환경용으로 단단히 잠근 방식으로 다룹니다

프리셋 외에 허용 호스트와 차단 호스트를 직접 정해 더 세밀하게 통제할 수도 있습니다.

원칙은 에이전트가 일을 끝내는 데 실제로 필요한 곳만 허용하는 것입니다. 민감한 자동화일수록 엄격한 프리셋으로 옮기고, 인터넷을 쓰는 자동화는 의존하는 서비스가 바뀔 때마다 허용·차단 호스트를 다시 검토합니다.

각 프리셋이 구체적으로 어떤 호스트를 허용하고 막는지, 설치 직후 기본값이 무엇인지는 공식 문서에 설명이 없습니다.

Airlock과의 관계

Airlock은 에이전트의 네트워크 접근에 웹사이트 단위 정책을 더합니다. 호스트 수준에서 허용과 차단을 명시해야 할 때 씁니다.

  • 웹을 쓰는 에이전트를 승인된 도메인으로 제한합니다.
  • 네트워크가 켜져 있어도 위험한 호스트를 막습니다.
  • 나가는 접근 정책을 에이전트 사이에서 반복 적용하고 점검할 수 있게 합니다.

컨테이너로 실행하는 에이전트와 함께, 정책을 먼저 좁게 잡고 넓혀 갈 때 효과가 가장 큽니다. 설정 방법은 Airlock에 있습니다.

Approvals — 승인

Go는 민감한 행동을 하기 전에 승인을 요청할 수 있습니다. 정책이 안정되고 실제 업무에서 시험될 때까지 승인을 켜 두라고 문서는 권합니다.

승인을 조정하는 순서는 이렇습니다.

  1. 도입 기간에 뜨는 승인 요청을 살펴봅니다.
  2. 에이전트의 범위와 권한을 조정합니다.
  3. 다시 실행해 불필요한 요청이 줄었는지 확인합니다.

승인을 끄는 것이 아니라, 범위를 맞게 잡아 불필요한 요청을 줄이는 방향입니다. 여러 도우미가 올리는 승인 요청은 Mission Control에서 모아 처리합니다.

어떤 행동이 승인 대상인지의 전체 목록은 공식 문서에 설명이 없습니다.

Rules를 안전장치로 쓰기

Rules는 대화와 도구 사용에 이벤트 기반 통제를 더합니다. 문서의 보안 관련 예는 네 가지입니다.

  • 위험한 셸 명령을 운영자가 검토할 때까지 막기
  • 배포나 운영 환경 변경에 해당하는 프롬프트 앞에 안내 덧붙이기
  • 파일 수정 뒤 후속 검토 요청하기
  • 해당 작업이 끝난 뒤 범위가 좁은 검증 명령 실행하기

중요한 단서가 있습니다. Rules는 승인과 폴더·네트워크 정책을 보완할 뿐, 강제 보안 통제를 대신하지 못합니다. 자동으로 명령을 실행하는 규칙은 범위를 좁게 잡아야 합니다. 만드는 방법은 Rules에 있습니다.

문서가 제시하는 보안 기준

  1. 공유 채널을 켜기 전에 Sender Groups를 제한합니다.
  2. 에이전트마다 프로젝트 폴더로만 접근을 한정합니다.
  3. 조직 고유의 민감한 패턴을 차단 목록에 추가합니다.
  4. 운영용 에이전트에는 보수적인 Network Guard 프리셋을 씁니다.
  5. 인터넷을 쓰는 컨테이너 에이전트에는 Airlock을 설정합니다.
  6. 반복되는 위험 패턴에는 Rules를 더합니다.
  7. 위험이 큰 기능에는 승인 요청을 켜 둡니다.

이 기준은 의도적으로 보수적입니다. 실제 업무에서 안전한 동작이 반복해서 확인된 뒤에만 통제를 풉니다.

알아 둘 점

  • 문서는 각 통제의 기본값을 밝히지 않습니다. 설치 뒤 Settings > Security에서 직접 확인해야 합니다.
  • 감사 기록을 내보내는 기능이 있는지는 이 문서 페이지에 설명이 없습니다. Airlock 문서는 승인 기록과 활동 기록에서 정책의 효과를 확인하라고만 적습니다.

참고한 문서