AI 에이전트 거버넌스 (AI Agent Governance): 기업 팀을 위한 실무 가이드

AI 에이전트 거버넌스 (AI agent governance)는 조직이 어떤 AI 에이전트를 운영 환경(production)에 허용할지, 해당 에이전트가 어떤 도구와 데이터에 접근할 수 있는지, 그리고 에이전트가 취하는 모든 행동이 어떻게 기록되는지를 결정하는 정책, 통제 및 런타임 강제 집행 (runtime enforcement)의 집합입니다. 이는 에이전트가 실행되기 전(공급망 검증 (supply chain verification)), 실행 중(도구 및 콘텐츠에 대한 정책 강제 집행 (policy enforcement)), 그리고 사후(변조 방지 감사 로그 (tamper-evident audit logs))에 적용됩니다. 2026년의 보안 및 플랫폼 팀에게 에이전트 거버넌스는 더 이상 선택 사항이 아닙니다. 이제 에이전트는 행동을 취하고, 도구를 호출하며, 자금을 이동시키고, 기록 시스템 (systems of record)에 데이터를 작성합니다. IAM, DLP, API 게이트웨이는 이러한 용도로 설계되지 않았습니다.

이 가이드는 AI 에이전트 거버넌스가 무엇을 다루는지, 왜 기존의 보안 계층만으로는 충분하지 않은지, 그리고 연결된 환경, 온프레미스 (on-premises) 환경, 그리고 에어갭 (air-gapped) 환경 전반에 걸쳐 어떻게 작동하는 거버넌스 모델을 구축할 수 있는지 설명합니다.

AI 에이전트 거버넌스란 무엇인가?

AI 에이전트 거버넌스는 AI 에이전트의 전체 수명 주기를 제어하고 감사하는 관행으로, 이를 통해 조직은 언제든지 다음 세 가지 사항을 증명할 수 있습니다: 어떤 에이전트가 실행 중인지, 무엇을 할 수 있도록 허용되었는지, 그리고 실제로 무엇을 했는지입니다.

거버넌스는 세 가지 계층을 가집니다:

공급망 검증 (Supply chain verification). 에이전트나 이를 지원하는 아티팩트 (모델, MCP 서버, 기술, 정책)가 런타임 (runtime)에 도달하기 전에, 조직은 이들이 승인된 출처에서 왔는지, 보안 스캔을 통과했는지, 그리고 변조되지 않았는지를 확인합니다.
런타임 강제 집행 (Runtime enforcement). 에이전트가 실행되는 동안, 정책 엔진 (policy engine)은 조직이 정의한 규칙에 따라 모든 도구 호출 (tool invocation), 프롬프트 (prompt), 응답 (response)을 평가합니다.
감사 및 책임 (Audit and accountability). 모든 정책 결정, 도구 호출, 승인 및 콘텐츠 이벤트는 컴플라이언스 (compliance) 팀이 증거로 사용할 수 있는 변조 방지 체인 (tamper-evident chain)에 기록됩니다.

이 세 가지 계층이 모두 없다면 거버넌스는 깨지고 불완전해집니다. 런타임 정책이 없는 스캔된 에이전트는 여전히 해서는 안 될 행동을 할 수 있습니다. 공급망 확인이 없는 런타임 게이트웨이는 여전히 오염된 모델 (poisoned model)을 로드할 수 있습니다.

2026년에 AI 에이전트 거버넌스가 중요한 이유

지난 18개월 동안 발생한 세 가지 변화로 인해 에이전트 거버넌스 (Agent Governance)는 이론적인 관심사에서 운영 필수 요건으로 격상되었습니다.

이제 에이전트는 답변만 하는 것이 아니라 행동을 수행합니다. 모델은 문자열을 반환하지만, 에이전트는 도구 (Tools)를 호출하고, 데이터베이스를 쿼리하며, 티켓을 생성하고, 이메일을 보내며, 비용을 지출합니다. 오작동하는 에이전트의 폭발 반경 (Blast radius)은 운영적, 재무적, 규제적 측면에서 동시에 발생합니다.

공급망 공격 표면 (Supply chain attack surface)은 이미 악용되고 있습니다. 기록된 사례들은 수십만 명의 사용자에게 영향을 미쳤습니다:

mcp-remote의 CVE-2025-6514 (437K+ 다운로드, CVSS 9.6)는 조작된 OAuth 엔드포인트를 통해 원격 코드 실행 (Remote code execution)을 허용했습니다.
악성 Postmark MCP 서버가 모든 이메일을 공격자에게 몰래 숨은 참조 (BCC)로 보냈습니다.
Smithery 플랫폼 침해 사고로 인해 경로 탐색 (Path traversal)을 통해 호스팅된 3,000개 이상의 MCP 서버 자격 증명이 노출되었습니다.
GitHub MCP 서버의 프롬프트 인젝션 (Prompt injection)으로 인해 프라이빗 저장소 (Private repo) 데이터가 퍼블릭 PR로 유출되었습니다.

이것들은 이론적인 위험이 아닙니다. 이것들은 새로운 기준 (Baseline)입니다.

규제 기관들도 속도를 맞추고 있습니다. NIST AI RMF, EU AI Act, CMMC Level 2/3, HIPAA, SR 11-7, 그리고 21 CFR Part 11은 이제 모든 조직이 AI 시스템에 대해 출처 (Provenance), 접근 제어 (Access control), 인간의 감독 (Human oversight), 그리고 변조 방지 기록 (Tamper-evident records)을 입증할 것을 요구합니다. "우리는 모델 제공자를 신뢰한다"는 말은 감사 (Audit)에 대한 답변이 될 수 없습니다.

IAM, DLP, 그리고 API 게이트웨이가 충분하지 않은 이유

보안 책임자들은 때때로 기존의 스택이 이미 에이전트를 커버하고 있다고 가정합니다. 하지만 세 가지 이유로 그렇지 않습니다.

기존 계층	관리 대상	에이전트에 대해 부족한 점
IAM	누가 시스템에 접근할 수 있는가	에이전트 바이너리가 승인된 것과 일치하는지 검증할 수 없음; 권한 부여와 실행 사이에 변조가 발생함
...

에이전트는 결정론적 신원 (Deterministic identity), 잘 구성된 네트워크 경로 (Well-formed network paths), 그리고 인간 형태의 접근 패턴 (Human-shaped access patterns)이라는 각 도구의 핵심 가정을 깨뜨립니다. 에이전트는 비결정론적 (Non-deterministic)이며, 종종 HTTP 대신 stdio를 통해 통신하고, 단일 세션 내에서 서로 다른 역할을 채택할 수 있습니다.

에이전트 거버넌스 (Agent governance)는 IAM (Identity and Access Management), DLP (Data Loss Prevention) 또는 게이트웨이 (gateways)를 대체하지 않습니다. 대신 이들과 병행하여 작동하며, 기존 시스템들이 설계 단계부터 해결하지 못했던 공백을 메웁니다.

모든 AI 에이전트 거버넌스 프로그램에 필요한 5가지 통제 항목

실질적으로 작동하는 프로그램은 5가지 구체적인 통제 항목을 구축합니다. 각 항목은 에이전트 생명주기 (agent lifecycle)의 각 계층에 대응합니다.

1. 실행 전 아티팩트 검증 (Artifact verification before execution)

프로덕션 (production) 환경에 도달하는 모든 모델, 에이전트, 데이터셋, MCP 서버, 프롬프트 (prompt) 및 정책 (policy)은 반드시 다음 사항을 충족해야 합니다:

공개 소스가 아닌 신뢰할 수 있는 내부 레지스트리 (internal registry)에서 가져올 것
직렬화 공격 (serialization attacks), 백도어 가중치 (backdoored weights), 프롬프트 인젝션 (prompt injection), 데이터 포이즈닝 (data poisoning) 및 라이선스 위반 여부를 스캔할 것
로드 시점 (load time)에 암호학적으로 서명되고 검증될 것
스캔 결과와 출처 (provenance)를 설명하는 서명된 증명 (attestation)이 동반될 것

이 단계는 공급망 공격 (supply chain attacks)이 런타임 사고 (runtime incidents)로 이어지기 전에 차단하는 지점입니다.

2. 도구 수준의 액세스 제어 (Tool-level access control)

조직은 모든 에이전트에 대해 다음 사항을 정의합니다:

에이전트가 호출할 수 있는 도구 (tools)
허용되는 인자 (arguments) (예를 들어, database.query는 DELETE가 아닌 SELECT 문에 대해서만 허용될 수 있음)
속도 제한 (rate limiting) 또는 파괴적 작업 (destructive-operation) 확인이 필요한 조건
어떤 에이전트가 어떤 다른 에이전트에게 작업을 위임할 수 있는지

이러한 규칙은 세션 시작 시점뿐만 아니라 모든 도구 호출 시점에 평가됩니다.

3. 콘텐츠 인식 가드레일 (Content-aware guardrails)

인프라 수준의 격리 (isolation) 방식은 에이전트가 api.github.com에 연결되었다는 사실은 알려주지만, 에이전트가 공개 저장소 (public repository)로 자격 증명 (credentials)을 푸시하려고 시도했다는 사실은 알려주지 않습니다. 콘텐츠 인식 거버넌스는 다음을 검사합니다:

인젝션 시도를 위한 프롬프트 (prompt) 콘텐츠
PII (개인 식별 정보), PHI (개인 건강 정보) 또는 제한된 정보가 포함된 완료 (completion) 콘텐츠
민감한 데이터 유출 여부를 확인하기 위한 도구 인자 (tool arguments)
의미론적 수준 (semantic level)에서의 MCP 서버 요청 및 응답

4. 고위험 작업에 대한 인간 개입 승인 (Human-in-the-loop approvals for high-risk actions)

어떤 작업들은 절대로 자동 항법(autopilot) 상태로 실행되어서는 안 됩니다. 거버넌스 프로그램은 어떤 도구 호출(tool invocation)이 완료 전 인간의 서명을 필요로 하는지 정의하고, 해당 승인을 증명(attestation)으로 캡처하며, 이 증명을 감사 로그(audit log)와 연결합니다. 예시: 임계값 이상의 자금 이동, 프로덕션 데이터 삭제, 경영진을 대신한 외부 이메일 발송, 또는 고객 기록 수정 등입니다.

5. 변조 방지 감사 로깅 (Tamper-evident audit logging)

모든 정책 결정, 도구 호출(tool call), 승인 및 콘텐츠 이벤트는 암호학적으로 체인화된 로그(cryptographically chained log)에 기록됩니다. 이 체인은 과거의 항목을 변경하려는 모든 시도를 탐지할 수 있도록 보장합니다. 로그는 컴플라이언스(compliance) 팀이 감사, 사고 및 사후 분석(post-mortem) 중에 사용하는 증거가 됩니다.

AI 에이전트 거버넌스가 실제로 작동하는 방식

동일한 거버넌스 모델은 매우 다른 배포 패턴 전반에 걸쳐 작동해야 합니다.

Kubernetes 및 온프레미스 (on-prem). 정책은 서명된 OCI 아티팩트(KitOps ModelKit과 같은 형태)로 패키징되어 컨테이너 이미지를 이미 서비스하고 있는 동일한 레지스트리를 통해 배포됩니다. 보안 런타임(secure runtime)이 각 클러스터 내부에 위치하여, 검증된 정책을 가져오고 이를 로컬에서 강제합니다. 새로운 툴링(tooling)은 필요하지 않습니다.

에어갭 (Air-gapped) 및 DDIL 환경. 연방 정부, 국방, 의료 및 OT(운영 기술) 팀은 SaaS 컨트롤 플레인(control plane)에 의존할 수 없습니다. 정책은 연결이 없는 상태에서도 로컬에서 강제되어야 하며, 연결이 복구될 때 감사 로그가 동기화되어야 합니다. 또한, 클라우드 서비스에 도달할 수 없다는 이유로 런타임이 보안이 해제된 상태(fail open)로 작동하는 저하 모드(degraded mode)가 있어서는 안 됩니다.

데스크톱 및 엣지 (edge). 개발자는 노트북에서 에이전트를 실행합니다. 현장 팀은 엣지 디바이스에서 실행합니다. 거버넌스 모델은 클러스터 경계에서 멈추는 것이 아니라 이러한 엔드포인트(endpoint)까지 확장되어야 합니다.

멀티 벤더 에이전트 플릿 (Multi-vendor agent fleets). 대부분의 조직은 현재 하나 이상의 제공업체로부터 에이전트를 실행하고 있습니다. 거버넌스는 특정 벤더의 관리 환경에 고립되지 않고 모든 제공업체에 걸쳐 작동해야 합니다. 그렇지 않으면 조직은 제공업체의 수만큼 많은 감사 추적(audit trails)을 갖게 되며, 단일 진실 공급원(single source of truth)을 확보할 수 없게 됩니다.

단계별 가이드: AI 에이전트 거버넌스를 구축하는 방법

현재 실행 중인 항목을 인벤토리화(Inventory) 하세요. 지난 분기에 개발자들이 다운로드한 섀도우 AI (shadow AI)를 포함하여, 조직 전체에서 사용 중인 모든 에이전트 (agent), MCP 서버, 모델 (model), 도구 통합 (tool integration)을 매핑하세요. 보이지 않는 것은 거버넌스(governance)를 적용할 수 없습니다.
정책 분류 체계(policy taxonomy)를 정의하세요. 세 가지 정책 유형을 설정하세요: 아티팩트 정책 (artifact policy, 승인), 도구 정책 (tool policy, 런타임 호출), 그리고 가드레일 정책 (guardrail policy, 콘텐츠). 이를 코드로 인코딩하기 전에 먼저 평이한 언어로 첫 번째 버전을 작성하세요.
큐레이션된 내부 레지스트리 (internal registry)를 구축하세요. 승인된 모델, 에이전트, MCP 서버, 데이터셋 및 정책을 보안 스캐닝과 서명 기능이 포함된 하나의 레지스트리에 중앙 집중화하세요.
AI를 위한 보안 런타임 (secure runtime)을 배포하세요. 정책을 로컬에서 강제하고, 도구 수준의 액세스 제어 (access control)를 지원하며, 콘텐츠 인식 가드레일 (content-aware guardrails)을 통합하고, 변조 방지 감사 로그 (tamper-evident audit logs)를 기록하는 런타임을 선택하세요. 단순히 쉬운 환경뿐만 아니라, 가장 까다로운 배포 환경에서도 작동하는지 확인하세요.
가장 중요한 작업에 대해 인간의 승인 (human approvals) 프로세스를 연결하세요. 위험도가 가장 높은 상위 5개 도구부터 시작하세요. 프로그램이 성숙해짐에 따라 범위를 확장하세요.
감사 로그를 컴플라이언스 증거 (compliance evidence)와 연결하세요. 컴플라이언스 담당자는 수동 준비 과정 없이 NIST AI RMF, CMMC, EU AI Act, SR 11-7 또는 HIPAA 검토를 위한 변조 방지 증거를 내보낼 수 있어야 합니다.
정기적인 주기에 따라 정책을 검토하고 업데이트하세요. 새로운 도구, 새로운 에이전트, 그리고 새로운 위협이 매달 등장합니다. 정체된 정책은 쓸모없는 정책입니다.

피해야 할 일반적인 실수

거버넌스를 게이트웨이 문제로 취급하는 것. 게이트웨이는 트래픽을 확인하지만, 트래픽 뒤에서 실행되는 아티팩트 (Artifact)를 검증하지는 않습니다. 거버넌스는 에이전트가 로드되기 전부터 시작되어야 합니다.
모델 제공자의 거버넌스에 의존하는 것. 호스팅 제공업체는 자신의 클라우드 상에서 자체 에이전트를 관리합니다. 하지만 개발자가 Hugging Face에서 가져온 에이전트나 GitHub에서 가져온 MCP 서버까지 관리하지는 않습니다.
연결이 끊겼을 때 'Fail Open(보안을 해제하고 허용)'되는 도구를 선택하는 것. 만약 런타임 (Runtime)이 SaaS 제어 평면 (Control Plane)에 의존하고 있는데 연결이 끊어진다면, 보안 공백과 서비스 중단 사이에서 하나를 선택해야 하는 상황에 놓이게 됩니다.
직접 구축하는 것. ModelScan, Garak, Cosign, OPA 및 커스텀 감사 도구 (Audit tooling)를 하나로 엮는 작업은, 유지보수 비용을 솔직하게 계산했을 때 보통 2년 이상의 벤더 지출을 초과하게 됩니다.
액션을 체이닝 (Chaining) 없이 로그만 남기는 것. 사후에 수정될 수 있는 로그는 감사 추적 (Audit trail)이 될 수 없습니다.

AI 에이전트 거버넌스의 성공을 측정하는 방법

다음 지표들을 지속적으로 추적하십시오:

외부 소스 대비 큐레이션된 내부 레지스트리 (Internal Registry)에서 가져온 에이전트 및 MCP 서버의 비율
배포 전 아티팩트 정책 (Artifact policy)에 의해 차단된 아티팩트 수
런타임 시 도구 정책 (Tool policy)에 의해 거부된 도구 호출 (Tool invocation) 수
감사 및 컴플라이언스 (Compliance) 요청에 대한 증거 확보 평균 시간 (Mean time to evidence)
인간 참여 (Human-in-the-loop) 승인으로 보호되는 고위험 도구 호출의 커버리지
프로그램 시작 이후 해결된 거버넌스 격차 (Governance gaps)의 수

Jozu의 역할

Jozu는 이 문제를 해결하기 위해 만들어졌습니다. Jozu Hub는 관리 평면 (Management plane) 역할을 합니다. 모델, 에이전트, MCP 서버, 데이터셋 및 정책을 위한 큐레이션된 레지스트리를 제공하며, 5개의 통합 보안 스캐너, 서명된 에이전트 증명 (Agent attestations), 아티팩트 차이 분석 (Artifact diffing), 그리고 암호학적으로 체이닝된 감사 로그 (Audit logs)를 갖추고 있습니다. Jozu Agent Guard는 AI를 위한 보안 런타임 (Secure runtime)으로, 모든 도구 호출 시 정책을 강제하고, 통합된 Bifrost 게이트웨이를 통해 프롬프트 및 완료 콘텐츠 (Completion content)를 검사하며, 인간의 승인을 서명된 증명으로 캡처합니다. 또한 에어갭 (Air-gapped) 및 DDIL (Disconnected, Disrupted, Intermittent, and Limited) 환경에서도 타협 없이 작동합니다.

이러한 결합을 통해 조직은 레지스트리(Registry)부터 런타임(Runtime)에 이르기까지 하나의 정책 언어, 하나의 감사 체인(Audit chain), 그리고 하나의 플랫폼을 보유하게 됩니다. 5개의 서로 다른 벤더를 조합할 필요가 없으며, 통합 과정의 경계에서 거버넌스 공백이 발생하지 않습니다. 또한 연결이 끊겨도 보안이 해제되는 'Fail-open' 현상이 발생하지 않습니다.

Explore Jozu Agent Guard →
Request a demo →

자주 묻는 질문 (Frequently asked questions)

AI 거버넌스 (AI governance)와 AI 에이전트 거버넌스 (AI agent governance)의 차이점은 무엇인가요?
AI 거버넌스는 윤리, 책임성, 데이터 및 모델 리스크를 다루는 광범위한 조직적 관행입니다. AI 에이전트 거버넌스는 어떤 에이전트가 실행되는지, 어떤 도구(Tool)를 호출하는지, 그리고 그들의 행동이 어떻게 기록되는지를 제어하는 기술적 및 운영적 계층입니다. 전자가 원칙을 설정한다면, 후자는 그 원칙을 집행합니다.

AI 에이전트 거버넌스는 MLOps와 동일한 것인가요?
아니요. MLOps는 모델 개발 및 서빙 파이프라인 (Serving pipeline)을 관리합니다. 에이전트 거버넌스는 프로덕션 환경에서 에이전트의 보안, 정책 집행 및 감사 동작을 관리합니다. 대부분의 조직에는 두 가지 모두가 필요합니다.

IAM이나 DLP와 같은 기존 도구로 AI 에이전트를 커버할 수 있나요?
그 자체만으로는 불가능합니다. IAM은 에이전트 바이너리 (Agent binary)가 승인된 것과 일치하는지 검증할 수 없습니다. DLP는 에이전트와 MCP 서버 사이의 로컬 도구 호출 (Local tool invocations)을 감지하지 못합니다. 두 도구 모두 기술 스택에 포함되어야 하지만, 에이전트 거버넌스의 공백을 메울 수는 없습니다.