Kubernetes에서 실행 중인 귀하의 AI 에이전트가 현재 인터넷에 노출되어 있을 가능성

Microsoft Defender 연구원들이 이번 주에 컨테이너를 실행하는 모든 OpenClaw 사용자라면 반드시 확인해야 할 내용을 발표했습니다. Mage AI, kagent, AutoGen Studio, MCP 서버 등을 포함하여 Kubernetes에 배포된 많은 AI 및 에이전트 기반(agentic) 앱들이 취약하거나 누락된 인증과 함께 인터넷에 직접 노출되어 있다는 사실입니다.

이것이 귀하에게 무엇을 의미하는지 정확히 말씀드리겠습니다. 헤드라인은 실제 상황보다 더 무섭게 들릴 수 있지만, 이는 오늘 당장 해결해야 할 실제적인 문제입니다.

실제로 노출된 것

공격 표면(attack surface)은 제로 데이(zero-day) 취약점이 아닙니다. 바로 설정 오류(misconfiguration)입니다. 즉, 기본 설정으로 배포된 AI 에이전트 포드(pod)나, 에이전트가 신뢰할 수 있는 네트워크 외부에서 접근 가능하다는 점을 고려하지 않은 네트워크 정책(network policies)이 문제입니다.

공격 유형은 실재합니다:

• 노출된 에이전트 엔드포인트(endpoints)를 통한 원격 코드 실행 (Remote code execution)
• 취약한 인증을 사용하는 에이전트 API를 통한 자격 증명 탈취 (Credential theft)
• 인터넷 접속을 고려하여 설계되지 않은 에이전트 컨텍스트(contexts)로부터의 데이터 노출

Microsoft Defender 보고서의 핵심 문구는 다음과 같습니다: "공격자는 내부 프로토타입을 하룻밤 사이에 외부 공격 표면으로 바꿀 수 있습니다."

노출 여부를 확인하는 방법

귀하의 Kubernetes 클러스터에서 다음 명령어를 실행해 보십시오:

# 모든 AI/에이전트 포드와 그 네트워크 노출 상태를 찾습니다
kubectl get pods -A | grep -E 'mcp|agent|autogen|kagent|mage'

...

만약 해당 에이전트 포드 중 어느 하나라도 네트워크 정책 없이 default 네임스페이스(namespace)에 있다면, 별도의 증거가 없는 한 외부에서 접근 가능하다는 가정하에 조치해야 합니다.

구체적인 MCP 서버 문제

MCP 서버는 특히 영향을 많이 받는데, 그 이유는 에이전트로부터 연결을 받기 위해 네트워크 접속이 필요한 장기 실행 서비스(long-lived services)로 실행되는 경우가 많기 때문입니다. 만약 에이전트 포드로만 액세스를 제한하는 네트워크 정책 없이 MCP 서버를 Kubernetes에 배포했다면, 아마도 노출되어 있을 것입니다.

해결 방법:

# MCP 서버 배포에 다음을 추가하십시오
apiVersion: v1
kind: NetworkPolicy
...

이것은 2026.5.7 버전에 출시된 "노드별 기본 거부 경로 정책 (default-deny per-node path policy)"의 OpenClaw 버전입니다. 즉, 네트워크 계층에서 동일한 원칙을 적용하는 것입니다.

"모든 에이전트 앱을 프로덕션급으로 취급하라"는 말의 실제 의미

Microsoft Defender 팀은 에이전트 앱이 외부에서 접근 가능한 상태가 되는 즉시, 모든 에이전트 앱을 프로덕션급 (production-grade) 웹 서비스로 취급할 것을 권장합니다. 실질적인 시사점은 다음과 같습니다:

1. 모든 에이전트 엔드포인트에 인증 적용 — 내부 전용이라 할지라도 OAuth 또는 최소한 API 키 인증을 추가하십시오. 네트워크 격리만을 유일한 보안 계층으로 신뢰하지 마십시오.

2. 기본적인 네트워크 정책 (Network policies) 적용 — 네트워크 정책 없이 에이전트 포드 (agent pods)를 실행하고 있다면, 단 한 번의 설정 오류만으로도 외부 노출 위험에 처할 수 있습니다.

3. 정기적인 감사 (Regular audit) — 분기별 보안 검토 목록에 "AI/에이전트 포드 노출 여부 확인"을 포함하십시오. 이는 방화벽 규칙을 확인하는 것과 동일한 작업이지만, AI 워크로드(workloads)를 대상으로 한다는 점이 다릅니다.

4. 최소 권한 자격 증명 (Least-privilege credentials) — 에이전트가 다른 시스템에 접근하기 위해 자격 증명이 필요한 경우, 해당 자격 증명은 필요한 최소한의 권한만 가져야 하며 이상적으로는 정기적으로 교체(rotate)되어야 합니다.

MCP 보안 관점

이는 제가 지난 금요일에 다루었던 MCP 취약점에 관한 내용과 일맥상통합니다. STDIO 전송 결함과 nginx-ui CVE는 모두 MCP 서버가 네트워크에 노출되어 있을 때 더 위험합니다. MCP 서버에 대한 접근을 에이전트 포드로만 제한하는 Kubernetes 네트워크 정책을 사용했다면, 두 취약점 모두의 폭발 반경 (blast radius)을 제한할 수 있었을 것입니다.

Kubernetes에서 MCP 서버를 실행하는 경우: 네트워크 정책을 추가하고, 설정이 지원된다면 에이전트와 MCP 서버 간에 mTLS를 활성화하며, 어떤 포드가 어떤 서비스에 도달할 수 있는지 감사하십시오.

이것은 보안의 모든 원칙과 동일합니다: 심층 방어 (defense in depth). 네트워크 격리는 문제가 발생하기 전까지는 괜찮습니다. 인증을 추가하고, 네트워크 정책을 추가하고, 로깅을 추가하십시오. 이제 에이전트는 인프라입니다.