에이전트 아키텍처에서의 보안 경계 설계

AI 코딩 에이전트가 확산되면서 생성된 코드가 전체 시크릿 접근 권한으로 실행되는 보안 위험이 커지고 있다. 이 글은 에이전트 시스템을 구성하는 4가지 행위자(에이전트, 시크릿, 생성 코드, 파일시스템)와 신뢰 수준에 따른 4단계 보안 아키텍처를 체계적으로 제시한다. 권장 패턴은 에이전트 하네스와 생성 코드를 별도 VM/샌드박스로 격리하면서 시크릿은 네트워크 프록시를 통해서만 주입하는 방식이다.

핵심 포인트

현재 대부분의 에이전트는 생성된 코드에 전체 시크릿 접근 권한을 부여하는 1단계(경계 없음) 구조로 운영된다
에이전트 시스템의 4가지 행위자: LLM 런타임(프롬프트 인젝션 취약), 시크릿, 생성된 코드, 파일시스템
2단계(시크릿 인젝션): 아웃바운드 트래픽 가로채는 프록시가 헤더에 시크릿 주입 — 생성 코드가 자격증명에 직접 접근 불가
3단계(분리된 컴퓨팅): 에이전트 하네스와 생성 코드를 별개 VM/샌드박스에서 격리 실행
4단계(샌드박스 + 시크릿 인젝션, 권장): 완전 격리와 안전한 시크릿 사용을 동시에 달성
주입 규칙은 실행 중인 샌드박스에서 재시작 없이 동적으로 변경 가능 — 다단계 워크플로우 지원

상세 정리

문제 배경: 코딩 에이전트 패턴 확산으로 LLM, 생성 코드, 파일시스템이 하나의 보안 컨텍스트를 공유한다. LLM이 프롬프트 인젝션에 손상되면 모든 API 토큰과 DB 자격증명이 노출된다.
4가지 행위자 정의: 에이전트(LLM 기반 런타임, 신뢰도 낮음), 에이전트 시크릿(API 토큰/DB 자격증명/SSH 키), 생성된 코드 실행(에이전트가 만들어 실행하는 프로그램), 파일시스템(실행 환경) — 각 행위자의 신뢰도가 서로 다르다.
1단계(경계 없음): 모든 행위자가 단일 보안 컨텍스트 공유. 현재 대부분 에이전트의 현실. 에이전트 손상 시 모든 시크릿 즉시 노출.
2단계(시크릿 인젝션): 에이전트와 생성 코드 사이에 네트워크 프록시 배치. 아웃바운드 HTTPS 요청에 API 키/토큰을 HTTP 헤더로 자동 주입. 생성 코드는 자격증명을 알지 못하고도 인증된 외부 서비스 호출 가능. 단, 실행 중 오용(예: 민감 데이터 추출)은 여전히 가능.
3단계(분리된 컴퓨팅): 에이전트 하네스를 신뢰할 수 있는 컴퓨팅에, 생성 코드를 별도 VM/샌드박스에 격리. 생성 코드가 에이전트의 시크릿에 아예 접근 불가. 단, 격리만으론 시크릿 없이 외부 서비스 호출이 불가하다.
4단계(샌드박스 + 시크릿 인젝션, 권장): 3단계의 VM 격리에 2단계의 프록시 시크릿 주입을 결합. 생성 코드는 자격증명을 보유하지 않고도 프록시를 통해 인증된 외부 API 안전하게 호출. 에이전트가 손상되어도 유출할 시크릿이 VM 내에 없다.
동적 규칙 변경: 주입 규칙은 실행 중인 샌드박스에서 재시작 없이 업데이트 가능. 신뢰할 수 없는 코드 실행 전에 자격증명을 제거하는 다단계 워크플로우 구현이 가능하다.
도메인 매칭: 정확한 도메인과 와일드카드(예: *.github.com) 모두 지원. 특정 서비스에만 자격증명을 주입하면서 일반 트래픽은 허용하는 세밀한 제어 가능.
핵심 원칙 요약: 에이전트 하네스는 신뢰 컴퓨팅 환경에서, 생성 코드는 고립된 샌드박스에서 실행하고, 시크릿은 네트워크 계층에서만 주입해야 한다.

왜 읽나AI 에이전트 시스템을 설계하거나 보안 아키텍처를 고민하는 엔지니어에게 프롬프트 인젝션 위협에 대응하는 실용적인 4단계 격리 모델을 제공한다.

Vercel Blog 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

에이전트 아키텍처에서의 보안 경계 설계

이 글과 비슷한

오리진 서버 포스트 퀀텀 인증 지원 — ML-DSA mTLS 구현기

DeepsecBench: AI 모델의 보안 취약점 탐지 성능 평가

Nuxt 2026년 7월 보안 권고사항