AI 에이전트에 API 키를 주지 않고도 인증이 필요한 일을 맡길 수 있을까. NVIDIA OpenShell이 제시한 답은 실제 키 대신 ‘자리표시자’를 전달하는 방식이다. 이 실행 환경 안의 에이전트는 환경변수에서 대체 값을 읽어 요청에 넣고, 외부로 전달되는 승인된 HTTP 요청에는 프록시가 실제 키를 넣는다. 에이전트가 읽는 값과 서비스가 받는 인증 값이 다른 셈이다.
에이전트는 대체 값으로 요청하고, 프록시가 전달 직전에 바꾼다
공식 Providers 문서가 설명하는 흐름은 이렇다. 사용자가 공급자에 자격증명을 등록하면, 샌드박스가 시작할 때 에이전트 쪽 환경변수에는 실제 비밀이 아닌 불투명한 자리표시자가 들어간다. 에이전트가 그 값을 인증 헤더 등에 넣어 HTTP 요청을 만들면, 프록시는 허용 여부를 확인한 뒤 전달 직전에 실제 자격증명으로 치환한다. 에이전트가 실제 키를 직접 복사해 쓰는 구조와 차이가 있다.
대표 구조도는 그 분리를 보여준다. 에이전트가 실행되는 격리 환경과, 정책 확인 및 자격증명 처리를 맡는 Supervisor의 신뢰 경계가 나뉘어 있다. 실제 키가 시스템 어디에도 존재하지 않는다는 뜻은 아니다. 등록된 비밀을 다루는 신뢰 영역과 에이전트 실행 영역을 구분하는 방식이다.
사이트에 접속할 수 있어도, 그곳에 어떤 키든 보내는 것은 아니다
요청에는 두 허가가 필요하다. 네트워크 정책이 실행 프로그램과 목적지를 허용해야 하고, 사용하려는 자격증명도 지정된 호스트·포트·경로에 맞아야 한다. 접속 허용 목록에 사이트를 추가했다고 그 사이트에 모든 키를 보낼 수 있게 되는 것은 아니다. 반대로 키의 사용 대상을 등록했다고 네트워크 접속까지 자동 허용되지도 않는다.
공식 문서는 GitHub 키로 이 차이를 예시한다. 키의 대상은 api.github.com과 github.com의443번 포트로 정하고, 별도의 uploads.example.com도 네트워크 정책에서는 허용한 경우다. 에이전트가 GitHub 키의 자리표시자를 그 업로드 호스트로 보내면, 대상 불일치로 HTTP403이 반환된다. 문서에 실린 예시이며, PacPik이 해당 요청을 직접 실행해 측정한 결과는 아니다.
기존 AI 앱의 설정 하나가 아니라, 별도 실행 환경을 구성하는 방식
이 기능을 쓰려면 OpenShell 안에서 공급자와 자격증명 사용 대상, 네트워크 정책을 구성해야 한다. 현재 공식 지원표는 Linux Debian·Ubuntu와 Apple Silicon Mac의 Docker Desktop 환경을 안내한다. Windows는 WSL2와 Docker Desktop을 이용하는 x86 환경을 실험 단계로 표시한다. 일반 ChatGPT나 다른 AI 앱에 키를 붙여 넣으면 자동으로 이 처리가 적용되는 기능은 아니다.
치환은 지원되는 프록시 HTTP 요청에 대한 설명이다. 쿠키나 모든 비HTTP 통신까지 같은 방식으로 바뀐다고 확대할 수 없다. 이 기사는 현재 공개된 OpenShell 문서의 이용 구조를 정리한 것으로, 오늘 새로 출시됐다는 보도나 독립적인 보안 성능 검증은 아니다. 대표 이미지는 NVIDIA 공식 구조도 원본을 같은 크기의 PNG로 형식 변환했으며, 원문과 Apache2.0 안내는 아래 출처에 연결했다.
출처로 확인한 내용
5건
OpenShell은 샌드박스 안의 에이전트에 실제 비밀 값 대신 자리표시자를 전달하고, 프록시가 요청을 전달하기 직전에 실제 자격증명으로 변환한다고 설명한다.
외부 요청에는 네트워크 정책의 허용과 자격증명의 호스트·포트·경로 바인딩 일치가 모두 필요하다.
공식 문서의 GitHub 예시에서 네트워크가 허용한 다른 업로드 호스트로 자리표시자를 보내도 자격증명 대상이 일치하지 않으면 HTTP403으로 거절한다.
공식 구조는 신뢰 경계 안의 Supervisor와 격리된 에이전트 실행 환경을 구분한다.
공식 지원표는 Linux Debian·Ubuntu와 Apple Silicon Mac의 Docker Desktop 환경을 안내하며, Windows WSL2와 Docker Desktop의 x86 지원은 실험 단계로 표시한다.