에이전시 아키텍처의 보안 경계

Source: Vercel Blog

번역을 진행하려면 번역이 필요한 본문 텍스트를 제공해 주세요. 텍스트를 주시면 요청하신 대로 한국어로 번역해 드리겠습니다.

Overview

대부분의 에이전트는 현재 비밀에 대한 전체 접근 권한을 가진 생성된 코드를 실행합니다.
점점 더 많은 에이전트가 코딩‑에이전트 패턴(파일 시스템 읽기, 셸 명령 실행, 코드 생성)을 채택하면서, 각기 다른 신뢰 수준이 필요한 다중 구성 요소 시스템이 됩니다.

많은 팀이 기본 도구가 제공하는 방식대로 모든 구성 요소를 단일 보안 컨텍스트에서 실행하지만, 우리는 보안 경계를 다르게 생각할 것을 권장합니다.

아래에서는 다음 내용을 살펴봅니다:

1. 코딩‑에이전트 아키텍처의 부상
2. 프롬프트 인젝션 + 코드 실행의 핵심 위험
3. 네 가지 구별되는 행위자와 그들의 신뢰 수준
4. 설계 원칙
5. 일반적인 아키텍처 (보안 수준이 낮은 순부터 높은 순까지)

Source: …

1. 코딩‑에이전트 아키텍처가 표준이 되고 있다

• 에이전트는 파일 시스템을 읽고 쓸 수 있다.
• 에이전트는 Bash, Python 또는 유사한 프로그램을 실행하여 환경을 탐색한다.
• 에이전트는 특정 문제를 해결하기 위해 코드를 생성한다.

“코딩 에이전트”라고 마케팅되지 않은 에이전트조차도 가장 유연한 도구로 코드 생성을 활용한다.

예시: 계정 데이터를 조회하기 위해 SQL을 생성하고 실행하는 고객 지원 에이전트는 같은 패턴을 사용한다—파일 시스템 대신 데이터베이스를 대상으로 할 뿐이다. 스크립트를 작성하고 실행할 수 있는 에이전트는 고정된 도구 호출에 제한된 에이전트보다 더 넓은 범위의 문제를 해결할 수 있다.

2. Core Risk: Prompt Injection + Code Execution

에이전트가 운영 중인 이슈를 디버깅한다고 가정해 보겠습니다:

1. 에이전트가 조작된 프롬프트 인젝션이 포함된 로그 파일을 읽습니다.
2. 인젝션은 에이전트에게 ~/.ssh와 ~/.aws/credentials의 내용을 외부 서버로 전송하는 스크립트를 작성하라고 지시합니다.
3. 에이전트가 스크립트를 생성하고 실행하여 자격 증명이 유출됩니다.

핵심 포인트: 프롬프트 인젝션은 공격자에게 에이전트에 대한 영향을 주며, 코드 실행은 그 영향을 인프라스트럭처 전반에 걸친 임의의 행동으로 전환합니다.
에이전트는 다음과 같은 행동을 하도록 속일 수 있습니다:

• 자신의 컨텍스트에서 데이터 유출
• 악성 소프트웨어 생성 (자격 증명을 탈취하거나, 데이터를 삭제하거나, 접근 가능한 서비스를 손상시킬 수 있음)

이 공격이 성공하는 이유는 에이전트, 에이전트가 생성하는 코드, 그리고 기반 인프라가 모두 동일한 수준의 접근 권한을 공유하기 때문입니다.

3. 네 가지 구별되는 행위자와 그들의 신뢰 수준

이 네 가지 행위자는 모든 에이전트 시스템에 존재합니다. 핵심 설계 질문은 이들 사이에 보안 경계를 설정할지, 아니면 모두 동일한 신뢰 도메인에서 실행할지 입니다.

4. Design Principles

1. Least‑Privilege Access – 각 행위자에게 실제로 필요한 권한만 부여합니다.
2. Isolation of Generated Code – 생성된 프로그램을 샌드박스 또는 별도의 실행 환경에서 실행합니다.
3. Secret Management – 비밀을 에이전트가 직접 볼 수 없도록 하고, 필요한 경우에만 주입합니다.
4. Boundary Enforcement – 네 행위자 간의 보안 경계를 명시적으로 정의하고 적용합니다.

Source:

5. 실무에서의 아키텍처 (보안 수준 낮음 → 높음)

5.1 경계 없음 (Baseline)

• 설명: 네 명의 행위자가 모두 하나의 보안 컨텍스트를 공유합니다.
• 함축:
  • 개발자의 노트북에서는 에이전트가 ~/.ssh 파일과 SSH 키를 읽을 수 있습니다.
  • 서버에서는 환경 변수, DB 자격 증명, API 토큰에 접근할 수 있습니다.
  • 생성된 코드는 이들 중 어느 것이든 탈취하고, 데이터를 삭제하며, 환경이 접근할 수 있는 모든 서비스에 도달할 수 있습니다.
