서론

최소 권한의 원칙을 지키자.

최근 GitHub Actions 위에서 Claude Code를 구동하는 워크플로우를 만들었습니다. 특정 웹사이트를 주기적으로 체크하여, 관심 있는 장르의 정보만 추출하고, 이를 보고서로 정리하여 GitHub에 커밋해주는 간단한 자동화입니다.

직접 만드는 것 자체는 몇 시간 만에 끝났습니다. 하지만 완성된 것을 검토하던 중, '이거 은근히 위험한 구성 아닌가'라는 생각이 들었던 순간이 있어 그 이야기를 쓰고자 합니다.

누가 설계했나

먼저 고백하자면, 이 워크플로우와 프롬프트 모두 제가 처음부터 설계한 것은 아닙니다. Claude Code에게 '이런 자동화를 만들고 싶다'고 전달했고, 구현부터 GitHub Actions의 워크플로우 구성까지 거의 통째로 맡겼습니다. 소위 바이브 코딩(vibe coding)입니다.

처음에 나온 구성은 이렇습니다.

처음 나왔던 구성

jobs:
report:
steps:
...

돌아가게는 합니다. 실제로 첫 실행 때는 제대로 보고서가 완성되었습니다.

하지만 완성된 워크플로우의 YAML을 보면서 '이거 인간의 확인 없이 git push까지 자동화해도 정말 괜찮은 걸까'라는 의문이 들었습니다.

무엇에 걸렸나

Claude Code와 함께 그 불안감을 깊이 파고들자, 이 에이전트는 다음 세 가지 조건을 동시에 충족하고 있었습니다.

• 자율적으로 작동함: 사람이 일일이 확인하지 않아도 스케줄 실행 시마다 자동으로 git push까지 수행함
• 쓰기 및 실행 권한을 가짐: Bash 툴로 git 조작이 가능함
• 신뢰할 수 없는 외부 콘텐츠에 접촉함
  [1]: WebFetch로 가져오는 외부 사이트의 내용은 우리가 완전히 통제할 수 있는 것이 아님

이 세 가지가 갖춰지면 무슨 일이 벌어질까요? 만약 외부 사이트에 우연히(혹은 악의적으로) 에이전트에게 지시처럼 읽힐 문자열이 섞여 있다면, 그대로 Bash를 통해 임의의 명령을 실행하거나 의도하지 않은 내용을 push할 위험이 원리적으로 성립해 버립니다.

이는 OWASP가 LLM 애플리케이션의 대표적인 위험으로 언급하는 'Excessive Agency(과잉 에이전시)' (LLM06:2025)와 거의 같은 구조입니다. ①과 ②는 Excessive Agency의 근본 원인인 '과도한 자율성', '과도한 권한' 그 자체이며, ③은 여기에 악용되는 간접 프롬프트 인젝션(indirect prompt injection)의 진입점입니다.

어떻게 고쳤나

방침은 간단했습니다. 에이전트 자신으로부터 Bash와 Write 권한을 완전히 박탈하는 것이었습니다.

• 에이전트의 최종 출력은 자유로운 텍스트가 아닌, JSON Schema로 타입을 고정한 구조화된 데이터만으로 제한함
• 실제 파일 쓰기 및 git commit/push는 에이전트와 분리된, AI를 거치지 않는 결정적인 쉘 스크립트 단계가 담당하게 함

워크플로우의 이미지는 이렇습니다.

jobs:
report:
steps:
...

핵심은 에이전트가 장악당하더라도 할 수 있는 것은 '이상한 텍스트를 반환'하는 것까지로 제한하고, 명령어 실행이나 push 자체는 불가능하게 만든 것입니다. 실제로 파일을 쓰거나 git을 조작하는 것은 AI의 판단을 거치지 않는 일반 스크립트이므로, 외부 콘텐츠에서 유래된 지시가 그대로 명령어 실행으로 이어지는 경로 자체가 사라집니다.

덧붙여 세부적인 최소 권한도 추가했습니다.

• WebFetch는 대상 도메인으로만 제한함 (다른 사이트에 멋대로 접근할 수 없게 함)
• Read는 상태 관리용 1개 파일로만 제한함 (리포지토리의 다른 파일을 읽게 하지 않음)

맺음말

이번 일을 통해 전하고 싶은 것은 단 하나입니다.

에이전트에게 '자율적으로 작동하는 능력', '쓰기/실행 권한', 그리고 '신뢰할 수 없는 외부 콘텐츠' 세 가지를 동시에 부여할 때는, 한 번 멈춰서 생각해보는 것이 좋다는 것입니다.

이는 Claude Code나 GitHub Actions만의 이야기가 아닙니다. 브라우저 조작 계열의 AI 에이전트든, 다른 AI 에이전트 서비스든, 이 세 조건이 갖춰지면 같은 형태의 구멍이 생길 수 있습니다. 만약 자신이 사용하고 있는 AI 에이전트가 이 세 조건을 충족한다면, 쓰기/실행 권한을 정말 필요한 만큼만 좁힐 수 있는지 한 번 확인해 볼 가치가 있다고 생각합니다.

다시 한번 강조하지만, 최소 권한의 원칙을 지킵시다.

• 대상 사이트의 평판과는 관계가 없습니다. 관공서 사이트와 같이 신뢰할 수 있는 도메인이라 하더라도, CMS (콘텐츠 관리 시스템)의 취약점, 외부 단체의 게시 권한, 임베디드 위젯 (embedded widget) 등을 경유하여 페이지의 내용이 발신자의 의도와 다른 형태로 변해버리는 일은 어떤 사이트에서든 일어날 수 있습니다. 도메인을 좁히더라도 그 도메인의 내용물까지는 완전히 제어할 수 없다는 것이 여기서 말하는 "신뢰할 수 없다"는 의미입니다. ↩︎

Discussion