[기획: AI 트렌드] 한 주 새 별 1만 2천여 개가 몰린 AI 보안 감사 스킬, 찾은 에이전트는 검증하지 않는다

별은 지난 한 주에 몰렸고, 코드는 9월에 멈춰 있었다

GitHub 주간 트렌딩의 1위는 Cloudflare의 저장소 security-audit-skill이었습니다. GitHub는 개발자들이 코드를 올려 두는 곳이고, 트렌딩은 그 기간 관심이 몰린 저장소를 골라 보여 주는 목록입니다. 한 주 사이 붙은 별은 1만 2,680개, 누적은 4만 6,784개였습니다. 별은 사용자가 저장소에 누르는 관심 표시입니다. 누적의 4분의 1 남짓이 한 주에 붙은 셈이지만, 관심의 크기일 뿐 성능을 잰 숫자는 아닙니다.

저장소에 든 것은 코딩 에이전트에게 보안 감사를 맡기는 스킬입니다. 코딩 에이전트는 사람 대신 코드를 읽고 명령까지 실행하는 AI 프로그램입니다. 스킬은 에이전트에게 특정 작업을 가르치는 SKILL.md 파일이 든 폴더입니다. 신입에게 건네는 업무 매뉴얼 묶음처럼, 폴더 안 문서는 일하는 순서를 적은 절차서입니다. Anthropic은 지난 목요일 이 형식의 표준을 리눅스 재단 산하 단체에 기증했고, 이 표준을 도입한 에이전트 플랫폼이 70개가 넘는다고 밝혔습니다.

에이전트에게 「이 코드 전체를 보안 감사해 줘」처럼 말로 요청하면 감사가 시작됩니다. 찾으려는 것은 실제 신뢰 경계를 넘는 취약점입니다. 취약점은 공격자가 원래 허용되지 않은 일을 하게 만드는 코드의 결함입니다.

그런데 저장소의 변경 기록에는 지난 한 주의 날짜가 하나도 없습니다. 커밋은 저장소에 변경을 한 번 기록한 단위입니다. 첫 커밋은 6월 18일, 마지막 커밋은 9월 14일이었습니다. 관심은 새 코드가 아니라 한 달 넘게 그대로인 절차서에 몰렸습니다. 왜 하필 이 주였는지는 확인하지 못했습니다.

여섯 단계, 그리고 먼저 떼어 두는 예산

스킬을 불러오기만 하면 기본은 질문이나 좁은 검토에 응하는 조언 모드이고, 사람이 분명히 요청해야 전체 감사가 돌아갑니다. 전체 감사는 정찰 → 사냥 → 후보 검증 → 기록 작성 → 기록 재검증 → 보고서의 여섯 단계입니다.

정찰에서는 코드 구조와 신뢰 경계, 외부 입력이 들어오는 곳을 파악해 점검 단위 목록을 만듭니다. 사냥에서는 서로 격리된 하위 에이전트들이 단위를 나눠 맡아 취약점을 찾습니다. 하위 에이전트는 주 에이전트가 일을 맡기려고 따로 띄우는 에이전트로, 원문 이름은 사냥꾼입니다. 취약점 찾기를 맡은 단계는 둘째 하나뿐이고, 셋째부터 다섯째까지는 찾은 후보를 확인하고 기록하는 단계입니다.

예산을 쓰는 데도 순서가 있습니다. 예산을 정해 두면, 감사 전체에서 에이전트를 부를 수 있는 횟수의 상한이 됩니다. 사냥꾼을 배치하기 전에, 점검이 빠진 곳을 찾는 비평가 에이전트와 검증에 쓸 호출부터 떼어 둡니다. 검증 예산이 모자라면 사냥을 멈추고, 검증하지 못한 후보는 결과 파일에 넣지 않은 채 실행을 「미완료」로 적습니다.

대상 코드를 돌려 봐야 할 때는 샌드박스에서만 돌립니다. 샌드박스는 외부 네트워크를 끊고 파일 쓰기와 자원 사용을 운영체제 수준에서 제한한 격리 실행 공간입니다. 그런 통제가 없으면 코드를 실행하지 않고, 그 단서를 확인되지 않은 상태로 남깁니다.

발견한 에이전트와 확인하는 에이전트는 다르다

저장소 소개 문서인 README의 설계 원칙에는 「발견을 확인하는 에이전트는 결코 그것을 찾은 에이전트가 아니다」라는 문장이 있습니다. 셋째 단계에서 후보는 하나씩 새 검증자에게 넘어가고, 검증자는 그 후보를 반박하려고 시도합니다. 형식이 틀리거나 설명문으로 감싼 검증 결과는 고쳐 쓰지 않고 버립니다.

