Docker의 사각지대: 하나의 호스트, 두 가지 매우 다른 작업
Docker는 프로세스 격리에 탁월하지만, 근본적인 사각지대가 존재합니다. 바로 네트워크 요청 뒤에 숨겨진 '의도'를 파악할 수 없다는 점입니다. 기본적인 네트워크 허용 목록(allowlist)은 에이전트가 수행하려는 애플리케이션 계층의 작업과 관계없이 GitHub로 향하는 모든 아웃바운드 연결을 동일한 트래픽으로 간주합니다.
Docker 컨테이너 내에 GitHub 토큰을 보유한 에이전트를 생각해 보십시오. 컨테이너 입장에서 리포지토리 데이터를 읽는 요청(GET)과 이슈를 생성하는 요청(POST)은 동일한 서비스로 향하는 동일한 트래픽으로 보입니다. Docker의 계층 3/4 수준의 제어는 이러한 극명하게 다른 작업을 구분할 수 있는 의미론적 인지 능력이 부족하며, 이는 치명적인 보안 공백을 만듭니다.
컨테이너는 실행 환경을 캡슐화하고 강력한 보안 계층을 제공하는 데 여전히 매우 유용합니다. 하지만 네트워크 연결 가능성만을 허용된 작업의 기준으로 삼을 때 한계가 드러납니다. 기존 모델은 "에이전트가 이 엔드포인트에 도달할 수 있는가?"라고 묻지만, 더 중요한 질문인 "에이전트가 그 접근 권한으로 무엇을 할 수 있는가?"에 대해서는 답을 주지 못합니다.
이러한 사각지대는 샌드박싱에 있어 더 세밀하고 애플리케이션을 인지하는 접근 방식이 필요함을 시사합니다. Docker는 에이전트 프로세스를 호스트로부터 성공적으로 격리하지만, 특정 API 작업을 제어하는 세밀한 애플리케이션 수준 정책을 적용할 수 없어 중요한 작업이 취약한 상태로 남게 됩니다.
차이를 드러내는 Curl 테스트
전통적인 네트워크 보안은 에이전트가 대상에 도달할 수 있는지 묻지만, 더 깊은 질문은 연결된 후 어떤 작업을 수행할 수 있는지입니다. 이 중요한 차이를 설명하기 위해 컨테이너 내부에서 GitHub API를 대상으로 하는 curl 테스트를 고려해 보겠습니다. 처음에는 요청이 기본적으로 거부됩니다.
이후 정책 업데이트를 통해 GitHub API에 대한 읽기 전용 접근이 허용됩니다. 컨테이너나 에이전트를 재시작하지 않고 적용된 이 변경 사항은 즉시 curl 명령어가 데이터를 가져올 수 있게 합니다. 이제 동일한 호스트에서 동일한 도구가 API와 성공적으로 상호 작용합니다.
그러나 결정적인 테스트는 그다음입니다. 새로운 GitHub 이슈를 생성하기 위해 POST 요청을 시도하는 것입니다. 동일한 curl 명령어를 사용하고 동일한 API 엔드포인트를 대상으로 함에도 불구하고, 이 쓰기 작업은 거부됩니다. 정책이 읽기만 허용하고 쓰기는 허용하지 않았기 때문입니다.
이는 애플리케이션 계층 검사의 힘을 보여줍니다. GitHub로 향하는 모든 트래픽을 구분 없이 처리하는 기본적인 IP 및 포트 규칙과 달리, NVIDIA OpenShell과 같은 고급 샌드박스는 HTTP 메서드(GET vs POST) 및 특정 API 경로를 기반으로 규칙을 적용할 수 있습니다. 이러한 의미론적 인지 능력은 유효한 토큰을 가진 에이전트라도 의도된 기능 내에서만 활동하도록 제한하여 의도치 않거나 악의적인 작업을 방지합니다.
OpenShell, 가드레일을 런타임으로 이동시키다
NVIDIA OpenShell은 보안 경계를 컨테이너 호스트에서 에이전트 런타임으로 이동시킵니다. Apache 2.0 라이선스로 배포되는 이 오픈 소스 샌드박스는 Docker를 대체하는 것이 아니라, 자율형 AI 에이전트를 위한 정책 적용 계층을 제공합니다. OpenShell은 기존 네트워크 허용 목록보다 훨씬 더 세밀한 수준에서 에이전트의 작업을 감독합니다.
운영자는 YAML을 사용하여 선언적 정책(declarative policies)을 정의하며, OpenShell은 이를 Open Policy Agent (OPA/Rego) 규칙으로 컴파일합니다. 이러한 정책은 HTTP 인식 제어를 가능하게 하여 메서드(예: GET vs POST), 특정 경로, 그리고 /usr/bin/curl과 같은 허용된 바이너리에 대한 세밀한 제한을 설정할 수 있습니다. 중요한 점은 워크플로우에서 입증된 바와 같이, 실행 중인 에이전트를 재시작하지 않고도 정책 변경 사항이 즉시 적용된다는 것입니다.
OpenShell의 설계는 네트워크 트래픽 그 이상을 다룹니다. 여기에는 Linux Landlock LSM 및 seccomp 프로필을 사용하여 파일 시스템과 프로세스를 제한하는 다중 계층 격리가 포함됩니다. 이는 권한 상승 및 승인되지 않은 시스템 호출을 차단합니다. 자격 증명 중개(Credential brokering)는 에이전트가 API 비밀 값을 직접 보유하지 못하게 하여 보안을 더욱 강화합니다. 실제 토큰은 요청이 허용된 송신(egress) 규칙과 일치할 때만 주입되므로 프롬프트 인젝션 위험을 완화합니다.
기저 메커니즘과 추가적인 구현 세부 사항에 관심이 있는 분들을 위해 프로젝트가 여기 공개되어 있습니다: NVIDIA OpenShell: Runtime for Autonomous AI Agents. 이 포괄적인 접근 방식은 에이전트가 접근할 수 있는 위치뿐만 아니라, 무엇을 할 수 있는지 정의하고 에이전트를 제어하는 것을 목표로 합니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
읽기 전용(Read-Only)이 위험이 없는 것은 아닙니다: 한계를 파악하십시오
세밀한 제어가 있더라도 읽기 전용 액세스가 위험으로부터 자유로운 것은 아닙니다. GET 요청도 쿼리 문자열이나 헤더를 통해 데이터를 유출할 수 있으므로, 정책은 HTTP 메서드 그 이상을 살펴봐야 합니다. 엄격한 규칙은 단순히 POST나 DELETE 작업을 차단하는 것을 넘어, 특정 경로, 매개변수, 허용된 스키마를 제한해야 할 수도 있습니다.
운영상의 한계 또한 주의가 필요합니다. 알 수 없는 엔드포인트를 자동으로 승인하거나, 기존의 시행 계층이 구문 분석하기 어려운 원시 WebSockets 또는 GraphQL과 같은 복잡한 프로토콜을 간과할 경우 정책 공백이 발생할 수 있습니다. NVIDIA OpenShell의 감독자(supervisor)는 HTTP 트래픽을 프록시 및 검사하며, 선언적 YAML 정책을 Open Policy Agent (OPA/Rego) 규칙으로 컴파일합니다.
OpenShell을 심층 방어(defense-in-depth) 전략의 중요한 한 계층으로 취급하십시오. 현실적인 프롬프트 인젝션 시나리오를 바탕으로 정책을 테스트하고, 에이전트가 액세스할 수 있는 자격 증명을 최소화하며, 런타임이 실제로 무엇을 검사하는지 확인하십시오. 샌드박스 내부의 에이전트는 API 비밀 값을 직접 보유하지 않으며, 대신 요청이 허용된 송신 규칙과 일치할 때만 상위 게이트웨이에서 실제 토큰이 외부적으로 주입됩니다.
더 깊은 통찰력과 구현을 위해 OpenShell GitHub 저장소와 NVIDIA의 포괄적인 문서를 살펴보십시오. OpenShell은 또한 파일 시스템 및 프로세스 제어를 위해 Linux Landlock LSM 및 seccomp 프로필과 통합되어 권한 상승 및 승인되지 않은 시스템 호출을 차단합니다.
자주 묻는 질문(FAQ)
AI 에이전트를 보호하는 데 Docker만으로는 충분하지 않은 이유는 무엇인가요?
Docker는 프로세스를 격리하지만, 일반적인 네트워크 규칙은 일반적으로 에이전트가 수행하는 API 작업이 아닌 목적지에 따라 연결을 허용하거나 차단합니다.
NVIDIA OpenShell은 무엇을 추가하나요?
OpenShell은 HTTP 메서드 및 목적지에 대한 제어를 포함하여 에이전트 중심의 정책을 적용하도록 설계된 오픈 소스 런타임입니다.
OpenShell이 쓰기는 차단하면서 GitHub 읽기는 허용할 수 있나요?
네, 정책을 통해 허용된 읽기 요청과 이슈 생성을 위한 POST와 같은 허용되지 않은 쓰기 요청을 구분할 수 있습니다.
읽기 전용 API 액세스가 데이터 유출 위험을 제거하나요?
아니요. 쿼리 문자열, 헤더, 지원되지 않는 프로토콜 또는 지나치게 허용적인 규칙은 여전히 위험을 초래할 수 있으므로 신중한 정책 설계가 필요합니다.