참고자료 · Security

하네스 보안과 가드레일

좋은 하네스는 모델이 똑똑한지보다 먼저, 위험한 행동을 어떻게 제한하는지 설명해야 합니다. 이 페이지는 agentic coding에서 실제로 중요한 보안 경계를 sandbox, rules, hooks, MCP governance 네 층으로 나눠 설명합니다.

1. Sandbox는 가장 바깥 경계입니다

sandbox는 런타임이 어느 범위까지 파일을 읽고 쓰고 시스템에 접근할 수 있는지 정합니다. 일반적인 코딩 저장소에서는workspace-write 가 가장 현실적입니다. 읽기 전용 분석은 read-only, 완전 개방은 정말 예외적인 경우만 허용해야 합니다.

2. Rules는 선언형 정책입니다

Rules는 “무엇이 금지인지”, “무엇이 승인 대상인지”를 문서가 아니라 실행 정책으로 고정합니다. destructive command, 배포, 외부 쓰기, 모델 삭제 같은 명령은 rules에 먼저 걸어 두는 편이 좋습니다.

prefix_rule(["git", "reset", "--hard"], "forbidden")
prefix_rule(["rm", "-rf"], "forbidden")
prefix_rule(["terraform", "destroy"], "forbidden")
prefix_rule(["kubectl", "delete"], "forbidden")
prefix_rule(["git", "push"], "prompt")
prefix_rule(["gh", "pr", "create"], "prompt")

3. Hooks는 실행 순간의 guardrail입니다

Hooks는 보안 경계의 전부가 아니라, 실행 시점의 빠른 차단기입니다. 예를 들어 위험한 bash를 실행 직전에 막고, Kotlin 파일 수정 직후 자동 lint를 돌리는 식입니다.

4. MCP는 연결 자체가 권한입니다

MCP를 붙인다는 것은 모델에게 새로운 도구와 데이터 접근권을 주는 것입니다. 그래서 조직 수준에서는 “어떤 MCP 서버를 허용할 것인가”, “누가 추가할 수 있는가”, “registry를 어떻게 운영할 것인가”가 중요합니다. GitHub 문서도 조직/엔터프라이즈 단위 MCP registry 관리 문서를 별도로 둡니다.

5. 실무 체크리스트

• 기본 sandbox는 `workspace-write + on-request` 에서 시작
• destructive command 는 rules에서 먼저 금지
• 빠른 차단은 PreToolUse hook 로 보조
• MCP는 업무 가치가 분명한 것만 allowlist 기반으로 추가
• 새로운 MCP는 팀 공통 설정에 넣기 전에 별도 검증

6. 더 깊게 들어가려면

이 페이지는 기본 수준의 보안 경계를 다룹니다. 실제 플러그인 보안 사고를 가정하고 4계층 방어 원칙을 훨씬 자세히 정리한 새 페이지들이 있으니, 운영 환경을 만들 때는 함께 봐 주십시오.

7. 이어서 볼 기본 자료