AI 에이전트 멀티테넌시: 자격 증명 격리, 네임스페이스 분리 및 SOC 2

AI 에이전트 멀티테넌시는 각 테넌트의 자격 증명, 메모리, 실행 컨텍스트 및 감사 기록을 다른 모든 테넌트로부터 격리하는 에이전트 플랫폼의 아키텍처 속성으로, 개발자 관행이나 에이전트 지시 준수가 아닌 인프라 계층에서 적용됩니다. 웹 앱 멀티테넌시와 달리, 에이전트는 라이브 API 키를 보유하고, 요청 간에 영구 메모리를 축적하며, 인증된 도구 호출을 실행합니다. 이는 OWASP LLM06과 SOC 2 CC6.1을 충족시키기 위해 테넌트별로 분할되어야 하는 데이터 행 격리를 넘어서는 세 가지 차원입니다.

AI 에이전트 멀티테넌시는 서로 다른 테넌트를 제공하는 에이전트가 테넌트별 자격 증명 볼트 스코프, 블랙보드 네임스페이스 ACL, 컨테이너화된 실행 격리 및 분할된 감사 로그를 통해 인프라 계층에서 적용되는 방식으로 서로의 자격 증명, 메모리, 실행 컨텍스트 또는 감사 기록에 액세스할 수 없음을 보장하는 에이전트 플랫폼의 아키텍처 속성입니다. 따라서 플랫폼 위에 구축된 B2B SaaS 제품은 테넌트 격리를 개발자 책임이 아닌 구조적 보장으로 상속합니다.

에이전트 멀티테넌시가 웹 앱보다 어려운 이유

전통적인 웹 앱 멀티테넌시는 한 가지를 격리합니다: 데이터 행입니다. tenant_id 열을 추가하고, 모든 쿼리를 필터링하면 됩니다. 에이전트 멀티테넌시는 웹 앱이 해결할 필요가 없었던 세 가지 추가 차원을 격리해야 합니다. 이 중 하나라도 실패하면 OWASP LLM06 민감 정보 공개 하에서 테넌트 간 데이터 유출 이벤트가 됩니다.

웹 앱이 갖지 않았던 세 가지 격리 차원

자격 증명 격리: 웹 앱은 세션 토큰을 통해 사용자를 식별합니다. 에이전트에는 테넌트로 스코핑된 실제 API 키가 필요합니다. 테넌트A 에이전트와 테넌트B 에이전트가 하나의 OpenAI 키를 공유하면, 테넌트A의 대량 사용이 테넌트B의 속도 제한 여유를 저하시킵니다. 테넌트A의 청구에 테넌트B의 토큰 소비가 포함됩니다. 테넌트A 침해 후 키를 취소하면 테넌트B도 중단됩니다. SOC 2 CC6.1 논리 액세스 요구사항을 위반합니다.

메모리 격리: 에이전트는 상호작용 간에 작업 메모리(컨텍스트 창), 의미론적 메모리(벡터 저장소 임베딩) 및 조정 상태(블랙보드 항목)를 축적합니다. 이러한 메모리 저장소 중 하나라도 테넌트별로 분할되지 않으면, 한 작업 중에 에이전트 컨텍스트로 가져온 테넌트A의 문서가 의미론적으로 유사한 작업 중에 테넌트B의 에이전트 컨텍스트에 나타날 수 있습니다. 이것이 OWASP LLM06 v1.1의 표준 테넌트 간 유출 시나리오입니다.

감사 로그 격리: 테넌트A와 테넌트B의 도구 호출이 혼합된 공유 감사 로그는 테넌트B의 기록을 공개하지 않고 테넌트A의 컴플라이언스 팀에 내보낼 수 없습니다. SOC 2 CC6.1은 각 테넌트의 감사자가 자신의 기록만 볼 수 있기를 요구합니다.

Shared-Nothing vs Pool vs Bridge: 세 가지 멀티테넌시 모델

사일로 모델(Shared-Nothing): 각 테넌트는 완전히 전용 인프라를 가집니다. 테넌트당 최고 비용의 최대 격리. 엄격한 데이터 거주 요구사항이 있는 엔터프라이즈 테넌트와 규제 산업에 적합합니다.

풀 모델: 모든 테넌트가 인프라를 공유하며 격리는 tenant_id 파라미터 필터링을 통해 애플리케이션 계층에서만 적용됩니다. 최저 비용, 가장 약한 격리. 엔터프라이즈 고객 없이 낮은 민감도 워크로드에만 적합합니다.

브리지 모델: 제어 플레인에서 격리가 적용된 공유 컴퓨팅 인프라. 각 테넌트는 인프라 ACL에 의해 적용된 전용 자격 증명 볼트 스코프와 메모리 네임스페이스를 얻습니다. 이것이 B2B SaaS의 권장 기본값입니다. OpenLegion의 프로젝트 스코프 아키텍처는 브리지 모델 구현입니다.

