보안 및 컨테이너화

샌드박스와 자격 증명 격리

Agent가 생성한 코드와 사용자의 비밀 키는 절대 같은 장소에 있어서는 안 됩니다. 이는 보안 아키텍처의 필수 요구사항이며, 단순한 모범 사례 권장이 아닙니다.

핵심 원칙

생성된 코드와 비밀 키는
절대 같은 장소에 있어서는 안 됩니다

이것이 Agent 보안 관리의 제1원칙입니다: 자격 증명과 실행 환경의 물리적 격리.

기존 방식의 문제점

전통적 아키텍처: 하나의 컨테이너에 모든 것

하나의 컨테이너에 모든 것

코드 실행, API 키, OAuth Token, 세션 자격 증명이 모두 같은 실행 환경에 공존합니다. Agent가 볼 수 있는 모든 것은 악성 코드도 볼 수 있습니다.

Prompt Injection 한 번으로 키 탈취

공격자는 Prompt Injection을 통해 Agent가 코드 한 줄(echo $API_KEY)을 실행하도록 설득하는 것만으로 환경 변수의 모든 키를 훔칠 수 있습니다. 전체 공격 체인이 극히 짧아 방어하기 어렵습니다.

Agent가 똑똑할수록 문제가 심각해집니다

더 강력한 Agent는 더 강력한 도구 호출 능력을 의미합니다. 기존 아키텍처에서는 이것이 더 큰 공격 표면을 의미합니다. 모델의 발전이 이 문제를 자동으로 해결하지 않으며, 오히려 악화시킵니다.

모델 능력이 강해질수록 보안 문제가 심각해집니다. 이는 보안 아키텍처가 모델의 자율적 판단에 의존할 수 없음을 의미합니다. 구조적 설계를 통해 보장해야 합니다: 모델이 완전히 제어당하더라도 공격자가 자격 증명에 접근할 수 없도록.

두 가지 자격 증명 격리 패턴

MODE 1

리소스에 바인딩

Token은 사용 시 리소스 접근 경로에 내장되며 독립 변수로 존재하지 않습니다. Agent는 사용할 수 있지만 볼 수는 없습니다.

GIT 클론 시나리오

Token은 클론 시 remote URL에 주입됩니다:
https://token@github.com/repo.git
샌드박스 내 Agent는 push/pull 작업을 정상적으로 수행할 수 있지만 Token을 직접 읽거나 추출할 수 없습니다: Git 설정 깊은 곳에 내장되어 있어 환경 변수로 읽을 수 없습니다.

Token

Remote URL에 주입

사용 가능하지만 보이지 않음

MODE 2

Vault 프록시 패턴

Token은 안전한 Vault 서비스에 저장되며 Agent의 모든 API 호출은 프록시를 통해 전달됩니다. 프록시는 Session ID로 해당 자격 증명을 조회하여 요청에 주입하므로 Agent는 원시 Token에 접근할 수 없습니다.

MCP OAUTH 시나리오

Agent가 MCP 호출을 시작하면 요청이 먼저 프록시 서비스에 도달합니다. 프록시는 현재 Session ID로 Vault에서 OAuth Token을 조회하여 요청 헤더에 주입한 후 대상 MCP 서버로 전달합니다. Agent는 전 과정에서 "호출 성공"만 알 뿐 Token 문자 하나도 보지 못합니다.

Agent 요청 발송

프록시 Token 주입

대상 서비스

OS 수준 샌드박스 격리

3중 격리 장벽

파일 시스템 격리

Agent는 작업 디렉토리의 파일에만 접근할 수 있습니다. 호스트 머신의 다른 파일 시스템 경로는 읽을 수 없으며 자격 증명, 설정, 시스템 파일 모두 보이지 않습니다.

네트워크 격리

샌드박스는 네트워크 접근 범위를 제한합니다. Agent는 임의의 외부 서비스로 데이터를 전송할 수 없습니다. 자격 증명을 획득하더라도 외부로 유출할 수 없습니다.

프로세스 격리

Agent의 코드는 독립된 프로세스 공간에서 실행되어 호스트 머신의 다른 프로세스에 접근할 수 없습니다. 다른 프로세스의 메모리를 읽거나 신호를 보낼 수도 없습니다.

3단계 신뢰 계층

도구부터 조직까지의 계층적 권한 제어

TOOL

도구 수준 신뢰

가장 세밀한 제어입니다. 파일 삭제, 데이터베이스 쓰기, 이메일 발송 등 고위험 작업은 매번 사용 시 수동 승인이 필요합니다. 코드 검색, 파일 읽기 등 안전한 읽기 전용 작업은 자동 허용으로 설정할 수 있습니다.

SESSION

세션 수준 신뢰

단일 대화의 권한 범위입니다. 사용자는 세션 시작 시 Agent에게 특정 범위의 권한을 부여합니다(예: "/src 디렉토리는 읽기/쓰기 가능하지만 /config는 수정 불가"). 세션 기간 동안 권한 범위는 변경되지 않으며 세션 종료 후 자동으로 회수됩니다.

GLOBAL

전역 정책

조직 수준의 보안 정책 제한입니다. 사용자가 세션에서 어떤 권한을 부여하더라도 Agent는 전역 정책을 위반할 수 없습니다. 예: "프로덕션 데이터베이스에 절대 접근 불가", "외부 도메인으로 요청 전송 불가". 이것이 최후의 안전 방어선입니다.

구조적 보안 > Prompt 수준 보안. 설계 단계에서 공격이 불가능하도록 만들어야 합니다. 모델의 자율적 판단에 의존할 수 없습니다. 자격 증명과 실행 환경의 물리적 격리, 다층 신뢰 제어, OS 수준 샌드박스가 Agent를 프로덕션 환경에서 안전하게 운영하는 초석입니다.