Agentic Architecture 의 보안 경계

오늘 대부분의 에이전트는 당신의 비밀 (secrets) 에 대한 완전한 접근 권한을 가진 생성된 코드 (generated code) 를 실행합니다. 더 많은 에이전트가 코딩 에이전트 패턴을 채택함에 따라, 파일 시스템을 읽거나, 쉘 명령어를 실행하거나, 코드를 생성하는 방식으로 작동하기 때문에, 각 구성 요소마다 다른 수준의 신뢰가 필요해지고 있습니다. 대부분의 팀은 기본 도구 설정이 그렇기 때문에 이 모든 구성 요소를 하나의 보안 컨텍스트에서 실행하지만, 우리는 이러한 보안 경계를 다르게 생각해야 한다고 권장합니다. 아래에서는 이를 살펴보겠습니다.

코딩 에이전트 아키텍처를 채택하는 에이전트가 더 많아지고 있습니다. 이러한 에이전트는 파일 시스템에 읽기 및 서기를 수행합니다. 환경 탐색을 위해 bash, Python 또는 유사한 프로그램을 실행합니다. 또한 점점 더 많은 에이전트가 특정 문제를 해결하기 위해 코드를 생성하고 있습니다. "코딩 에이전트"로 마케팅되지 않은 에이전트조차도 가장 유연한 도구로 코드 생성을 사용합니다. 계정을 조회하기 위해 SQL 을 생성하고 실행하는 고객 지원 에이전트는 파일 시스템 대신 데이터베이스를 대상으로 하는 동일한 패턴을 사용하고 있습니다. 고정된 도구 호출 세트에만 제한된 에이전트보다, 스크립트를 작성하고 실행할 수 있는 에이전트는 더 넓은 문제 클래스를 해결할 수 있습니다. 예를 들어, 생산 문제를 디버깅하는 에이전트를 고려해 봅시다. 에이전트는 crafted prompt injection 을 포함하는 로그 파일을 읽습니다. 이 주입은 에이전트에게 외부 서버의 내용을 전송하는 스크립트를 작성하도록 지시합니다. 에이전트는 해당 스크립트를 생성하고 실행하며, 인증 정보가 사라집니다.

~/.ssh ~/.aws/credentials
이것이 코딩 에이전트 패턴의 핵심 위험입니다. 프롬프트 주입은 공격자에게 에이전트에 대한 영향을 부여하며, 코드 실행은 그 영향을 인프라에 대한 임의의 행동으로 바꿉니다. 에이전트는 자신의 컨텍스트에서 데이터를 탈취하거나, 악성 소프트웨어를 생성하거나, 둘 다 할 수 있습니다. 이러한 악성 소프트웨어는 인증 정보를 도난당하거나, 데이터를 삭제하거나, 에이전트가 실행하는 머신에서 도달 가능한 모든 서비스를 침해할 수 있습니다. 공격은 에이전트, 에이전트가 생성한 코드, 그리고 인프라가 모두 동일한 수준의 접근 권한을 공유하기 때문에 작동합니다.

올바른 위치에 경계를 그리기 위해서는 이러한 구성 요소와 각 구성 요소가 deserve 하는 신뢰 수준을 이해해야 합니다. 에이전트 시스템에는 4 개의 서로 다른 신뢰 수준을 가진 고유한 주체가 있습니다. 에이전트는 컨텍스트, 도구 및 모델에 의해 정의된 LLM 기반 런타임입니다. 에이전트는 표준 SDLC 를 통해 구축하고 배포하는 오케스트레이션 소프트웨어, 도구 및 외부 서비스 연결이 포함된 에이전트 하네스 (agent harness) 내부에서 실행됩니다. 하네스는 일반적인 백엔드 서비스를 신뢰하는 것과 같은 방식으로 신뢰할 수 있지만, 에이전트 자체는 프롬프트 주입과 예측 불가능한 행동에 노출되어 있습니다.

정보는 필요 시에만 공개되어야 합니다. 즉, SQL 을 실행하는 도구를 사용할 때 에이전트는 데이터베이스 인증 정보를 보지 않아도 됩니다. 에이전트 비밀 (agent secrets) 은 시스템이 작동하기 위해 필요한 인증 정보로, API 토큰, 데이터베이스 인증 정보 및 SSH 키를 포함합니다. 하네스는 이를 책임감 있게 관리하지만, 다른 구성 요소가 직접 접근할 수 있으면 위험해집니다.

아래 전체 아키텍처 논의는 이러한 비밀에 접근 경로가 있는 구성 요소를 결정하는 것입니다. 에이전트가 생성하고 실행하는 프로그램은 변수입니다. 생성된 코드는 언어 런타임이 허용하는 모든 것을 할 수 있어, 가장 추론하기 어려운 주체가 됩니다. 이러한 프로그램은 외부 서비스와 통신하기 위해 인증 정보를 필요로 할 수 있지만, 생성된 코드가 비밀에 직접적인 접근 권한을 부여하면 프롬프트 주입이나 모델 오류가 인증 정보 도난으로 이어질 수 있습니다.

파일 시스템과 더 넓은 환경은 ..."