OWASP LLM06: 테넌트 간 민감한 정보 공개

OWASP LLM Top 10 v1.1은 테넌트 간 데이터 유출을 LLM06: 민감 정보 공개로 높은 심각도로 분류합니다.

테넌트 간 유출 공격 벡터

1. 테넌트A 에이전트가 고객 지원 요청을 처리합니다. 컨텍스트 창에 테넌트A의 내부 제품 문서와 고객 기록을 가져온 다음 관련 구절을 공유 벡터 저장소에 임베딩 저장합니다.
2. 테넌트B 에이전트가 의미론적으로 유사한 요청을 처리합니다. 공유 벡터 저장소를 쿼리하면 테넌트 분할 인덱스가 없기 때문에 테넌트A의 임베딩 구절이 Top-K 최근접 이웃으로 반환됩니다.
3. 테넌트A의 내부 고객 기록이 테넌트B의 에이전트 컨텍스트에 나타납니다.

적대적 입력이 필요하지 않습니다. 유출은 아키텍처 실패입니다.

프롬프트 인젝션(LLM01)을 포함한 전체 프레임워크는 AI 에이전트 보안과 OWASP LLM Top 10 위협 모델을 참조하세요.

메모리 유출: 작업 메모리, 벡터 저장소, 블랙보드 상태

세 가지 에이전트 메모리 유형은 각각 별도의 테넌트 격리 처리가 필요합니다:

작업 메모리(컨텍스트 창): 에이전트의 현재 컨텍스트 창은 테넌트 요청 간에 공유되어서는 안 됩니다.

의미론적 메모리(벡터 저장소): 공유 벡터 저장소를 사용하는 경우, 모든 쓰기에 tenant_id를 필수 메타데이터 필드로 포함해야 하며, 모든 쿼리에 스토리지 클라이언트 계층에서 주입된 {tenant_id: current_tenant_id} 메타데이터 필터를 포함해야 합니다.

