성공적인 인젝션 한 번, 모든 자격 증명 넘겨주기
API 키를 환경 변수에 넣는 것은 지난 20년간 서버 측 엔지니어링의 기본 동작이었습니다. 2026년 9월 28일, 엔비디아는 오픈 에이전트 보안 플랫폼(Open Agent Safety Platform)을 발표하며 이 기본 동작을 에이전트 시대의 금지 구역으로 만들었습니다. 이 플랫폼은 두 가지 요소로 구성됩니다: 오픈소스 소프트웨어 OpenShell(Apache 2.0, GitHub 저장소 NVIDIA/OpenShell)과 참고 시스템 설계 Sentry입니다. 후자는 BlueField-4 DPU(Data Processing Unit, 데이터 처리 장치)에서 실행되며 주 CPU의 에이전트를 아웃오브밴드(out-of-band) 워치독으로 모니터링하고, 공식적으로 밀리초 단위의 에이전트 격리가 가능하다고 밝혔습니다.
저장소 현황: Rust 구현으로, crates가 core, supervisor, credential-gateway, policy-engine, egress-gateway 등의 모듈로 분리되어 있습니다; 18.2k 스타, 1,852 커밋; 0.1.x 안정 버전으로 약 3주에 한 버전씩 출시됩니다. 커밋 빈도와 3주 간격 출시 리듬은 동일한 결론을 가리킵니다 - 이 런타임은 여전히 빠르게 형성되는 단계에 있으며, 프로덕션에 도입하는 경우 인터페이스 변경에 대한 비용을 예상해야 합니다.
OpenShell의 설계 논리는 한 가지 원칙으로 압축할 수 있습니다: 에이전트 행동은 예측 불가능하므로, 그 도달 범위를 좁히고 권한 판단을 모델 컨텍스트에서 커널로 옮기는 것입니다. 에이전트 런타임의 경쟁 초점이 바뀝니다 - ‘모델이 얼마나 규칙을 지키는가’에서 ‘권한을 초과할 수 있는 범위는 얼마인가’로.
자격 증명은 게이트웨이로, 컨텍스트에는 들어가지 않는다
자율 에이전트의 일상 작업은 셸 명령 실행, 파일 작성, 네트워크 요청 등이며, 자격 증명은 일반적으로 환경 변수, 설정 파일 또는 .env 파일에 저장됩니다. 성공적인 프롬프트 인젝션 한 번, 혹은 모델의 오류 판단 한 번만으로 에이전트는 모든 자격 증명으로 작동하게 됩니다. 폭발 반경은 그에게 부여된 권한 집합과 같으며, 권한을 좁히는 것은 폭발 반경을 좁히는 것입니다. 이것이 OpenShell 전체 설계의 출발점입니다.
프롬프트 수준의 방어선은 적대적인 입력 앞에서 강제력이 없습니다. system prompt 제약은 모델의 순응성에 의존하며, 공격자가 할 일은 모델의 생각을 바꾸는 것뿐입니다. 커널 수준 권한 경계는 모델의 생각을 무시하고 시스템 호출을 직접 거부합니다. 방어선과 경계의 차이점은 강제 주체에 있습니다: 하나는 모델의 자발성에 의존하고, 다른 하나는 커널에 의존합니다.
그림: OpenShell 명령줄 인터페이스 실행 스크린샷, 에이전트의 작업은 정책 검사를 통과한 후에 실행됩니다. 출처: OpenShell 공식 저장소 문서
커널 수준 강제 첫 번째 핵심 메커니즘입니다. 정책이 커널 레벨에서 적용되며, 런타임 라이브러리나 컨테이너 구성에 의존하지 않습니다; 에이전트의 경계 내 모든 작업은 정책 검사를 통과해야 합니다. 컨테이너는 프로세스 격리와 이미지 배포를 해결하지만, OpenShell은 다른 질문에 답합니다: 에이전트 실행 중 자격 증명, 파일, 네트워크에 대한 모든 접근이 허용되는가입니다.
자격 증명 게이트웨이는 두 번째 핵심 메커니즘입니다. API 키와 토큰은 자격 증명 게이트웨이(credential gateway)가 대신 보관하며, 아웃바운드 요청 시 주입됩니다; 자격 증명은 처음부터 에이전트 컨텍스트에 들어가지 않고 파일 시스템에도 남지 않습니다. ‘key를 .env에 넣는다’는 일반적인 방식과 비교하면, 노출 면적이 전체 머신에서 게이트웨이 구성 요소 하나로 좁혀집니다. 모델은 속일 수 있지만, 속은 모델은 열쇠를 가지고 있지 않습니다.
아웃바운드 트래픽 역시 관리됩니다: 아웃바운드 게이트웨이(egress gateway)는 목적지 화이트리스트에 따라 트래픽을 허용하며, 화이트리스트 외부의 모든 목적지는 도달할 수 없습니다; 파일 시스템과 네트워크 목적지도 에이전트가 볼 수 있는 디렉토리와 주소만 노출됩니다.
그림: OpenShell 아키텍처 - 에이전트, 슈퍼바이저, 자격 증명 게이트웨이, 정책 엔진, 아웃바운드 게이트웨이가 각각 독립된 모듈로 구성되며, 자격 증명과 정책 판단은 모두 에이전트 컨텍스트 외부에서 완료됩니다. 출처: OpenShell 공식 저장소 docs/images
정책 변경은 형식 검증을 거쳐야만 적용된다
정책을 한 줄 틀리는 것은 하나의 구멍을 여는 것과 같습니다. OpenShell은 정책 변경을 형식 검증 뒤에 막습니다: 새 정책은 적용 전에 먼저 형식 검증을 거쳐 의미가 예상과 일치하는지 확인합니다. 동종 샌드박스 도구 중에서 이 단계는 드뭅니다 - 대부분의 솔루션은 정책이 코드이며 변경 즉시 적용되는 상태에 머물러 있습니다.
supervisor 구성 요소는 에이전트 생성, 모니터링 및 종료를 담당하며 라이프사이클 관리 계층을 구성합니다. SDK는 Python, TypeScript, Go, Rust 네 가지 언어를 지원하며, Kubernetes 배포는 Helm을 사용하므로 엔지니어링 연결 경로는 완전합니다.
형식 검증 자체에는 한계가 있습니다: ‘정책을 틀리게 쓰는 것’을 막지만, ‘정책을 올바르게 썼지만 너무 좁게 쓴 것’을 해결하지는 않습니다. 정책이 너무 좁으면 에이전트가 제대로 작동하지 않고, 운영 부담이 규칙을 완화하도록 밀어답니다. 의도가 한 번 완화되면, 가장 엄격한 검증도 완화된 의도를 정확히 실행하는 것에 불과합니다. 보안 책임이 코드 레벨에서 정책 작성자에게로 옮겨지며, 정책 자체가 새로운 감사 대상이 됩니다.
그림: 샌드박스 강제 지점 시연 - 정책이 파일 시스템, 네트워크, 자격 증명, 아웃바운드 트래픽 등 여러 경계에서 각각 적용되며, 각 경계는 독립된 구성 요소에 해당합니다. 출처: OpenShell 공식 저장소 docs/images
워치독을 BlueField-4 DPU로 옮겨 밀리초 단위 격리 구현
Sentry 참고 설계는 워치독을 호스트 밖으로 옮겼습니다. BlueField-4 DPU에서 실행되며 주 CPU에서 실행되는 에이전트를 아웃오브밴드로 모니터링하고, 공식적으로 밀리초 단위의 에이전트 격리가 가능하다고 밝혔으며, 데모 환경에서 Vera CPU도 실행에 참여했습니다.
아웃오브밴드는 이 설계의 핵심입니다. 인밴드 모니터링은 모니터링 대상과 동일한 커널과 신뢰 도메인을 공유하므로, 호스트가 침해되면 모니터링도 함께 침해됩니다; DPU는 독립적인 연산 능력과 네트워크 경로를 가지고 있으며, 주 CPU의 에이전트가 제어 불능 상태가 되어도 워치독 자체에 도달할 수 없습니다. 격리 동작은 밀리초 단위로 계산되며, 악의적 창구 역시 밀리초 단위로 좁아집니다 - 전제 조건은 DPU 측 펌웨어와 소프트웨어 스택이 지켜내는 것이며, 워치독 자체가 새로운 고가치 공격 목표가 됩니다.
공식 보도자료에는 동시에 12개 업계 파트너와 통합사가 명시되어 있으며, 클라우드 업체와 보안 업체가 모두 포함되어 있습니다. 생태계 입지는 매우 직설적입니다: 엔비디아는 ‘에이전트가 경계가 있는 런타임에서 실행된다’는 것을 기본 배포 형태로 만들고자 합니다. 마치 하이퍼바이저가 가상 머신에 대한 것처럼 말입니다.
0.1.x 버전 번호, ‘광범위하게 사용 가능’ 네 글자보다 더 솔직한 버전 번호
버전 번호가 먼저 찬물을 끼얹습니다. OpenShell 현재 버전은 0.1.x 안정 버전이며, 약 3주 간격으로 출시되는데, 공식 표현은 ‘이제 광범위하게 사용 가능하다’(now broadly available)입니다. 3주 간격 출시 자체가 신호입니다: 인터페이스와 의미가 여전히 변화 중이므로, 프로덕션에 도입할 경우 마이그레이션 비용을 예상해야 합니다; ‘광범위하게 사용 가능’이라는 네 글자와 0.1.x 버전 사이에는 판단의 여지를 사용자에게 남겨둡니다.
두 번째 찬물: 샌드박스는 폭발 반경을 줄이지 않고, 위험을 제거하지는 않습니다. 커널 강제 레이어, 자격 증명 게이트웨이, 정책 엔진 자체가 새로운 신뢰 기반이 되며, 이들에 문제가 생기면 경계가 무효화됩니다. 공격면은 위치가 옮겨졌을 뿐, 총량은 줄지 않았습니다 - 감사 대상이 ‘에이전트 애플리케이션’에서 ‘샌드박스 런타임’으로 확대됩니다.
방향성 논쟁도 아직 결정되지 않았습니다. 안트로픽의 Claude Managed Agents 같은 관리형 플랫폼은 샌드박스를 클라우드 서비스 내에 구현하며, 사용자가 직접 경계를 구축할 필요가 없습니다. OpenShell은 자체 관리형, 감사 가능한 경로를 따릅니다. 두 가지 길의 전제 조건은 다릅니다: 데이터가 도메인 밖으로 나가지 않고, 자체 감사 단서를 유지해야 하는 팀은 후자를 선택하며, 전담 운영 역량이 없는 팀은 관리형 서비스를 사용하는 것이 훨씬 수월합니다. 선택은 규정 요구사항과 운영 역량에 의해 결정되며, 두 가지 길은 각각 유효한 시나리오를 가집니다.
소프트웨어는 공짜, 하드웨어는 판다
상업적 계산은 명확해야 합니다. OpenShell은 Apache 2.0 오픈소스로 배포되어 에이전트 배포의 규제 장벽을 낮추고, Sentry 참고 설계는 BlueField-4 DPU와 Vera CPU에 묶여 있습니다. 소프트웨어는 무료로 배포되며, 보안 하드웨어는 대당으로 가격 책정됩니다 - CUDA 시대의 낡은 전략이 다시 반복됩니다: 생태계 도구는 무료, 연산 능력은 돈을 받습니다. 샌드박스 런타임 자체는 수익을 창출하지 않으며, 경계가 어떤 하드웨어에서 실행되느냐에 따라 돈이 결정됩니다.
이 전략은 사용자에게도 타당합니다: OpenShell을 선택하면 감사 가능한 경계와 명확한 하드웨어 구매 목록을 얻게 되며, 관리형 플랫폼을 선택하면 무운영을 얻게 됩니다. 두 가지 전달 형태는 각각 자체적인 계산을 따르며, 저장소의 오픈소스 라이선스만으로는 전체 사업 구조를 알 수 없습니다.
처음의 경계선으로 돌아갑니다. 프롬프트 방어선은 모델이 무엇을 말하는지를 관리하며, 커널 경계는 프로세스가 무엇을 할 수 있는지를 관리합니다; 전자는 모델의 순응성에 의존하고, 후자