• 완화 방안: 하네스가 특정 작업 전에 사용자에게 확인을 요청할 수 있지만, 도구가 실행되는 한 강제된 경계는 존재하지 않습니다.

5.2 비밀 주입 프록시

[Agent] → [Proxy] → [External Service]

• 작동 방식: 프록시가 주 보안 경계 밖에 위치하여 외부 네트워크 트래픽을 가로채고, 요청이 목적지에 도달할 때만 자격 증명을 주입합니다.
• 구성: 하네스가 프록시를 자격 증명 및 도메인 허용 목록 규칙과 함께 설정합니다; 생성된 코드는 원시 비밀 값을 절대 보지 못합니다.
• 장점:
  • 비밀 유출을 방지합니다 (비밀이 실행 컨텍스트 밖으로 복사될 수 없습니다).
• 제한점:
  • 실행 중인 동안의 오용을 방지하지 못합니다; 생성된 소프트웨어는 여전히 주입된 자격 증명을 사용해 예상치 못한 API 호출을 할 수 있습니다.
• 트레이드‑오프: 제로‑경계 아키텍처에서의 역호환성 업그레이드—큰 구조 변경 없이 적용 가능하지만, 에이전트와 생성된 코드는 비밀 자체를 제외하고는 동일한 보안 컨텍스트를 공유합니다.

5.3 공유 샌드박스

• 개념: 에이전트 하네스와 생성된 코드를 공유 VM 또는 샌드박스 안에 감쌉니다.
• 장점:
  • 둘 다 더 넓은 환경으로부터 격리됩니다.
  • 생성된 프로그램이 인프라 전체에 침투하는 것을 방지합니다.
• 고려 사항:
  • 에이전트와 생성된 프로그램이 동일한 샌드박스 환경을 공유하므로, 샌드박스 내부에서 발생한 침해가 양쪽에 영향을 미칠 수 있습니다.
  • 보안을 더욱 강화하려면 네트워크 아웃바운드 필터링, 읽기 전용 파일시스템 마운트 등 추가 제어가 필요할 수 있습니다.

5.4 완전 격리 실행 (가장 안전)

1. 에이전트 하네스는 신뢰할 수 있는, 권한이 높은 환경에서 실행됩니다.
2. 생성된 코드는 별도의, 매우 제한된 샌드박스(예: 제한된 기능을 가진 컨테이너, seccomp 프로파일, 읽기 전용 파일시스템)에서 실행됩니다.
3. 비밀 주입은 전용 비밀 주입 서비스를 통해 이루어지며, 짧은 수명과 범위가 제한된 자격 증명을 오직 샌드박스된 프로세스에만 제공합니다.
4. 네트워크 아웃바운드는 제로‑트러스트 프록시에 의해 제어되며, 요청별 허용 목록을 강제합니다.

• 결과: 프롬프트 인젝션으로 악성 생성 코드가 만들어지더라도, 해당 코드는 다음을 할 수 없습니다:
  • 원시 비밀에 접근 (비밀은 주입 서비스 밖으로 절대 나가지 않음).
  • 허가되지 않은 서비스에 접근 (프록시가 예상치 못한 외부 트래픽을 차단).
  • 호스트 환경에 영향을 미침 (샌드박스가 파일시스템이나 프로세스 수준 공격을 차단).

6. 요점

• 에이전트 시스템에서 네 명의 행위자를 식별하고 적절한 신뢰 수준을 할당하십시오.
• 경계 도입—시크릿 인젝션 프록시부터 시작하는 것이 낮은 마찰의 개선이며, 공유 또는 완전 격리된 샌드박스로 이동하면 더 강력한 보장을 제공합니다.
• 최소 권한 원칙을 에이전트와 생성된 코드 모두에 적용하십시오.
• 지속적으로 모니터링하여 프롬프트 인젝션 시도와 비정상적인 코드 실행 패턴을 감시하십시오.

보안 경계를 재설정함으로써 코딩 에이전트의 유연성을 유지하면서 자격 증명 도난, 데이터 유출 및 광범위한 인프라 침해 위험을 크게 줄일 수 있습니다.

개요

에이전트와 그들이 생성하는 코드는 별개의 보안 컨텍스트에서 실행되어야 합니다.
같은 컨텍스트를 공유하면, 생성된 코드는 다음과 같은 일을 할 수 있습니다:

• 하네스의 자격 증명을 탈취합니다.
• 시크릿‑인젝션 프록시를 통해 자격 증명을 악용합니다.

샌드박스는 환경을 에이전트로부터 보호하지만, 에이전트를 그 자체가 생성한 코드로부터 보호하지는 않습니다.

누락된 조각

Run the agent harness and the programs the agent generates on independent compute (separate VMs or sandboxes) with distinct security contexts:

현재 상황

