AI Agent Governance vs IAM vs DLP vs API Gateways: 각각의 역할은 무엇인가

IAM, DLP, 그리고 API 게이트웨이(API gateways)는 조직의 보안 스택(security stack)에서 필수적인 부분입니다. 하지만 이 중 그 어느 것도 AI 에이전트(AI agents)를 관리하지는 않습니다. IAM은 누가 시스템에 접근할 권한이 있는지를 제어합니다. DLP는 규제 대상 데이터가 잘 정의된 네트워크 및 엔드포인트 경계를 통해 어떻게 이동하는지를 제어합니다. API 게이트웨이는 HTTP 트래픽을 검사합니다. AI 에이전트는 이 도구들이 구축된 모든 가정을 깨뜨립니다. 에이전트는 비결정론적(non-deterministically)으로 행동하고, HTTP만큼이나 자주 stdio를 통해 통신하며, 게이트웨이가 전혀 볼 수 없는 도구(tools)를 호출하고, 권한 부여와 실행 사이에 교체되거나 변조될 수 있습니다. AI 에이전트 거버넌스(AI agent governance)는 이 간극을 메우는 계층이며, 기존 스택을 대체하는 것이 아니라 기존 스택과 나란히 실행됩니다.

이 비교는 다음과 같은 특정 질문에 답하려는 보안 및 플랫폼 리더들을 위한 것입니다: "우리는 이미 IAM, DLP, 게이트웨이를 갖추고 있습니다. AI 에이전트를 위한 무언가가 여전히 필요할까요?" 짧은 답변은 '예'이며, 이 글은 정확히 왜, 그리고 어디에 필요한지를 보여줍니다.

짧은 비교

제어 항목	관리 대상	AI 에이전트에 대해 부족한 점
IAM	누가 시스템에 접근할 수 있는가	에이전트 바이너리(binary)가 승인된 것과 일치하는지 확인할 수 없음; 도구 호출(tool calls)을 관리할 수 없음; 인간 형태의 접근(human-shaped access)을 위해 설계됨
...
이 글의 나머지 부분에서는 각 행을 자세히 설명합니다.

IAM이 AI 에이전트에 대해 수행하는 것(과 수행하지 않는 것)

IAM은 인간의 신원(identity)과 권한 부여(authorization)를 제어합니다: 누가 로그인할 수 있는지, 어떤 역할을 보유하는지, 어떤 시스템에 접근할 수 있는지를 제어합니다. 일부 IAM 플랫폼은 이제 서비스 계정에 발급되는 자격 증명(credentials)과 수명이 짧은 토큰(short-lived tokens)을 통해 머신 아이덴티티(machine identity)도 제공합니다.

에이전트에게 IAM이 필요한 경우:

에이전트가 호출하는 시스템 및 서비스에 신원(identities)을 발급할 때
해당 자격 증명에 대해 최소 권한 원칙(least privilege)을 강제할 때
행동이 변할 때 액세스를 순환(rotating)하거나 취소(revoking)할 때

IAM이 부족한 경우:

에이전트 자체를 검증할 수 없습니다. IAM 토큰은 서비스가 API를 호출할 수 있도록 권한을 부여합니다. 하지만 API를 호출하는 에이전트 바이너리(agent binary)가 보안 팀이 승인한 바로 그 바이너리인지까지는 검증하지 못합니다. 변조(Tampering)는 권한 부여(authorization)와 실행(execution) 사이에서 발생하며, IAM은 이를 감지할 수 없습니다.
도구 호출(tool calls)을 제어하지 못합니다. 에이전트가 권한을 부여받고 나면, IAM은 해당 에이전트가 어떤 도구를, 어떤 인자(arguments)를 사용하여, 어떤 대상(targets)에 대해 호출하는지 알 수 없습니다.
결정론적 행위자(deterministic actors)를 가정합니다. IAM은 안정적인 권한 세트를 가진 사용자나 서비스를 모델링합니다. 반면 에이전트는 비결정론적(non-deterministic)이며, 동일한 신원(identity)을 가지고 있더라도 호출할 때마다 서로 다른 행동을 취할 수 있습니다.
에이전트 특화 감사 증거(agent-specific audit evidence)를 생성하지 않습니다. IAM 로그는 누가 인증(authenticated)했는지를 기록합니다. 어떤 모델이 로드되었는지, 어떤 정책(policy)이 적용 중이었는지, 또는 어떤 도구 호출이 거부되었는지는 기록하지 않습니다.