후보마다 신뢰가 낮은 주체가 어떤 입력으로 막아야 할 통제를 뚫고 경계를 넘어, 누구에게 무슨 결과를 냈는지 적어야 합니다. 신뢰 경계는 신뢰가 낮은 쪽의 입력이 높은 쪽의 자원에 함부로 닿지 못하게 그어 둔 선입니다. 예를 들어 로그인하지 않은 방문자의 요청으로 남의 계정 정보가 읽힌다면, 그 신뢰 경계가 뚫린 것입니다.

판정은 셋뿐입니다. 「확인됨(confirmed)」은 코드 안의 경로가 끝까지 추적되고 관측한 결과가 있는 후보입니다. 「기각(rejected)」은 반박된 후보이며, 새 근거 없이 다음 실행에서 같은 주장이 되풀이되지 않도록 기록에 남깁니다. 「확인 필요(needs_validation)」는 결론을 막는 사실을 정확히 적어 둔 미확인 가설로, 확신이 덜한 취약점과는 다릅니다. 결론을 좌우하는데 배포 설정이나 프록시처럼 저장소 밖에 있는 통제는 있다고도 없다고도 가정하지 않고 이쪽으로 보내며, 기록에는 그것을 확인할 계획이 붙습니다.

심각도는 취약점이 얼마나 위험한지 매긴 등급이며, 「확인됨」에만 붙습니다. 원문에는 「구체적인 피해를 말하지 못하면 심각도는 느낌보다 낮다」는 문장도 있습니다.

열 가지 금지와 「대략 절반」이라는 자기 측정

SKILL.md 끝에는 하지 말 것 열 가지가 적혀 있습니다. 첫째는 체크리스트에서 벗어난 점을 취약점처럼 내놓는 일이고, 둘째는 실제로 넘을 수 있는 경계 위반 없이 심층 방어를 권하는 일입니다. 심층 방어는 방어를 여러 겹 두는 설계입니다. 앞 겹이 공격을 이미 막는다면, 뒤 겹이 없다는 사실은 취약점이 아니라 보강 메모로 따로 적힙니다.

자기 권한 안의 일이나 자기에게만 돌아오는 피해를, 경계를 넘은 결과처럼 다루는 일도 목록에 있습니다. 관측한 것보다 강한 효과를 보고하는 일, 독립 검증 전에 보고서를 쓰는 일도 마찬가지입니다.

README 설계 원칙에는 「여러 번 돌릴수록 점검 범위가 넓어진다」는 줄이 있고, 근거로 Cloudflare 테스트 결과가 붙어 있습니다. 한 번 실행이 반복 실행에서 찾은 취약점 총량의 대략 절반을 찾았다는 것입니다. README의 성능 수치는 이 한 줄뿐이고, 대상 저장소나 실행 횟수 같은 방법은 README에 적혀 있지 않습니다.

절반의 기준은 실제로 있는 취약점 전체가 아니라 여러 번 돌려 찾은 것의 합입니다. 그 합도 실제 전체보다 클 수는 없습니다. 그러니 이 숫자는 도구의 강약보다 실행마다 찾는 것이 달라진다는 편차를 보여 주고, 실제 전체에 견준 한 번 실행의 몫은 절반을 넘기 어렵습니다(우리 판단). SKILL.md에는 「No one pass is complete」, 즉 어떤 한 번의 실행도 완결이 아니라는 규칙이 있습니다. 한 번의 실행이 대상을 다 훑었다고 암시해서도 안 됩니다.

「0건」을 읽는 법

우리는 Anthropic의 무료 보안 스캐너, 신청한 프로젝트엔 보고서가 사람 검토 없이 간다에서 AI 보안의 병목, 즉 진행을 가장 늦추는 일이 찾기보다 검증하고 고쳐 넣는 데 있다고 봤습니다. 이번 절차서의 설계 원칙과 금지 목록도 대부분 찾은 것을 검증하고 부풀리지 않는 일을 다룹니다(우리 판단).

절차서는 확인된 취약점이 0건인 깨끗한 실행이어도, 그 사실과 함께 남은 점검 범위와 검증 한계를 적으라고 요구합니다. 빠른 프로필로 돌렸거나 범위를 좁힌 실행은 부분 점검이라고 분명히 밝혀야 합니다. 별 개수로 이 도구의 성능을 알 수 없듯, 한 번 실행의 「확인됨」 건수로 대상의 안전을 알 수도 없습니다(우리 판단).

그래서 감사를 돌린 팀이 찾은 개수보다 먼저 읽을 것은 보고서에 따로 남는 범위 진술과 「확인 필요」 목록입니다(우리 판단). 한 번 돌린 AI 감사의 「확인됨 0건」은 안전하다는 판정이 아니라, 이번 실행이 이 범위에서 확인한 것이 없다는 기록입니다(우리 판단 · 확신도 중간).