처음 에이전트를 붙이면 현장은 두 번 놀란다. 한 번은 생각보다 일을 잘해서 놀라고, 다음은 너무 쉽게 위험한 행동까지 이어가서 놀란다. 그래서 많은 조직이 극단으로 간다. 모든 실행을 막거나, 반대로 개발 편의를 이유로 거의 모든 권한을 열어둔다. 둘 다 운영 설계가 아니다.
에이전트 하네스에서 권한은 부가 설정이 아니다. 모델이 어디까지 혼자 움직이고, 어디서 사람에게 멈춰 서야 하는지를 정하는 운영 경계다.
권한은 보안 옵션이 아니라 제품 설계다
에이전트가 실패하는 지점은 대개 답변 품질보다 실행 경계다. 읽기, 수정, 실행, 외부 전송, 결제, 배포는 같은 “tool call”이 아니다. 조직의 손실 가능성이 다르다.
Claude Code 문서는 권한을 읽기 전용, Bash 실행, 파일 수정처럼 계층화하고, allow·ask·deny 규칙을 순서대로 평가한다고 설명한다. default, acceptEdits, plan, dontAsk, bypassPermissions 같은 permission mode도 같은 맥락이다. 모드는 UX 설정이 아니라 운영 위험의 기본값이다.
에이전트 자율성은 “얼마나 똑똑한가”가 아니라 “어떤 행동을 자동으로 허용했는가”로 결정된다.
따라서 권한 설계는 보안팀 사후 검토가 아니라 제품 요구사항에 들어가야 한다. 상담 에이전트, 개발 에이전트, 구매 에이전트, 운영 모니터링 에이전트는 처음부터 다른 권한 표면을 가져야 한다.
allowlist는 편의 목록이 아니라 반복 업무의 계약이다
allowlist를 넓게 잡으면 데모는 빨라진다. 운영은 느려진다. 사고가 나면 다시 전체 권한을 닫게 되고, 현장은 에이전트를 우회한다.
좋은 allowlist는 “자주 쓰는 안전한 명령”의 모음이 아니다. 반복 업무에서 자동 실행해도 되는 행동의 계약이다.
| 권한 계층 | 자동화 기준 | 예시 판단 |
|---|---|---|
| 읽기 | 손실이 없고 감사 가능 | 파일 조회, 검색, 로그 읽기 |
| 제한 실행 | 결과가 되돌릴 수 있음 | 테스트, lint, dry-run |
| 변경 | 범위가 좁고 diff 검토 가능 | 작업 디렉토리 내 파일 수정 |
| 외부 영향 | 사람 승인 필요 | 배포, 결제, 고객 발송 |
| 파괴적 행동 | 기본 거부 | 삭제, 권한 변경, 대량 전송 |
여기서 중요한 것은 명령 문자열만 믿지 않는 것이다. Claude Code 권한 문서는 Bash 패턴이 URL, 리다이렉트, 변수, 옵션 조합으로 우회될 수 있음을 지적한다. 그래서 네트워크, 파일시스템, 비밀정보, 배포 권한은 문자열 allowlist만으로 끝내지 않는다. 별도 hook, proxy, sandbox, 정책 엔진으로 한 번 더 잡아야 한다.
승인 게이트는 사람을 끼워 넣는 장치가 아니다
승인 게이트를 “민감하면 사람에게 물어본다”로 설계하면 곧 실패한다. 승인 피로가 생기고, 관리자는 습관적으로 승인한다. 게이트는 멈춤 버튼이 아니라 판단 정보를 표준화하는 장치다.
OpenAI Agents SDK의 HITL 문서는 tool call이 승인 필요 상태가 되면 실행을 멈추고, interruption을 반환한 뒤, RunState를 저장하고 승인 또는 거절 후 재개하는 흐름을 제시한다. 이 구조의 핵심은 사람이 채팅창에서 즉흥적으로 판단하는 것이 아니다. 어떤 tool, 어떤 인자, 어떤 업무 맥락, 어떤 변경 diff를 보고 승인할지 고정하는 것이다.
승인 게이트에는 세 가지가 필요하다.
- 승인자가 보는 입력: tool 이름, 인자, 대상 시스템, 예상 변경
- 승인 결과의 범위: 이번 call만 승인할지, 같은 run 동안 반복 승인할지
- 거절 메시지: 모델이 대체 경로를 찾을 수 있을 만큼 구체적인 사유
이 세 가지가 없으면 게이트는 통제가 아니라 병목이다.
MCP 시대에는 권한 경계가 더 바깥으로 간다
MCP는 에이전트가 외부 도구와 데이터에 붙는 표준 인터페이스가 됐다. 2025-11-25 MCP authorization specification은 보호된 MCP 서버를 OAuth 2.1 resource server로 보고, Protected Resource Metadata와 scope 기반 요청을 요구한다. 의미는 분명하다. 하네스 내부 allowlist만으로는 부족하다. 서버 쪽 scope, 토큰, resource indicator까지 함께 설계해야 한다.
AX Ops에서는 권한을 세 겹으로 본다.
- 모드: 이 업무는 기본적으로 계획만 하는가, 수정까지 하는가
- 목록: 어떤 tool과 인자를 자동 허용·질문·거부하는가
- 게이트: 어떤 순간에 누구의 승인과 어떤 기록을 남기는가
이 세 겹이 맞으면 에이전트는 더 많이 움직인다. 반대로 권한을 뭉뚱그리면 조직은 “안전해서 느린 에이전트”와 “빠르지만 못 쓰는 에이전트” 사이를 오간다.
참고
- Anthropic, Claude Code IAM / permissions, accessed 2026-07-20: https://code.claude.com/docs/en/iam
- Anthropic, Claude Code Hooks reference, accessed 2026-07-20: https://code.claude.com/docs/en/hooks
- OpenAI, Agents SDK Human-in-the-loop, accessed 2026-07-20: https://openai.github.io/openai-agents-python/human_in_the_loop/
- Model Context Protocol, Authorization specification 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
권한 설계는 나중에 잠그는 일이 아니라 처음부터 운영 속도를 정하는 일이다. 업무별 하네스를 함께 설계하려면 AX Ops 방법론 →