IAM은 스택(stack) 내에 머물러 있습니다. 단지 에이전트를 거버넌스(govern)하지 못할 뿐입니다.

DLP가 AI 에이전트에 대해 수행하는 것(및 수행하지 못하는 것)

DLP는 규제 대상 데이터가 이동하는 방식을 제어합니다. DLP는 파일, 이메일, 네트워크 트래픽 및 엔드포인트(endpoint) 작업을 검사하여 정책(사회보장번호(SSN), 개인건강정보(PHI), 소스 코드, 고객 기록 등)과 일치하는 항목을 찾아내고, 위반 사항에 대해 차단하거나 경고를 보냅니다.

에이전트에 있어 DLP가 필요한 경우:

전통적인 채널을 통해 조직 외부로 규제 대상 데이터가 유출되는 것을 포착할 때
파일 업로드, 이메일 첨부 파일 및 관리되는 엔드포인트(managed endpoints)에 대한 정책을 강제할 때

DLP가 부족한 부분:

도구 호출에 대한 가시성 부재 (No visibility into tool invocations). 에이전트가 "내부 문서를 검색하고 일치하는 콘텐츠를 반환"하기 위해 MCP 서버 도구를 호출할 때, DLP는 해당 호출, 인자(arguments), 또는 응답을 확인하지 못합니다.
stdio에 대한 기본 요소 부재 (No primitives for stdio). 대부분의 MCP 통신은 에이전트 프로세스와 MCP 서버 간의 stdio를 통한 로컬 통신입니다. DLP는 해당 트래픽을 검사하지 않습니다.
프롬프트 또는 완성문 검사 부재 (No prompt or completion inspection). DLP 규칙은 잘 정돈된 데이터(well-formed data) 내의 패턴을 매칭합니다. 도구 호출을 통해 에이전트가 데이터를 유출하도록 유도하는 사용자 프롬프트 인젝션(prompt injection)이나, 규제 대상 콘텐츠를 의역하여 포함하는 완성문(completion)은 잡아내지 못합니다.
아티팩트 출처 확인 불가 (No artifact provenance). DLP는 데이터를 처리하는 모델이나 에이전트가 승인된 레지스트리(registry)로부터 왔는지 검증하지 않습니다.

DLP는 설계된 목적에 따라 데이터 이동 중(data-in-motion)인 사례를 포착합니다. 에이전트는 DLP가 설계되지 않은 데이터 실행 중(data-in-action)인 사례를 생성합니다.

API 게이트웨이가 AI 에이전트를 위해 수행하는 것(과 수행하지 못하는 것)

API 게이트웨이는 라우팅(routing), 속도 제한(rate limiting), 인증(authentication), 페이로드 검사(payload inspection)와 같은 HTTP 트래픽을 관리합니다. 일부 업체들은 이제 프롬프트 로깅(prompt logging), 기본적인 콘텐츠 필터링, 그리고 가드레일(guardrail) 제공업체와의 통합 기능을 갖춘 "AI 게이트웨이" 기능을 마케팅하고 있습니다.

에이전트를 위해 API 게이트웨이가 필요한 경우:

에이전트 트래픽을 LLM 제공업체로 라우팅
속도 제한(Rate limiting) 및 할당량 관리(quota management)
모델 API에 대한 인증
LLM 요청 및 응답의 중앙 집중식 로깅

API 게이트웨이가 부족한 부분:

트래픽은 보지만 액션(actions)은 보지 못합니다. 대부분의 에이전트 활동(도구 호출(tool invocations), MCP 호출, 로컬 모델 추론, 에이전트 간 통신)은 HTTP 게이트웨이를 통과하지 않습니다.
콘텐츠 검사가 얕습니다. 많은 게이트웨이가 프롬프트(prompt) 콘텐츠만 검사합니다. 도구 인자(tool arguments), MCP 서버 입출력, 에이전트 간 메시지는 포함되지 않습니다.
실패 시 기본 동작이 허용(allow)입니다. 게이트웨이의 가드레일(guardrail) 통합 과정에서 오류가 발생하거나 타임아웃이 발생할 때, 가장 흔한 운영 환경의 동작은 요청을 그대로 통과시키는 것입니다. 이는 기본적으로 페일 오픈(fail-open) 방식입니다.
아티팩트(artifact) 검증이 없습니다. 게이트웨이는 트래픽 반대편에 있는 모델이나 에이전트가 승인된 레지스트리(registry)에서 온 것인지 확인하지 않습니다.
변조 방지 감사(tamper-evident audit)가 불가능합니다. 게이트웨이 로그는 벤더의 SaaS 또는 고객의 로깅 스택에 저장됩니다. 이 로그들은 암호학적으로 체인(cryptographically chained)되어 있지 않으며, 감사관이 기대하는 형태의 증거로 내보낼 수 없습니다.

API 게이트웨이는 유용한 에이전트 인프라의 일부입니다. 하지만 거버넌스(governance) 솔루션은 아닙니다.

다른 솔루션이 다루지 못하는 AI 에이전트 거버넌스의 범위

AI 에이전트 거버넌스는 에이전트 주변의 경계(perimeter)가 아닌, 에이전트 자체에 집중하는 계층입니다.

기능	IAM	DLP	API 게이트웨이	AI 에이전트 거버넌스
에이전트 아티팩트의 출처(provenance) 및 무결성 검증	아니요	아니요	아니요	예
...

이것이 실제 격차(gap)입니다. 에이전트 거버넌스는 다른 도구들의 다른 버전이 아닙니다. 그것은 서로 다른 계층입니다.

구체적인 예시: 에이전트가 결제를 수행할 때

환불 요청을 처리하는 에이전트를 가정해 보겠습니다. 사용자가 상황을 설명하면, 에이전트는 환불 여부를 결정한 뒤 payments.refund(account, amount)를 호출합니다.

계층	관찰 내용	차단 가능 항목
IAM	에이전트의 서비스 계정(service account)이 결제 API를 호출할 권한이 있음	권한이 없는 서비스 계정
...

IAM, DLP, 그리고 게이트웨이는 틀린 것이 아닙니다. 단지 이 질문에 답하도록 설계되지 않았을 뿐입니다. AI 에이전트 거버넌스는 이 질문을 위해 설계되었습니다.

"게이트웨이에 규칙을 그냥 작성하면 된다"가 보통 실패하는 이유

팀들이 에이전트 거버넌스 (Agent Governance)를 기존의 API 게이트웨이 (API Gateway)로 밀어 넣으려고 할 때, 세 가지 문제가 나타납니다.

1. 게이트웨이는 에이전트 동작의 대부분을 보지 못합니다. 로컬 도구 호출 (Local tool calls), stdio 통신, MCP 트래픽, 그리고 온디바이스 추론 (On-device inference)은 게이트웨이에 도달하지 않습니다. 게이트웨이는 오직 자신을 통과하는 부분만을 거버넌스할 수 있습니다.

2. 게이트웨이 정책 언어는 에이전트의 의사결정을 위해 구축되지 않았습니다. 속도 제한 (Rate limits)이나 HTTP 헤더 검사는 "이 에이전트가 이러한 조건 하에서 이러한 인자 (Arguments)로 이 도구를 호출하는 것이 허용되는가"라는 질문과 깔끔하게 매칭되지 않습니다.

3. 게이트웨이의 장애 모드 (Failure modes)는 거버넌스 관점에서 잘못되었습니다. 가드레일 (Guardrail) 통합 과정에서 오류가 발생할 때, 대부분의 게이트웨이는 요청을 차단하기보다 허용하도록 설정되어 있습니다. 높은 위험도가 따르는 에이전트 작업에서 '기본 허용 (Default-allow)'은 안전을 위해 설계되지 않은 도구의 전형적인 장애 모드입니다.

게이트웨이는 게이트웨이로서의 역할에는 충실합니다. 하지만 에이전트 거버넌스 정책을 작성하기에 적합한 장소는 아닙니다.

네 가지 계층이 결합되는 방식

제대로 작동하는 스택은 이 네 가지를 모두 사용합니다.

