토큰에는 작업 목적도 세션도 없습니다. 부여된 범위만으로 명령이 안전한지 판단할 수는 없습니다.
CI/CD 파이프라인의 토큰이 사람 승인을 기다리지 않는 것은 정상입니다. 문제는 토큰의 범위가 지나치게 넓어질 때 생깁니다. 여러 서버에 접근해야 하는 빌드 러너에는 처음 만들 때 넓은 권한을 주고, 이후 줄이지 않는 경우가 많습니다. 이 상태에서는 위험한 명령 하나가 큰 피해로 이어질 수 있습니다. 많은 접근 제어 모델은 명령이 허용 목록에 있는지만 확인합니다. 지금 이 명령이 이 상황에서 위험한지는 따로 판단하지 않습니다.
호출자에게 이 동작이 허용되는지와 명령 자체가 위험한지는 다른 질문입니다. 토큰에도 두 질문을 나눠 적용해야 합니다. 아래 2026년 사례는 이 문제가 그대로 나타난 사건은 아닙니다. 대신 범위가 넓은 토큰이 탈취되거나 공격자 입력에 속으면 피해가 어디까지 커질 수 있는지 보여 줍니다.
토큰에는 명령을 판단할 맥락이 없습니다
세션으로 작업하는 사람에게는 작업 목적이 있습니다. Work Session을 왜 열었는지 남아 있기 때문입니다. 토큰에는 이런 맥락이 없습니다. 생성 시점에 정한 범위만 있을 뿐, 명령을 판단할 다른 근거가 없습니다. 서비스 토큰의 명령 허용 목록이 *라고 해봅시다. 여러 서버에 접근해야 하는 빌드 러너에서 드문 설정은 아닙니다. ACL 검사는 통과하고 명령은 실행됩니다. sudo rm -rf /도 마찬가지입니다. ACL만 있는 모델은 이를 막지 못합니다. ACL은 명령 내용을 평가하도록 설계된 것이 아니라, 호출자가 해당 범주의 동작을 시도할 권한이 있는지만 보기 때문입니다. 생성 시점의 ACL이 넓다면 그 자체로는 안전장치 역할을 하지 못합니다.
이는 가정이 아닙니다. 최근 몇 달 사이 나온 세 사례가 범위가 넓은 토큰이 공격자에게 어떤 가치를 주는지 보여 줍니다.
- Claude Code의 GitHub Actions 연동 결함에서는 공격자가 별도 권한 없이 자신의 GitHub App을 등록할 수 있었습니다. 설치 토큰으로 이슈를 열자 에이전트는 이슈 텍스트를 지시로 취급했습니다. 공격자는 러너 환경을 읽고 OIDC 자격증명을 훔친 뒤, 저장소 쓰기 권한이 있는 토큰을 발급받을 수 있었습니다. Anthropic은 2026년 1월 신고 접수 후 나흘 만에 권한 검사 우회를 막았고, 4월까지 추가 방어 조치를 배포했습니다. 이 사실은 6월에 공개됐습니다. 신뢰된 워크플로 컨텍스트와 신뢰할 수 없는 입력을 구분하지 못한 문제는 패치된 버그 하나에 그치지 않습니다. (flatt.tech)
- 2026년 3월 LiteLLM 공급망 공격은 탈취되거나 유출된 빌드 토큰의 도달 범위를 보여 줍니다. TeamPCP의 소행으로 지목된 이 공격은 업스트림에서 시작됐습니다. 공격자는 보안 스캐너 Trivy를 먼저 침해했고, 오염된 빌드는 LiteLLM 파이프라인으로 흘러 들어갔습니다. CloudSEK이 재구성한 노출 범위 데이터셋에 따르면 2,500개 이상의 기업과 약 43만 4,000개의 CI/CD 파이프라인이 영향권에 있었습니다. 오염된 릴리스는 빌드 러너에서 SSH 키, 클라우드 자격증명, Kubernetes 토큰, AI 제공사 키를 수집하도록 만들어져 있었습니다. (CloudSEK)
- 2026년 8월 GitGuardian은 공개된 GitHub 커밋에서 1,255개 호스트네임에 걸쳐 노출된 n8n 자격증명 4,576건을 발견했습니다. 접근 가능한 896개 인스턴스를 시험한 결과, 36%가 유출된 토큰을 하나 이상 받아들였습니다. 이 토큰으로 워크플로 정의를 읽고 저장된 자격증명을 재사용할 수 있었습니다. 조작한 워크플로를 이용하면 실제 자격증명 값도 추출할 수 있었습니다. (The Hacker News)
세 사례 가운데 범위가 넓은 토큰이 위험 검사를 통과해 명령을 실행한 경우는 없습니다. 이 실패 방식이 아직 크게 알려지지 않았기 때문에, 접근 제어 모델도 이 질문을 확인하지 않은 채 출시됩니다. 세 사례가 보여 주는 것은 토큰의 도달 범위입니다. 토큰이 탈취되거나 공격자가 심은 입력을 따르게 되면, 피해는 토큰에 허용된 범위만큼 커집니다. Claude Code 사례가 가장 가깝습니다. 신뢰할 행위자를 가르는 인가 검사가 실패했고, 1월의 수정도 인가 검사였습니다. GitHub App은 기본적으로 더는 워크플로를 실행시키지 않습니다. LiteLLM과 n8n은 유출·탈취된 토큰이 허용 범위 안에서 움직인 경우이며, 명령 판단은 개입하지 않았습니다.
도달 범위를 줄이려면 권한 범위를 좁혀야 합니다. 코딩 에이전트의 토큰에는 GitHub와 Linear 접근 권한만 주고, 운영 에이전트의 토큰에는 AWS 접근 권한만 주는 방식입니다. 올바른 방향이지만 와일드카드 ACL 문제까지 해결하지는 못합니다. 좁힌 ACL도 여전히 ACL입니다. 호출자가 이 동작을 시도할 수 있는지는 답하지만, 특정 명령이 위험한지는 답하지 못합니다.
인가와 위험은 따로 확인해야 합니다
Alpacon은 이 문제를 인가와 위험, 두 가지 검사로 나눕니다. Work Session 안의 에이전트와 빌드를 실행하는 서비스 토큰 모두 두 검사를 거칩니다.
인가는 실행이 승인된 범위에 들어오는지 확인합니다. 관리자가 승인한 서비스 토큰 ACL인지, 활성 상태의 Work Session인지 봅니다. 위험, 즉 명령 위험 판단은 호출자가 아니라 명령 내용을 봅니다. 해당 명령이 위험한지 확인하는 단계입니다. 이 판단이 켜진 환경에서는 누가 명령을 냈는지와 관계없이 적용됩니다. ACL이 넓다고 해서 명령 위험 판단이 면제되거나 약해지지는 않습니다.
| 검사 | 답하는 질문 | 실행 시점 |
|---|---|---|
| 인가 | 이 호출자의 범위가 이 동작을 포함하는가 | 생성 시점, 한 번 |
| 명령 위험 판단 | 이 특정 명령이 위험한가 | 매번, 명령마다 |
서비스 토큰과 개인 API 토큰은 다르게 다룹니다. 서비스 토큰의 범위는 관리자가 미리 승인합니다. 개인 API 토큰은 토큰을 쥔 사람이 직접 범위를 정합니다. 권한이 필요한 실행에는 서비스 토큰과 Work Session을 사용합니다. 권한이 필요 없는 개인 토큰 사용은 그대로입니다.
서비스 토큰은 관리자가 승인한 ACL로 인가를 충족합니다. 파이프라인에서는 범위 안의 토큰 명령을 사람에게 넘기지 않고 자동 승인할 수 있습니다. 명령 위험 판단은 거치지만 사람의 검토를 기다리지는 않습니다. 일상적인 배포 단계 때문에 CI/CD 작업이 멈추지 않게 하기 위해서입니다.
명령 위험 판단은 호출자가 아니라 명령 자체를 봅니다. Alpacon의 명령 판단이 켜진 환경에서는 Work Session 안의 에이전트와 빌드용 서비스 토큰이 같은 위험 검사를 거칩니다. ACL이 넓거나 와일드카드 범위를 가졌다는 이유만으로 명령 내용을 확인하지 않고 넘길 수는 없습니다.
범위만으로는 안전을 보장할 수 없습니다
API에 접근할 수 있는 토큰은 인가를 통과했다는 뜻입니다. 토큰이 실행하려는 명령이 안전한지는 별도의 문제입니다. 범위를 아무리 세심하게 정한 ACL이라도 이 질문에 답하지는 못합니다. "이 토큰은 이 호출을 허용받았다"는 사실로 검사를 끝내면, 범위가 맡지 못하는 판단까지 범위에 떠넘기게 됩니다. 위 사례들은 토큰이 잘못된 손에 들어가거나 잘못된 지시를 따를 때 피해가 얼마나 커질 수 있는지 보여 줍니다. 명령 위험 판단은 로그인 화면을 거치지 않는 호출자를 포함해 모든 호출자에게 적용해야 합니다.