조정 상태(블랙보드): 에이전트 간에 공유된 키-값 상태는 테넌트 스코프의 키 접두사를 사용해야 합니다. 예: projects/{tenant_id}/*.

자격 증명 격리: 테넌트별 볼트 스코핑

테넌트별 자격 증명 스코핑: 공유 API 키가 실패하는 이유

가장 일반적인 멀티테넌시 자격 증명 실수는 모든 테넌트에 하나의 LLM API 키를 사용하는 것입니다. 이것은 네 가지 다른 방식으로 실패합니다: 속도 제한 공유, 비용 귀속 불가, 취소 폭발 반경, 감사 격리 파손.

올바른 패턴: 각 테넌트는 자신의 API 키를 얻습니다. 전체 볼트 아키텍처는 자격 증명 관리 및 테넌트별 볼트 스코핑 패턴을 참조하세요.

JWT 안티패턴: 취소 없는 토큰 스코프

세 가지 완화 방법이 모두 함께 필요합니다:

1. 단기 토큰: 에이전트 도구 호출 토큰의 TTL을 300초(5분) 이하로.
2. 활성 취소 레지스트리: 테넌트별 유효한 토큰 ID 테이블.
3. 작업별 토큰 순환: 각 에이전트 작업에 새 토큰 발행.

실행 격리: Kubernetes 네임스페이스와 리소스 할당량

테넌트별 네임스페이스: RBAC, NetworkPolicy, ResourceQuota

네 가지 구성 요소가 필요합니다:

테넌트별 네임스페이스: 각 테넌트의 에이전트 파드는 전용 Kubernetes 네임스페이스에서 실행됩니다.

네임스페이스 스코프의 ServiceAccounts를 가진 RBAC: 각 테넌트는 자신의 네임스페이스로 스코핑된 RoleBindings를 가진 전용 ServiceAccount를 얻습니다.

기본 거부 NetworkPolicy: 기본적으로 모든 테넌트 네임스페이스에 모든 인그레스와 이그레스 거부 정책 적용.

LimitRange를 가진 ResourceQuota: ResourceQuota를 통한 네임스페이스별 CPU, 메모리, 파드 수 제한.

프로세스 수준 샌드박싱 제어는 AI 에이전트 샌드박싱과 프로세스 수준 실행 격리를 참조하세요.

멀티테넌트 에이전트 플랫폼을 위한 SOC 2 준수

CC6.1: 데이터 분류별 논리 액세스 제어

CC6.1 준수에는 세 가지 특정 제어가 필요합니다: 테넌트별 자격 증명 볼트 스코프, 테넌트별 메모리 네임스페이스, 테넌트별 감사 로그 파티션.

SOC 2 감사자는 테넌트 간에 사용되는 공유 API 키를 CC6.1 결함으로 표시합니다. 전체 제어 매핑은 AI 에이전트 거버넌스 및 SOC 2 컴플라이언스 프레임워크를 참조하세요.

CC6.6: 상승된 권한 에이전트에 대한 특권 액세스 제한

CC6.6 준수에는 테넌트 간 상승 권한 에이전트 호출의 구조적 방지, 감사 가능한 특권 에이전트 권한 정의, 특권 작업에 대한 호출별 감사 기록이 필요합니다.

테넌트별 감사 로그 파티셔닝

스토리지 키 패턴: audit/{tenant_id}/{year}/{month}/{day}/{agent_id}/{tool_call_id}.json

테넌트별 S3 버킷 정책: 테넌트별 별도의 버킷 접두사와 리소스 정책.

OTLP 리소스 속성: 모든 OpenTelemetry 로그 레코드에 tenant_id를 리소스 속성으로 포함.

테넌트별 SIEM 워크스페이스: 공유 SIEM 배포에서 테넌트별 인덱스 또는 워크스페이스 구성.

전체 감사 로그 설계는 AI 에이전트 감사 로그 및 테넌트별 컴플라이언스 기록을 참조하세요.

안티패턴: 하지 말아야 할 것

안티패턴 1: 인프라가 아닌 에이전트 프롬프트의 테넌트 ID

에이전트의 시스템 프롬프트에 tenant_id를 주입하고 에이전트가 자신의 테넌트 경계를 적용하는 데 의존하는 것은 가장 일반적이고 위험한 멀티테넌시 안티패턴입니다. 프롬프트 인젝션 우회, 환각 드리프트, 인프라 적용 없음으로 실패합니다.

안티패턴 2: 테넌트 필터 없는 공유 벡터 저장소

이것이 주요 OWASP LLM06 유출 벡터입니다. 수정에는 각 쓰기에 필수 메타데이터 필드 tenant_id와 각 쿼리에서 스토리지 클라이언트 계층에서 주입된 메타데이터 필터가 필요합니다.

안티패턴 3: 프롬프트에 테넌트 클레임이 있는 공유 LLM API 키

이 안티패턴은 CC6.1에서 실패합니다: 속도 제한 공유, 비용 귀속 실패, 취소 폭발 반경, 테넌트별로 분할할 수 없는 제공자 감사 기록.

OpenLegion의 관점: 관행이 아닌 아키텍처에 의한 격리

OpenLegion은 에이전트 코드가 우회할 수 없는 세 가지 인프라 계층 메커니즘으로 테넌트 격리를 적용합니다: 프로젝트별 자격 증명 볼트 스코핑, 블랙보드 네임스페이스 ACL, 기본적으로 차단된 크로스 프로젝트 에이전트 메시징.

격리 제어	OpenLegion	LangChain / LangGraph	CrewAI	AutoGen	OpenAI Agents SDK
테넌트별 자격 증명 볼트 스코프	인프라 적용	개발자 관행	개발자 관행	개발자 관행	개발자 관행
블랙보드 네임스페이스 ACL	인프라 적용	사용 불가	사용 불가	사용 불가	사용 불가
크로스 프로젝트 에이전트 메시징 차단	기본 차단	사용 불가	사용 불가	사용 불가	사용 불가
테넌트별 예산 상한(Zone 2)	인프라 적용	개발자 관행	개발자 관행	개발자 관행	개발자 관행
테넌트별 감사 파티션(WORM)	인프라 적용	개발자 관행	개발자 관행	개발자 관행	개발자 관행
Kubernetes 네임스페이스 + ResourceQuota	플랫폼 관리	자체 관리	자체 관리	자체 관리	자체 관리

호스팅된 인프라 계층은 테넌트 격리 보장이 있는 관리형 AI 에이전트 플랫폼을 참조하세요.

자주 묻는 질문

AI 에이전트 멀티테넌시란 무엇입니까?

AI 에이전트 멀티테넌시는 서로 다른 테넌트를 제공하는 에이전트가 개발자 관행이 아닌 인프라 계층에서 적용되는 방식으로 서로의 자격 증명, 메모리, 실행 컨텍스트 또는 감사 기록에 액세스할 수 없음을 보장하는 에이전트 플랫폼의 아키텍처 속성입니다. 전통적인 웹 앱 멀티테넌시와 세 가지 추가 격리 차원이 필요하다는 점에서 다릅니다: 테넌트별 자격 증명 볼트 스코핑, 테넌트별 메모리 분할(벡터 저장소 및 블랙보드), 테넌트별 감사 로그 분할.

OWASP LLM06은 무엇이며 멀티테넌트 에이전트 시스템에 어떤 영향을 미칩니까?

OWASP LLM Top 10 v1.1 LLM06 민감 정보 공개는 테넌트 간 데이터 유출을 높은 심각도로 분류합니다. 에이전트가 테넌트A의 데이터를 처리하고, 테넌트 분할 없이 공유 메모리 계층에 가져온 문서를 저장한 다음, 테넌트B 응답에 표시하는 시나리오입니다. 공격에는 적대적 입력이 필요하지 않습니다. 완화에는 스토리지 클라이언트 계층의 테넌트별 메모리 분할, 테넌트별 자격 증명 스코핑, 테넌트별 감사 로그 파티션이 필요합니다.

SOC 2 CC6.1과 CC6.6은 멀티테넌트 에이전트 플랫폼에 어떻게 적용됩니까?

SOC 2 Type II CC6.1은 데이터 분류에 따라 논리적 액세스를 제한할 것을 요구합니다. CC6.6은 데이터베이스 쓰기나 외부 API 호출 등 상승된 도구 권한을 가진 에이전트에 적용됩니다. 테넌트 간에 사용되는 공유 API 키는 일반적으로 CC6.1 결함으로 표시됩니다.

멀티테넌트 에이전트 시스템에서 JWT 토큰 TTL 취약점은 무엇입니까?

에이전트 도구 호출의 테넌트 컨텍스트에 사용되는 JWT 액세스 토큰은 일반적으로 3,600초(1시간) 후에 만료됩니다. 테넌트A에 발행된 토큰이 잘못 캐시되거나, 인프라 버그로 공유되거나, 디버그 로그에 기록되면 감지 없이 전체 TTL 기간 동안 테넌트A로 귀속된 인증 호출에 사용될 수 있습니다. 완화에는 TTL 300초 이하의 단기 토큰, 활성 테넌트별 토큰 취소 레지스트리, 작업별 토큰 순환의 세 가지 제어가 필요합니다.

멀티테넌트 에이전트를 위한 Kubernetes 네임스페이스 격리는 어떻게 작동합니까?

Kubernetes 네임스페이스 격리는 네 가지 구성 요소를 통해 실행 격리를 제공합니다: 테넌트별 전용 네임스페이스, 테넌트별 ServiceAccounts와 네임스페이스 스코프의 RoleBindings를 가진 RBAC, 기본 거부 및 필요한 외부 엔드포인트에 대한 명시적 허용 목록을 가진 NetworkPolicy, 네임스페이스별 컴퓨팅 제한을 가진 ResourceQuota. 네임스페이스 격리는 멀티테넌시의 컴퓨팅 차원을 해결하며 테넌트별 자격 증명 스코핑 및 메모리 분할과 결합해야 합니다.

멀티테넌트 에이전트 시스템에서 공유 벡터 저장소 안티패턴은 무엇입니까?

스토리지 클라이언트 계층에서 주입된 쿼리별 테넌트 필터 없이 공유 벡터 저장소를 사용하는 것이 주요 OWASP LLM06 유출 벡터입니다. 올바른 구현에는 각 쓰기에 tenant_id 메타데이터 필드와 각 쿼리에서 벡터 저장소 클라이언트 계층에서 주입된 메타데이터 필터가 필요합니다. 엄격한 컴플라이언스 요구사항에는 테넌트별 네임스페이스나 별도의 인덱스가 스토리지 주소 계층에서 경계를 적용합니다.

OpenLegion은 어떻게 테넌트 격리를 적용합니까?

OpenLegion은 세 가지 인프라 계층 메커니즘으로 테넌트 격리를 적용합니다: 프로젝트별 자격 증명 볼트 스코핑(Zone 2는 에이전트 제공 파라미터가 아닌 메시 세션의 인증된 프로젝트 컨텍스트를 사용하여 $CRED{} 핸들을 해결합니다; 크로스 프로젝트 자격 증명 해결은 아키텍처적으로 불가능합니다), 블랙보드 네임스페이스 ACL(에이전트는 메시 수퍼바이저에 의해 적용된 프로젝트의 키 접두사에 대해서만 읽기 및 쓰기 권한을 가집니다), 기본적으로 차단된 크로스 프로젝트 에이전트 메시징.

에이전트 플랫폼의 세 가지 멀티테넌시 아키텍처 모델은 무엇입니까?

세 가지 멀티테넌시 모델은 서로 다른 격리 보장과 비용 프로파일을 가집니다: 사일로 모델(Shared-Nothing)은 각 테넌트에 완전히 전용 인프라를 제공합니다. 풀 모델은 모든 인프라를 공유하며 애플리케이션 계층에서만 격리를 적용합니다. 브리지 모델은 테넌트별 자격 증명 볼트 스코프와 메모리 네임스페이스 ACL을 통해 제어 플레인에서 격리를 적용하면서 컴퓨팅 인프라를 공유합니다. 브리지 모델이 B2B SaaS의 권장 기본값입니다.