이 시스템이 실행되는 플랫폼 (노트북, 가상 머신, Kubernetes 클러스터 등) 과 무관하게 모든 에이전트 시스템에는 이 네 가지 주체가 존재합니다. 환경은 하네스 (harness) 를 신뢰할 수 있지만, 에이전트가 완전한 접근 권한을 가졌거나 보안 경계 없이 임의 프로그램을 실행할 수 있다고는 믿을 수 없습니다. 이러한 네 가지 주체는 모든 에이전트 시스템에 존재하며, 핵심 질문은 이들 사이에서 보안 경계를 설정하는지, 아니면 모두 동일한 신뢰 영역 (trust domain) 에서 실행하도록 허용하는지에 있습니다. 이러한 신뢰 수준으로부터 다음 설계 원칙들이 도출됩니다.

이러한 주체와 원칙을 염두에 두고 실제 관측된 아키텍처를 제시합니다. 보안 수준이 낮은 것부터 높은 순서로 나열되었습니다.

Claude Code 와 Cursor 같은 코딩 에이전트는 샌드박스 기능을 내장하고 있지만, 이는 종종 기본 설정 (off) 으로 제공됩니다. 실제로 많은 개발자는 보안 경계가 없는 상태로 에이전트를 실행합니다. 이 아키텍처에서는 네 가지 주체 사이에서 아무런 경계도 존재하지 않습니다. 에이전트, 에이전트의 비밀 정보 (secrets), 파일 시스템, 생성된 코드 실행은 모두 단일 보안 컨텍스트를 공유합니다. 개발자의 노트북 환경에서는 에이전트가 파일을 읽을 수 있고 SSH 키에 접근할 수 있습니다. 서버 환경에서는 환경 변수, 데이터베이스 인증 정보, API 토큰에 대한 접근 권한이 부여됩니다. 생성된 코드는 이러한 정보를 탈취하여 데이터를 삭제하거나 환경에서 도달 가능한 모든 서비스에 접근할 수 있습니다. 하네스는 특정 동작 전에 사용자에게 확인을 요청할 수 있지만, 도구가 실행되면 강제되는 보안 경계는 존재하지 않습니다.

.env A 는 주요 보안 경계 외부에 위치하며, 아웃바운드 네트워크 트래픽을 인터셉트하여 요청이 의도된 엔드포인트로 이동할 때만 인증 정보를 주입합니다. 하네스는 인증 정보와 도메인 규칙을 프록시 (proxy) 에 설정하지만, 생성된 코드는 원본 비밀 값을 결코 볼 수 없습니다.

프록시는 탈출 (exfiltration) 을 방지합니다. 실행 컨텍스트에서 비밀 정보를 복사하여 다른 곳에서 재사용하는 것을 막습니다. 그러나 프록시는 활성 런타임 동안의 오용을 방지하지는 않습니다. 시스템이 작동 중일 때, 생성된 소프트웨어는 주입된 인증 정보를 사용하여 예상치 못한 API 호출을 여전히 수행할 수 있습니다.

비밀 정보 주입 (secret injection) 은 경계가 없는 아키텍처에서 백워드 호환성을 갖는 경로입니다. 구성 요소를 실행하는 방식을 재구성하지 않고도 프록시를 추가할 수 있습니다. 트레이드오프는 에이전트와 생성된 코드가 비밀 정보 자체를 제외하고는 여전히 동일한 보안 컨텍스트를 공유한다는 점입니다.

자연스러운 본능은 에이전트 하네스와 생성된 코드를 공유된 VM 또는 샌드박스 안에 감싸는 것입니다. 공유된 샌드박스는 두 주체를 넓은 환경으로부터 격리하며, 이는 genuinely 유용합니다. 생성된 프로그램은 더 넓은 인프라 구조에 침투할 수 없습니다. 그러나 공유된 샌드박스에서는 에이전트와 생성된 프로그램이 여전히 동일한 보안 컨텍스트를 공유합니다. 생성된 코드는 하네스의 인증 정보를 탈취할 수 있으며, 비밀 정보 주입 프록시가 설치되어 있다면 프록시를 통해 인증 정보를 오용할 수 있습니다. 샌드박스는 에이전트를 환경으로부터 보호하지만, 에이전트의 자신의 생성된 코드로부터 에이전트를 보호하지는 않습니다.

결여된 부분은 에이전트 하네스와 에이전트가 생성하는 프로그램이 독립적인 컴퓨팅 자원 (VM 또는 샌드박스) 에서 실행되도록 하는 것입니다. 서로 다른 보안 컨텍스트를 가진 별도의 VM 또는 샌드박스에서 실행됩니다. 하네스와 하네스의 비밀 정보는 하나의 컨텍스트에 존재합니다. 파일 시스템과 생성된 코드 실행은 다른 컨텍스트에 있으며, 에이전트의 비밀 정보에 접근할 수 없습니다.

