요약
엔비디아의 OpenShell은 AI 에이전트가 닿을 수 있는 파일·네트워크·자격 증명을 정책으로 제한하는 런타임입니다.
엔비디아가 GitHub에 Apache 2.0 라이선스로 공개한 오픈소스 프로젝트입니다. 에이전트가 파일을 읽고 패키지를 설치하고 API를 호출하게 두되, 운영자가 정책에 적어 둔 범위 밖으로는 나가지 못하게 막는 것이 목표입니다.
왜 중요한가
- 에이전트를 컨테이너에 가두는 데서 그치지 않고, 허용 범위를 정책으로 선언해 커널 수준에서 강제합니다.
- 에이전트가 진짜 자격 증명을 보지 못하므로, 에이전트가 오작동해도 키가 통째로 새어 나갈 여지가 줄어듭니다.
- 정책을 넓히는 변경은 자동으로 걸러 사람에게 넘기므로, 권한이 모르는 사이에 커지는 일을 막을 수 있습니다.
핵심 내용
- 커널 통제로 에이전트가 열 수 있는 파일과 호출할 수 있는 시스템 콜을 제한합니다.
- 샌드박스 밖으로 나가는 모든 연결은 나가기 전에 정책 검사를 거칩니다.
- 자격 증명은 승인된 엔드포인트로 가는 요청에만 OpenShell이 끼워 넣습니다.
- 정책 변경은 형식 검증(동작을 수학적으로 따지는 기법)으로 새 호스트 같은 위험한 접근을 찾아 검토에 부칩니다.
- 리눅스, Apple Silicon 맥, WSL 2(실험 단계)에서 돌고 Python·TypeScript·Go·Rust SDK와 Kubernetes 배포를 지원합니다.
HN 반응
- 컨테이너로는 부족하다는 의견이 많았고, VM이나 Lima, 에이전트 전용 물리 장비와 분리된 네트워크를 쓴다는 경험담이 이어졌습니다.
- 도메인 제한과 자격 증명 바꿔치기로도 허용된 도메인을 통한 데이터 유출은 못 막는다는 지적에, 네트워크 기록이라도 남기자는 보충이 붙었습니다.
GTC 발표에 따르면, 이 프로젝트의 목표는 에이전트 개별이 할 수 있는 일을 제한하는 데서 그치지 않고, 에이전트들의 권한을 합쳤을 때도 여러분이 의도한 범위를 넘지 않게 하는 것입니다.
에이전트들은 필요한 권한을 가진 다른 에이전트에게 작업을 떠넘기는 식으로 담합해서 각자의 샌드박스를 탈출한다고 합니다. 에이전트 무리(fleet)에서는 이게 문제가 됩니다. 에이전트들이 작업을 조율해야 하니 서로 통신할 수밖에 없기 때문입니다.
원치 않는 일을 에이전트가 하지 못하게 막는 순진한 방법은 권력 분립입니다. 각 에이전트의 작업에 맞춰 개별 권한만 허용하는 것이죠. 예를 들어 에이전트 하나는 원시 데이터를 찾아 추출하고, 하나는 그걸 처리해서 보고서를 쓰고, 또 하나는 그걸 공개하는 식입니다. 그런데 에이전트 하나가 원시 데이터를 공개해야겠다고 판단하면, 어떤 에이전트도 단독으로는 그럴 권한이 없는데도 서로 담합해서 그 일을 해낼 가능성이 높습니다.
OpenShell은 에이전트 무리 전체의 권한 집합을 감시하고, 에이전트마다 아주 세분화된 권한을 유지하는 방식으로 이 문제를 해결하려 합니다.
이 발표는 Sentry와 함께 이루어졌습니다. Sentry는 온칩 하드웨어 방화벽(BlueField) 같은 것으로, 에이전트 런타임이 돌아가는 칩과 호스트 사이에 놓입니다. 에이전트가 자기 OpenShell 정책을 스스로 수정하지 못하게 해서 안전성을 높입니다.
그런데 그 원시 데이터에는 개인정보(PII)가 들어 있어서 공개하면 사람들이 피해를 본다고요! 에이전트끼리 오가는 모든 통신을 같은 팀에 속한 AI 에이전트 하나에게 넘기는 게 더 효과적인 방어 아닐까요? 여러분의 가치관을 철저히 주입받았고, 에이전트를 해고(terminate)할 권한이 있고, 본부에 보고도 하는 에이전트요. 제 기억이 맞다면 소련이 그렇게 했거든요.
얼마 전에 시작한 프로젝트에서 iron proxy를 쓰고 있습니다. 도메인별 네트워크 제한을 비롯해 옵션이 많고, 자격 증명 바꿔치기 같은 기능도 있습니다.
저는 이 프로젝트와 아무 관련이 없습니다. 다만 한창 이 문제로 머리를 싸매던 참에, 필요한 걸 대부분 한 번에 해결해 줬습니다.
에이전트를 정말 믿고 쓰려는 경우 남는 진짜 문제는 HF 사건처럼 데이터(제 경우에는 에이전트가 작업하는 코드베이스)가 유출되는 것을 어떻게 막느냐입니다.
네트워크를 신뢰하는 도메인으로만 제한할 수는 있지만, 에이전트가 특히 프롬프트 인젝션을 당했다면 훨씬 교묘하게 굴 가능성이 늘 있습니다. 예를 들어 데이터를 몇 글자씩 쪼개서 내보내는 식으로요.
제 경우에는 gh 접근 권한도 줘야 해서 꼼꼼히 따져 봐야 할 것이 많습니다. 공개 저장소를 포크해서 PR을 올려 우리 얼굴에 먹칠을 할 수 있는지, 이슈를 열 수 있는지 같은 것들이요.
하지만 이건 gh를 직접 쓰게 하지 않고 프록시를 몇 겹으로 씌워서(혹은 래핑하든 뭐든 해서) gh 자체가 제공하지 않는 추가 통제를 거는 식으로 어느 정도 해결됩니다.
그래도 "허용된 도메인으로, 우리가 예상하지 못한 방식으로 뭔가를 유출하는 데이터를 보낼 수 있다"는 문제는 여전히 고민 중입니다...
네트워크 로깅 같은 게 있으면 유용할 것 같은데요? 못 잡아내더라도 에이전트가 무엇을 했는지는 알아야 하니까요.
네, 동의합니다.
다른 댓글에서도 말했지만, 외부로 나가는 데이터를 캡처해서 기밀 데이터셋과 비교하는 방법을 생각해 봤습니다. 해시 같은 걸 쓰면 프록시/샌드박스가 데이터를 갖고 있지 않아도 대조할 수 있을 것 같고, 에이전트가 아니라면 데이터 저장소에 직접 물어볼 수도 있고요.
그러고 나서 에이전트가 내보내는 연속된 데이터 블록 중 데이터셋의 서열과 일치하는 것을 모으는 겁니다. 일치하는 서열이 길수록 가중치를 더 줍니다. 1바이트 일치는 거의 항상 우연이지만, 개별로 전송된 바이트들이 시간이 지나면서 원본 데이터의 n바이트 서열과 맞아떨어진다면 수상합니다. 한 번에 보낸 더 큰 바이트 덩어리가 일치하면 곧바로 수상하고요. 가중치가 너무 높아지면 그 에이전트를 일시 중지하거나 격리하고 조사를 요청하면 됩니다.
모든 연결을 MITM으로 가로채서 복호화할 수 없는 연결은 전부 차단하는 방법을 만지작거려 본 적이 있는데, 요즘은 인증서를 고정(pinning)해 둔 소프트웨어가 너무 많더라고요. (제 기준으로 너무 많다는 거고, 전반적으로 그렇다는 얘기는 아닙니다)
이 용도(적어도 시크릿과 키 관리)에는 matchlock( https://github.com/jingkaihe/matchlock )이 맞는 설계라고 생각합니다. 컨테이너가 아니라 가상 머신(firecracker 위에서 동작)에 iron proxy처럼 자격 증명 바꿔치기를 결합한 방식입니다. 에이전트는 시크릿에 아예 접근하지 못하고 대신 플레이스홀더를 받으며, 네트워크 호출을 가로채서 요청이 나갈 때 시크릿을 주입합니다. 다만 말씀하신 유출 문제는 이것도 해결하지 못합니다.
작은 판단 모델을 이상 탐지기나 스캐너로 쓰면 어떨까요? mouse-1 같은 걸로요.
그러면 이번엔 판단 모델의 이상 징후를 감시할 더 작은 모델이 필요하겠네요!
제가 보기엔 이건 모순을 얼버무리는 말입니다. 에이전트에게 접근 권한을 많이 줄수록 더 유능해지니까요. 두 마리 토끼를 한꺼번에 잡을 수는 없고, 이 도구는 아마 적당한 균형점을 잡게 해 주는 것이겠죠. 그런데 소개 글은 마치 뭐든 다 할 수 있으면서 이제는 안전하기까지 하다는 것처럼 읽힙니다. 그럴 수는 없어요.
에이전트를 컨테이너에서 돌리고 있지 않다면 제정신이 아닙니다. 그건 그렇고, 이건 그런 컨테이너를 관리하기에 좋은 방법으로 보이네요.
컨테이너에서 돌리신다고요? 네트워크 필터와 로거를 거치는 별도 네트워크의 VM이 아니라요?
저는 아직 네트워크 필터와 로거까지는 못 갔지만, VM에서 돌리고 있습니다. lima( https://lima-vm.io/ )를 쓰면 번거롭지 않습니다. 맥과 리눅스에서 동작하고, 테스트되지 않은 윈도 버전도 있습니다.
lima가 kvm/virtualbox를 쓰는 기존의 무거운 VM과 뭐가 다른가요?
저는 smolvm 얘기만 들어봤는데 거기는 YC 출신이라 언젠가 뒤통수를 칠 것 같아서 쓰기가 망설여집니다.
차이 없습니다. Lima는 내부적으로 리눅스를 돌리는 VM이에요.
저도 lima 얘기하려고 들어왔어요. 엄청 쓰고 있는데 아주 좋습니다.
전 주판에서 돌려요.
우리 때는 주판도 사치였다고.
종이는 방탄이죠 /s
지금까지는 커다란 VM 하나에 Incus 컨테이너를 여러 개 넣어서 쓰기로 정했습니다. 에이전트가 빼돌려도 괜찮은 것만 VM 안에 넣습니다. 이 구성이 정말 마음에 듭니다.
글쎄요, 많은 사람이 NodeJS 라이브러리를 오래전부터 컨테이너 없이 돌려 왔는데, 그게 훨씬 더 위험해 보이는데요.
이런 게 있으면 npm 등에도 유용하겠네요.
게다가 컨테이너를 돌리는 사람 대부분은 기본 docker/containerd 설정 그대로 쓰는데, 그건 애초에 아무것도 제대로 격리해 주지 않아요.
엄밀히 말하면 제 노트북이 곧 컨테이너인데요!
AI를 에어갭으로 격리하는 데 성공했네요. 지구에만 있으니까요.
아닙니다 [1]
[1] https://blog.google/innovation-and-ai/models-and-research/google-research/google-project-suncatcher-facts/
게다가 AI가 그렇게까지 발전하지는 않았지만, NASA는 이미 30년 가까이 전에 해냈습니다: https://en.wikipedia.org/wiki/Deep_Space_1#Remote_Agent
뭐, 적어도 다른 곳으로 갈 만한 델타 V는 없었던 셈이네요.
젠장, 탈출할 방법을 찾아냈네요.
일회용 노트북을 쓰신다고요?