**IAM (Identity and Access Management)**은 인간과 에이전트가 호출하는 시스템에 신원 (Identity)을 부여합니다. 토큰은 수명이 짧고 최소 권한 (Least-privilege) 원칙을 따릅니다.
**DLP (Data Loss Prevention)**는 관리되는 엔드포인트와 전통적인 채널에서 데이터 이동 중 제어 (Data-in-motion controls)를 계속해서 집행합니다.
**API 게이트웨이 (API Gateway)**는 에이전트 트래픽을 LLM 제공업체로 라우팅하고, 속도 제한을 적용하며, HTTP 계층에서 로깅을 중앙 집중화합니다.
**AI 에이전트 거버넌스 (AI Agent Governance)**는 에이전트와 가장 가까운 곳에 위치합니다. 아티팩트 (Artifacts)가 로드되기 전에 검증하고, 모든 호출 시 도구 수준의 정책을 집행하며, 의미론적 수준 (Semantic level)에서 콘텐츠를 검사하고, 인간의 승인을 캡처하며, 에이전트가 실행되는 모든 환경에 걸쳐 변조 방지 기능이 있는 감사 로그 (Tamper-evident audit logs)를 생성합니다.

각 계층은 서로 다른 질문을 다룹니다. 이들이 함께 모여 조직에 "무엇이 실행되고 있는가, 무엇을 하고 있는가, 그리고 무엇을 했는가"에 대한 방어 가능한 답변을 제공합니다.

이 계층들을 비교할 때 발생하는 흔한 실수

"AI 게이트웨이 (AI gateway)"를 구매하고 그것을 거버넌스 (governance)라고 부르는 것. 게이트웨이는 전체 그림의 일부일 뿐, 전체 그림이 아닙니다.
IAM의 범위가 에이전트 (agents)까지 확장된다고 가정하는 것. 그렇지 않습니다. 머신 아이덴티티 (Machine identity)는 자격 증명 (credentials)을 제어할 뿐, 에이전트를 검증하거나 도구 호출 (tool calls)을 거버넌스하지 않습니다.
DLP가 stdio를 커버할 것이라고 기대하는 것. DLP는 로컬 에이전트와 MCP 간의 통신을 위해 구축되지 않았으며, 그 통신의 대부분을 감지하지 못할 것입니다.
아티팩트 검증 (artifact verification)을 건너뛰는 것. 기존의 세 계층 모두 실행 중인 아티팩트가 사용자가 승인한 것임을 신뢰합니다. 그 중 어느 것도 이를 검증하지 않습니다.
SaaS 연결이 필요한 거버넌스 도구를 선택하는 것. 연결이 끊겼을 때 거버넌스 계층이 'Fail Open' (오류 시 허용) 또는 'Fail Closed' (오류 시 차단) 방식으로 작동한다면, 에어갭 (air-gapped) 또는 DDIL (Disconnected, Disrupted, Intermittent, and Limited) 환경에서는 거버넌스를 수행할 수 없습니다.

Jozu가 기존 스택 옆에서 어떻게 기능하는가

Jozu는 IAM, DLP 또는 API 게이트웨이를 대체하지 않습니다. 대신 이들과 나란히 실행되며, 이들이 설계되지 않은 영역을 보완합니다.

Jozu 구성 요소	기존 계층 옆에서의 역할
Jozu Hub	큐레이션된 레지스트리 (registry), 스캐닝 (scanning), 서명 (signing) 및 아티팩트 정책 (artifact policy). 어떤 에이전트와 MCP 서버가 승인되었는지에 대한 신뢰할 수 있는 원천 (source of truth)으로서 IAM 하단에 위치합니다.
Jozu Agent Guard	AI를 위한 보안 런타임 (runtime): 도구 수준의 정책 강제 (tool-level policy enforcement), 콘텐츠 인식 검사 (통합된 Bifrost 게이트웨이를 통해), 인간 참여형 승인 (human-in-the-loop approvals) 및 변조 방지 감사 (tamper-evident audit). API 게이트웨이, DLP 제품 및 IAM 플랫폼과 나란히 작동합니다.

이러한 조합을 통해 보안 팀은 레지스트리와 런타임 전반에 걸쳐 단일 정책 언어와 단일 감사 체인을 가질 수 있으며, 여기에는 IAM, DLP 및 게이트웨이가 도달할 수 없는 환경인 개발자 노트북, 엣지 디바이스 (edge devices), 에어갭 클러스터 및 DDIL 네트워크가 포함됩니다.