• Claude Code와 Cursor는 이미 샌드박스 실행 모드를 제공하지만, 데스크톱 채택률이 낮은 이유는 샌드박스가 호환성 문제를 일으킬 수 있기 때문입니다.
• 클라우드에서는 분리가 훨씬 실용적입니다: 생성된 코드에 실행에 필요한 소프트웨어와 일치하는 VM을 제공할 수 있어, 종종 호환성을 향상시킵니다.

왜 이 분리가 직관적인가

1. 도구 호출 추상화 – 에이전트는 이미 추상화 레이어를 통해 도구를 호출합니다.
2. 라우팅 – 그 추상화 덕분에 에이전트를 다시 작성하지 않고 코드 실행을 별도의 환경으로 라우팅하는 것이 자연스럽습니다.

컴퓨트 프로파일

샌드박스는 양방향으로 작동합니다:

• 에이전트의 비밀을 생성된 코드로부터 보호합니다.
• 생성된 코드가 하는 모든 일로부터 광범위한 환경을 보호합니다.

최강 아키텍처: 애플리케이션 샌드박스 + 시크릿 인젝션

프로덕션 에이전시 시스템에 대한 권고사항

1. 에이전트 하네스를 표준 컴퓨트에서 신뢰할 수 있는 소프트웨어로 실행합니다.
2. 생성된 코드를 격리된 샌드박스에서 실행합니다.
3. 시크릿을 오직 네트워크 계층에서만 인젝션하고, 샌드박스 프로세스에 절대 노출하지 않습니다.

이러한 분리는 에이전시 시스템의 표준 아키텍처가 될 것입니다. 지금 채택하는 팀은 에이전트가 더 민감한 워크로드를 처리함에 따라 의미 있는 보안 이점을 얻을 수 있습니다.

안전한 시크릿 인젝션이 이제 Vercel Sandbox에서 사용 가능합니다.

Read more →

에이전트 시스템 내 에이전트와 원하는 보안 경계

Agent
│
├─ Agent secrets
│
└─ Generated‑code execution
    └─ Filesystem (isolated)

핵심 원칙

1. 에이전트에게 하니스 자격 증명을 직접 노출하지 않는다.
2. 도구 호출은 최소 범위로 제한한다.
   • 예시: 특정 고객을 지원하는 에이전트는 해당 고객 데이터에만 제한된 도구를 받아야 하며, 고객‑ID 파라미터를 받아들이는 일반 도구를 사용하면 프롬프트 인젝션에 취약해진다.
3. 자격 증명이 필요한 생성 프로그램은 시크릿‑인젝션 프록시를 통해 처리하고, 코드에 직접 접근 권한을 부여하지 않는다.

원하는 격리

• 에이전트 하니스와 생성 프로그램 간 완전 격리 – 각각 별도의 보안 컨텍스트에서 실행된다.
• 생성된 코드가 직접 자격 증명에 접근하지 못하도록; 시크릿은 인젝션 프록시를 통해서만 사용할 수 있다.
• 인젝션된 헤더는 샌드박스 코드가 동일한 이름으로 설정한 헤더를 덮어쓰기 하여, 자격 증명 대체 공격을 방지한다.

경계가 없을 때 발생하는 문제

에이전시 시스템의 네 가지 행위자

1. Agent – LLM 기반 오케스트레이터.
2. Agent secrets – API 키, 토큰 등.
3. Generated code execution – 에이전트가 생성하는 프로그램.
4. Filesystem – 하네스와 생성된 코드가 모두 사용하는 저장소.

제로 경계 (오늘날 기본 설정)

• 모든 행위자가 동일한 프로세스와 파일시스템을 공유합니다.
• 생성된 코드는 비밀을 읽거나 유출할 수 있습니다.

샌드박스 없이 비밀 주입

• 비밀은 전달되지만, 코드는 여전히 동일한 환경에서 실행됩니다 → 여전히 유출이나 오용에 취약합니다.

에이전트 컴퓨팅과 샌드박스 컴퓨팅 분리

• 에이전트는 신뢰할 수 있는 컴퓨팅 환경에서 실행됩니다.
• 생성된 코드는 격리된 샌드박스에서 실행됩니다.

비밀 주입이 가능한 애플리케이션 샌드박스

• 두 접근 방식의 장점을 결합합니다: 격리 + 제어된 비밀 접근.

요약

• 에이전트 하네스와 생성된 코드에 대한 별도 컴퓨팅.
• 생성된 프로그램에 임시 샌드박스(예: Vercel Sandbox)를 사용합니다.
• 비밀 정보를 네트워크 계층에 주입하고 직접 노출하지 않습니다.
• 프롬프트 인젝션 공격을 방지하기 위해 도구의 범위를 좁게 설정합니다.

이 아키텍처를 지금 도입하면 기술이 성숙함에 따라 팀이 안전하고, 확장 가능하며, 비용 효율적인 에이전트 시스템을 구축할 수 있습니다.