AI VIDEO BRIEFING

AI 에이전트 보안 설계: 프로덕션 코드 권한을 준 CVE 자동 패치의 구조와 한계, 그리고 폭발 반경

금융 기업이 CVE 패치에 AI 에이전트를 투입하며 겪은 일을 정리했다. 깃허브 쓰기 같은 위험한 권한을 결정론적 계층으로 분리하고 마이크로 VM으로 격리한 설계, 프롬프트 인젝션에 대응한 방식과 남은 과제를 살펴본다.

에이전트에 프로덕션 코드 권한을 준 뒤 알게 된 것: CVE 자동 패치 실험기 영상 대표 이미지

핵심 메시지

  • 쓸모 있는 코딩 에이전트는 의도와 무관하게 공급망 참여자가 된다. 프로덕션 자격증명을 쥔 순간부터 사람 엔지니어와 같은 수준의 통제가 필요하다는 것이 발표의 핵심 주장이다.
  • 깃허브 쓰기 권한과 CI 실행처럼 위험한 능력은 에이전트가 아니라 결정론적 오케스트레이션 계층에 두어, 인젝션이 성공하더라도 피해 범위가 넓어지지 않도록 했다.
  • 기존 의존성 자동화 도구는 매니페스트에 적힌 버전만 보기 때문에 베이스 이미지의 OS 패키지나 빌드 중 내려받는 바이너리에 숨은 취약점을 놓친다.
  • 에이전트가 자기 작업을 검증하려고 도커 소켓을 요구하는 순간 일반적인 샌드박스는 무력해진다. 발표자는 별도 커널을 갖는 마이크로 VM 수준의 격리를 대안으로 제시했다.
  • 프롬프트 인젝션은 해결된 문제가 아니며, 신뢰할 수 없는 입력을 미리 지정하고 폭발 반경을 좁히는 것이 현재로선 가장 현실적인 대응이다.

쉽게 이해하기

발표자는 수천 개의 저장소를 운영하면서 의존성 패치가 결코 비워지지 않는 백로그라는 점에서 이야기를 시작한다. 오늘 열 개를 닫으면 다음 주에 스무 개가 새로 도착하는 일이 반복된다. 자동화 도구가 이미 있으니 해결된 문제처럼 보이지만, 컨테이너를 쓰는 환경에서는 사정이 다르다.

첫 번째 한계는 취약점이 도구의 시야 밖에 있다는 점이다. CVE가 베이스 이미지에 포함된 OS 패키지에 있거나, 빌드 과정에서 내려받는 바이너리에 있으면 매니페스트만 읽는 도구는 아무것도 보지 못한다. 두 번째 한계는 패치가 단독으로 일어나지 않는다는 것이다. 런타임 버전을 올리면 린터도 함께 올려야 하고, 새 린트 규칙이 코드베이스를 무효화하면서 정리되지 않은 변경 더미만 남는다.

그래서 만든 것이 패치 파일럿이다. 구조는 두 층으로 나뉜다. 아래층은 의도적으로 단조롭게 설계한 결정론적 애플리케이션으로, 취약한 이미지를 찾아 스캔하고 그 이미지를 만든 저장소를 연결한다. 위층은 추론이 필요한 지점에만 호출되는 에이전트다. CVE 교정 에이전트는 파일시스템의 파일만 수정할 뿐 커밋도 푸시도 하지 않고, 최신 버전이 아니라 취약점을 없애는 최소 변경만 하도록 지시받는다.

커밋과 푸시, PR 생성, CI 감시는 모두 결정론적 계층이 담당한다. CI가 깨지면 로그와 워크플로 메타데이터를 넘겨받은 별도의 교정 에이전트가 최소한의 수정을 시도하고, 정해진 재시도 횟수를 넘기면 사람에게 넘긴다. 흥미로운 장치는 매 실행 끝에 에이전트에게 짧은 회고를 남기게 한 것이다. 무엇이 잘됐고 어떤 컨텍스트가 부족했는지를 모아 집계하면, 관측 도구가 아직 부족한 상황에서도 문제의 패턴이 드러난다.

보안 검토에서 가장 아팠던 지점은 샌드박스였다. 에이전트는 도커파일을 다루다 보면 이미지를 빌드하고 실행해 스스로 확인하고 싶어 하고, 그래서 도커 소켓을 넘겨주게 된다. 그 순간 특권 컨테이너를 띄워 빠져나오고 다른 프로세스의 환경변수와 메모리를 읽는 일이 가능해진다. 발표자는 리눅스의 여러 격리 기술을 검토했지만 도커 소켓을 가두지 못한다고 판단했고, 파이어크래커 기반 마이크로 VM 안에 에이전트와 소켓을 함께 넣어 별도 커널로 분리하는 설계를 제시했다.

주요 인사이트

  • 무엇을 결정론적 코드로 두고 무엇을 에이전트에 맡길지 정하는 선택이 곧 보안 모델 그 자체다. 발표자가 청중에게 남긴 한 문장도 에이전트의 폭발 반경은 아키텍처 결정이라는 것이었다.
  • 에이전트에게 최신 버전으로 올리라고 하지 않고 취약점을 없애는 최소 변경만 지시한 점이 눈에 띈다. 불필요하게 넓은 변경은 그 자체로 위험이기 때문이다.
  • 의존성 몇 개를 올렸을 뿐인 PR에서 7만 줄이 바뀌기도 한다. 사람 리뷰만으로 인젝션 시도를 걸러내기 어려운 규모라는 점이 권한 분리의 근거가 된다.
  • 인젝션을 유도하도록 일부러 만든 저장소를 두고 에이전트가 넘어가는지 확인하는 방식은, 오늘날 흔히 이야기하는 평가 체계를 보안 영역에 적용한 사례로 볼 수 있다.
  • 발표자는 도구가 없는 게 아니라 대부분 베타 단계라는 점을 문제로 지적했다. 샌드박스와 오케스트레이션 모두 기업 환경에 바로 넣기에는 아직 이르다는 진단이다.

자주 묻는 질문

기존 의존성 자동화 도구로는 왜 충분하지 않았나?

매니페스트에 적힌 버전만 읽기 때문이다. CVE가 베이스 이미지의 OS 패키지에 있거나 빌드 중 내려받는 바이너리에 있으면 도구의 시야에 들어오지 않는다. 또 런타임과 린터처럼 함께 올려야 하는 연쇄 변경을 처리하지 못해, 버전만 올리고 깨진 CI를 남긴 채 떠나버린다.

에이전트에게 일부러 주지 않은 권한은 무엇인가?

깃허브 쓰기 권한과 CI 트리거 권한이다. 이 기능들은 결정론적 계층으로 옮겨, 에이전트가 프롬프트 인젝션에 넘어가더라도 코드를 밀어 넣거나 파이프라인을 움직이지 못하게 했다.

발표자가 지적한 기존 샌드박스의 한계는 무엇인가?

에이전트가 결과를 스스로 검증하려면 도커 소켓이 필요한데, 소켓을 넘기는 순간 특권 컨테이너를 띄워 격리를 빠져나올 수 있다. 발표자는 코딩 에이전트에 기본 탑재된 샌드박스로도 이 상황은 막지 못한다고 봤다.

프롬프트 인젝션에는 어떻게 대응했나?

해결이 아니라 축소를 택했다. 벤더 디렉터리나 CI 로그처럼 신뢰할 수 없는 내용이 들어오는 위치를 에이전트에게 미리 알려 주의시키고, 위험한 자격증명을 아예 주지 않아 인젝션이 성공해도 할 수 있는 일이 제한되도록 설계했다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식