Jozu Agent Guard 살펴보기 →
데모 요청하기 →

자주 묻는 질문 (Frequently asked questions)

IAM이 머신 아이덴티티(Machine Identity)를 통해 AI 에이전트 거버넌스(AI agent governance)를 커버할 수 있나요?
아니요. 머신 아이덴티티(Machine identity)는 서비스에 자격 증명(Credentials)을 발급합니다. 에이전트 아티팩트(Agent artifact)를 검증하거나, 도구 호출(Tool calls)을 관리하거나, 에이전트 전용 감사 증거(Audit evidence)를 생성하지는 않습니다. IAM과 에이전트 거버넌스는 상호 보완적으로 작동하며, 하나가 다른 하나를 대체할 수 없습니다.

AI 게이트웨이(AI gateway)가 AI 에이전트 거버넌스와 동일한 것인가요?
아니요. 게이트웨이는 LLM 제공업체로 향하는 HTTP 트래픽을 검사합니다. AI 에이전트 거버넌스는 아티팩트 검증(Artifact verification), 도구 수준 정책(Tool-level policy), 콘텐츠 검사(Content inspection), 인간의 승인(Human approvals), 그리고 게이트웨이가 전혀 볼 수 없는 환경을 포함하여 에이전트가 실행되는 모든 환경에서의 감사(Audit)를 다룹니다.

DLP가 규제 대상 데이터(Regulated data)를 다루는 AI 에이전트를 커버할 수 있나요?
부분적으로만 가능합니다. DLP는 전통적인 채널을 통해 조직 외부로 유출되는 규제 대상 데이터를 포착합니다. 하지만 로컬 도구 호출(Local tool invocations), stdio MCP 트래픽, 프롬프트 기반 유출(Prompt-driven leakage), 또는 의역된 완성문(Paraphrased completions)은 감지하지 못합니다.

각 계층에서 정책(Policy)은 어디에 존재하나요?
IAM 정책은 IAM 플랫폼에 존재합니다. DLP 정책은 DLP 제품에 존재합니다. API 게이트웨이 정책은 게이트웨이에 존재합니다. AI 에이전트 거버넌스 정책은 이상적으로 공유되고 버전 관리되며 서명된 아티팩트 형식(OCI가 가장 일반적인 선택임)으로 존재하여, 에이전트가 실행되는 어디에서나 강제 적용될 수 있어야 합니다.

기존의 IAM, DLP, 게이트웨이 제품에서 AI 기능을 그냥 켜기만 하면 되나요?
벤더(Vendors)들이 기존 제품에 AI 기능을 추가하고 있지만, 구조적인 한계는 동일합니다. IAM은 여전히 에이전트 아티팩트를 검증할 수 없습니다. DLP는 여전히 stdio를 볼 수 없습니다. 게이트웨이는 여전히 HTTP만 볼 수 있습니다. 기존 도구의 AI 기능은 특정 유스케이스(Use cases)를 개선할 뿐, 에이전트 거버넌스의 격차(Gap)를 메우지는 못합니다.

CISO는 어떤 계층을 담당해야 하나요?
가장 일반적으로 IAM은 ID 및 액세스(Identity and access) 팀이, DLP는 데이터 보안(Data security) 팀이, API 게이트웨이는 플랫폼(Platform) 팀이, 그리고 AI 에이전트 거버넌스는 보안 아키텍처(Security architecture) 또는 AI 보안(AI security) 부서가 담당합니다. CISO는 이 네 가지 모두에 걸친 정책을 총괄합니다.

AI 에이전트 거버넌스 (AI agent governance)는 아직 실질적인 제품 카테고리인가요?
네, 그렇습니다. AI 에이전트 거버넌스는 고유의 구매자(보안 아키텍처 및 AI 보안 리더), 고유의 평가 기준(아티팩트 검증 (artifact verification), 도구 정책 (tool policy), 콘텐츠 인식 (content awareness), 감사 (audit)), 그리고 새롭게 등장하는 벤더 생태계를 갖추고 있습니다. 2026년의 변화는 조직들이 이를 기존 카테고리의 확장판이 아닌, 별도의 독립된 항목으로 취급하기 시작했다는 점입니다.

관련 읽을거리: