멀티 에이전트 시스템 (Parts 6-8)이 기능적으로 견고해지면, 모든 기업 보안 검토에서 공통적으로 제기되는 질문은 동일합니다. 에이전트가 실제로 신뢰할 수 있는 네트워크 경로를 통해, 오직 허가된 작업만 수행하고 있는지, 그리고 6개월 뒤 누군가 "이 에이전트가 무엇을 왜 했는가?"라고 물었을 때 입증 가능한 감사 추적 (audit trail)이 있는지 어떻게 알 수 있을까요? 이 포스트에서는 프라이빗 네트워킹 (private networking), Entra Agent ID, 그리고 감사 추적 (audit trail) 설계를 다룹니다.

제로 트러스트 (Zero-trust) 네트워크 경계

프라이빗 엔드포인트 (Private endpoints): 트래픽을 퍼블릭 인터넷으로부터 격리하기

기본적으로 애플리케이션에서 Foundry Models로의 호출은 퍼블릭 인터넷을 통해 전달됩니다 (암호화되지만, 공개적으로 라우팅 가능함). 규제 대상 워크로드의 경우, 대신 Private Link를 통해 라우팅하십시오:

resource foundryPrivateEndpoint 'Microsoft.Network/privateEndpoints@2023-04-01' = {
  name: 'pe-foundry-project'
  location: location
...

이를 프로젝트 수준의 Managed VNET과 결합하여, 컴퓨팅(Part 7에서 에이전트 코드를 실행하는 오케스트레이션 레이어)으로부터의 아웃바운드 호출이 프라이빗 네트워크 경계를 절대 벗어나지 않도록 하십시오. 확인해야 할 장애 모드(failure mode)는 다음과 같습니다: 종속성 라이브러리(예: 텔레메트리 콜백을 수행하는 패키지 등)가 의도한 네트워크 경계를 완전히 우회하여 예상치 못한 퍼블릭 호출을 수행하는 경우입니다. 여러분의 코드뿐만 아니라 종속성 라이브러리의 네트워크 동작도 감사(audit)하십시오.

Entra Agent ID: 단순한 서비스가 아닌 자율 에이전트를 위한 ID

전통적인 관리 ID (managed identity)는 예측 가능한 동작과 정해진 일정에 따라 API를 호출하는 서비스를 위해 설계되었습니다. Entra Agent ID는 독립적인 결정을 내리는 자율 에이전트(autonomous agents)를 위해 이 모델을 구체적으로 확장합니다. 이 ID 모델은 단순히 "이 호출이 인증되었는가?"를 넘어 "이 에이전트가 이 특정 컨텍스트에서 이 특정 작업을 수행할 권한이 있는가?"에 답할 수 있어야 합니다.

from azure.identity import DefaultAzureCredential

class AgentIdentityContext:
...

핵심 설계 포인트: 멀티 에이전트 체인 (multi-agent chain)의 각 에이전트는 모든 에이전트가 하나의 광범위한 서비스 주체 (service principal)를 공유하는 대신, 자신만의 명시적인 allowed_actions 목록을 가진 고유한 범위 지정된 ID (scoped identity)를 부여받습니다. 이는 탈취되거나 오작동하는 환불 에이전트가 (프롬프트 인젝션 (prompt-injected) 등으로 인해 악의적으로) 사기 탐지 에이전트에게만 허용된 범위의 작업을 실수로(또는 의도적으로) 호출할 수 없음을 의미합니다.

보안 제어 (Security control)	방어 대상	적용 위치
Private Link / Managed VNET	신뢰할 수 있는 네트워크 경계를 벗어나는 트래픽	네트워크 계층
...

데이터 레지던시 (Data residency) 및 고객 관리 키 (Customer-managed keys)

프라이빗 네트워킹 (Private networking)과 ID는 "누가 이 시스템에 접근할 수 있고 누구로서 행동하는가"를 다룹니다. 이와 별개로 기업에서 흔히 요구되는 또 다른 사항은 "이 데이터가 물리적으로 어디에 존재하며, 누가 암호화 키를 보유하는가"입니다. 데이터 레지던시 (data residency)와 고객 관리 키 (CMK)는 이 문제를 다루며, 네트워킹과 ID 처리에만 집중하고 멈춰버린 팀들이 놓치기 쉬운 부분입니다.

데이터 레지던시의 경우, Foundry 프로젝트, 그 기반이 되는 Azure AI Search 인덱스, 그리고 Foundry IQ를 지원하는 모든 스토리지(storage)가 실제로 어느 리전 (region)에서 실행되는지 확인하십시오. 명시적으로 구성하지 않으면 기본값이 주 애플리케이션과 다른 리전으로 설정될 수 있으며, 이는 데이터 주권 (data-sovereignty) 요구 사항(GDPR 관련 의무, 거주 조항이 포함된 정부 계약 등)을 따르는 워크로드에 심각한 문제가 될 수 있습니다.

resource foundryProject 'Microsoft.CognitiveServices/accounts/projects@2024-10-01' = {
  name: 'your-project'
  location: 'westeurope'  // 데이터 레지던시 요구 사항과 명시적으로 일치해야 합니다 —
...

고객 관리 키 (Customer-managed keys, CMK)의 경우, 기본값은 Microsoft 관리 저장 시 암호화 (encryption at rest)입니다. 이는 대부분의 워크로드에는 적절하지만, 조직이 직접 제어하는 키를 회전(rotating)하거나 삭제함으로써 데이터에 대한 액세스 권한을 취소할 수 있는 능력을 요구하는 일부 규제 산업에는 불충분합니다.

resource foundryAccount 'Microsoft.CognitiveServices/accounts@2024-10-01' = {
  properties: {
    encryption: {
...

이 두 가지 사항은 기본 설정으로 데이터가 이미 기록된 후에 쉽게 사후 적용(retrofit)할 수 있는 것이 아닙니다. 데이터 레지던시 (data residency)와 CMK는 Foundry 프로젝트의 초기 프로비저닝 (provisioning) 단계에서 명시적으로 내려야 하는 결정이지, "보안 검토 전에 구성하면 되겠지"라고 남겨두어서는 안 되는 사항입니다. 프로비저닝 시점에 컴플라이언스 (compliance) 요구 사항이 아직 확정되지 않았다면, 플랫폼 기본값보다는 더 엄격한 구성(명시적 리전 고정, CMK)을 기본으로 선택하십시오. 나중에 제한 사항을 완화하는 것이 이미 기록된 데이터를 소급하여 더 엄격한 구성으로 마이그레이션하는 것보다 훨씬 쉽기 때문입니다.

실제로 유효한 감사 추적 (Audit trails)

"에이전트가 환불 API를 호출함"이라고 적힌 로그 한 줄은 감사 추적 (audit trail)이 아닙니다. 누군가가 "왜 에이전트가 이 환불을 결정했는가?"라고 물었을 때, 단순히 동작(action)뿐만 아니라 그 근거(reasoning)가 캡처되어 있어야 합니다.

import json
import time

...

단순한 동작 로그에는 없는, 진정한 감사 추적에 필요한 세 가지 요소는 다음과 같습니다: 결정 시점에서의 모델의 명시된 추론 (stated reasoning) (결과뿐만 아니라), 권한 부여 컨텍스트 (authorization context) (어떤 ID/정책이 해당 동작을 허용했는지), 그리고 입력값을 고려했을 때 왜 그 결정이 타당했는지 재구성할 수 있을 만큼 충분한 **상태 스냅샷 (state snapshot)**입니다. 이때 반드시 개인정보(PII) 원본 전체를 장기적으로 저장할 필요는 없으며, 입력 컨텍스트를 해싱(hashing)하는 것이 감사 가능성 (auditability)과 데이터 최소화 (data minimization) 사이에서 흔히 취할 수 있는 적절한 절충안입니다.

해피 패스(happy path)가 아닌 보안 경계 테스트하기

설정한 경계를 의도적으로 위반하려고 시도하는 테스트를 작성하십시오:

• 에이전트의 allowed_actions 목록에 없는 액션(action) 호출을 시도하고, 해당 요청이 거부 및 로그에 기록되는지 확인하십시오.
• 퍼블릭 엔드포인트(public endpoint)로 연결되는 요청을 시도하고, 네트워크 경계(network boundary)가 이를 차단하는지 확인하십시오.
• 에이전트가 권한이 없는 액션에 대해 권한이 있다고 주장하도록 유도하는 프롬프트 인젝션 (prompt-injection) 시도를 시뮬레이션하고, 실행을 제어하는 것이 모델 자체의 주장(claim)이 아니라 권한 확인 (authorization check) 단계임을 확인하십시오.

마지막 포인트가 가장 중요합니다. 권한 부여 (authorization)는 모델이 출력 텍스트에서 자신의 권한에 대해 무엇이라고 말하는지에 기반해서는 안 되며, 반드시 ID의 실제 허용된 액션 목록에 따라 코드 수준에서 강제되어야 합니다.

참고 문헌 (References)

• Azure AI Foundry를 위한 Private Link: https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/configure-private-link
• Foundry 프로젝트를 위한 관리형 VNET (Managed VNET): https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/configure-managed-network
• Microsoft Entra Agent ID: https://learn.microsoft.com/en-us/entra/identity/agent-identity/overview
• 제로 트러스트 (Zero Trust) 아키텍처 가이드라인: https://learn.microsoft.com/en-us/security/zero-trust/zero-trust-overview