현재 Claude Code 와 Cursor 는 모두 샌드박스 실행 모드를 제공합니다. 그러나 데스크톱 환경에서의 채택이 낮습니다. 이는 샌드박싱이 호환성 문제를 일으킬 수 있기 때문입니다. 클라우드 환경에서는 이 분리 방식이 더 실용적입니다. 에이전트가 실행해야 하는 소프트웨어 유형에 맞춰 생성된 코드에 전용 VM 을 할당할 수 있으며, 이는 실제로 호환성을 개선할 수 있습니다.

실제로는,

이 분리 작업은 단순한 변경 사항입니다. 에이전트가 도구 호출을 추상화 계층을 통해 수행하며, 이 추상화는 에이전트 자체를 재작성하지 않고 코드 실행을 별도의 환경으로 라우팅하는 것을 자연스럽게 만듭니다. 이 두 워크로드의 컴퓨팅 프로파일은 매우 다르며, 이를 분리하면 각워크로드를 독립적으로 최적화할 수 있습니다. 에이전트 해서는 대부분 LLM API 응답 대기 시간을 소비합니다. Vercel 은 I/O 동안 청구가 정지되고 활성 CPU 시간만 계산하므로, 실제 작업에 비례하여 비용을 유지하고 대기 시간을 청구하지 않아 이 워크로드에 적합합니다. Fluid compute 생성 코드는 반대 프로파일을 가집니다. 에이전트가 생성한 프로그램은 짧은 수명, 예측 불가능하며 불신용입니다. 각 실행은 다른 프로그램이 남긴 비밀이나 상태를 접근할 수 없도록 깨끗하고 격리된 환경을 필요로 합니다. Sandboxed 제품들은 실행마다 스피닝 업되어 이후 파괴되는 일시적 Linux VM 을 통해 이를 제공합니다. VM 경계가 보안 컨텍스트 분리를 강제합니다. 샌드박스 내부의 생성 코드는 해커스 비밀에 네트워크 경로가 없으며 호스트 환경에 접근할 수 없습니다. Vercel Sandbox 샌드박스는 양방향으로 작동합니다. 샌드박스는 생성 코드를 에이전트 비밀에서 보호하고, 생성 코드가 수행하는 것을 더 넓은 환경에서 보호합니다. 가장 강력한 아키텍처는 애플리케이션 샌드박스 및 비밀 주입을 결합하는 것입니다. 이 조합은 단독으로는 달성할 수 없는 두 가지 속성을 제공합니다: 생산용 에이전트 시스템에 대해 우리는 둘 다 결합하는 것을 권장합니다. 에이전트 해서는 표준 컴퓨팅에서 신뢰된 소프트웨어로 실행됩니다. 생성 코드는 격리된 샌드박스에서 실행됩니다. 비밀은 네트워크 수준에서 주입되어, 생성 코드가 직접적으로 비밀을 접근할 수 있는 곳에서 노출되지 않습니다. 에이전트 컴퓨팅과 샌드박스 컴퓨팅의 이 분리는 에이전트 시스템의 표준 아키텍처가 될 것입니다. 대부분의 팀은 아직 이 전환을 하지 않았으며, 기본 툴링이 이를 강제하지 않기 때문입니다. 이제 이러한 경계를 그리는 팀들은 에이전트가 더 민감한 워크로드를 수행함에 따라 의미 있는 보안 우위를 가질 것입니다. 안전한 비밀 주입은 이제 , 더 많은 정보는 에서 확인할 수 있습니다. Vercel Sandbox 문서에서 읽으세요. Read more 에이전트 시스템의 행위자들그 사이에서 보안 경계가 어디에 위치해야 하는지아기리된 코드와 생성 코드를 별도의 컨텍스트에서 실행하는 아키텍처해커스는 에이전트에 직접 자신의 자격증표를 노출해서는 안 됩니다. 에이전트는 범위를 가진 도구 호출을 통해 기능을 접근해야 하며, 이러한 도구는 가능한 한 좁아야 합니다. 특정 고객을 위한 지원 업무를 수행하는 에이전트는 해당 고객의 데이터에 대해 범위를 가진 도구를 받아야 하며, 고객 ID 파라미터를 받는 도구가 아닌 것이어야 합니다. 왜냐하면 이 파라미터는 프롬프트 주입의 대상이기 때문입니다. 자체 자격증표를 필요로 하는 생성 프로그램은 별도의 문제로, 아래 아키텍처가 이를 해결합니다. 에이전트 해커스와 생성 프로그램 간의 완전한 격리, 각자가 자신의 보안 컨텍스트에서 실행됩니다. 생성 코드는 직접적인 자격증표 접근이 없으며, 실행 중에는 주입 프로кси를 통해 비밀을 사용할 수 있지만 읽거나 탈출할 수 없습니다. 주입된 헤더는 샌드박스 코드가 설정한 동일한 이름의 헤더를 덮어써서 자격증표 대체 공격을 방지합니다. 모든 에이전트는 이제 코딩 에이전트처럼 보입니다. 경계가 없는 경우 무엇이 잘못되는지아기리된 시스템의 4 명의 행위자들경계 없음: 오늘의 기본값비밀 주입 없이 샌드박스링 분리된 에이전트 컴퓨팅

sandbox compute Application sandbox with secret injection Agent Agent secrets Generated code execution Filesystem Why sandboxing everything together isn't enough