AI 앱의 새 취약점, 모델이 아니라 설정이었다

AI 요약

• 무슨 일: Microsoft가 AI 앱 배포에서 공개 노출 + 약한 인증이 실제 공격 경로가 된 사례를 공개했습니다.
  • 관측 대상에는 MCP 서버, Mage AI, kagent, AutoGen Studio 같은 agentic application과 Kubernetes 워크로드가 포함됩니다.
• 핵심 숫자: Microsoft Defender for Cloud 신호 기준 원격 MCP 서버의 15%가 심각하게 무인증 노출됐다고 합니다.
• 의미: AI 보안의 초점이 jailbreak와 모델 안전성에서 배포 기본값, 서비스 계정, 도구 권한으로 넓어지고 있습니다.
  • 공격자는 zero-day 없이도 인터넷에 열린 AI UI와 API를 통해 RCE, credential theft, 내부 도구 접근을 노릴 수 있습니다.
• 주의점: 빠른 실험용 배포와 vibe coding이 만든 Helm chart·LoadBalancer·no-auth 조합은 production에서도 그대로 남을 수 있습니다.

Microsoft Defender Security Research Team이 2026년 5월 14일 AI 앱의 exploitable misconfiguration 연구를 공개했습니다. 제목은 차분하지만 내용은 꽤 직접적입니다. AI와 agentic application이 Kubernetes 같은 cloud-native 플랫폼에 빠르게 올라가면서, 공개 노출된 UI와 API, 약하거나 빠진 인증, 과도한 service account 권한이 하나의 공격 경로로 묶이고 있다는 이야기입니다.

이 뉴스가 중요한 이유는 새로운 모델 취약점이 아니기 때문입니다. 공격자는 모델을 jailbreak하지 않아도 됩니다. 복잡한 zero-day를 만들 필요도 없습니다. 인터넷에 열린 agent dashboard, 인증 없는 MCP endpoint, cluster-admin에 가까운 service account를 단 AI pipeline UI만 찾으면 됩니다. Microsoft는 이런 조합을 exploitable misconfiguration이라고 부릅니다. 단순한 설정 실수가 아니라 remote code execution, credential theft, sensitive internal tool access로 이어지는 실질적인 공격 경로라는 뜻입니다.

최근 AI 보안 논의는 모델의 refusal, prompt injection, agent hijacking, sandbox escape에 집중돼 왔습니다. 모두 중요한 문제입니다. 그러나 이번 연구는 더 오래된 보안 교훈을 다시 끌어옵니다. 인터넷에 열려 있으면 공격면이고, 인증이 없으면 경계가 아니며, service account가 과도하면 작은 UI 하나가 클러스터 전체 권한으로 커집니다. 달라진 것은 그 UI가 이제 notebook이나 admin dashboard가 아니라 AI agent와 tool execution layer라는 점입니다.

MCP 서버 15%라는 불편한 숫자

Microsoft 발표에서 가장 선명한 숫자는 원격 MCP 서버 15%입니다. Microsoft는 Defender for Cloud의 aggregated and anonymized signals를 기준으로, remote MCP server의 15%가 심각하게 insecure하며 unauthenticated access를 통해 내부 데이터와 operational capability에 접근할 수 있었다고 설명했습니다.

MCP는 AI agent가 외부 도구와 데이터 소스를 표준화된 방식으로 발견하고 호출하게 해주는 프로토콜입니다. 로컬로 띄울 수도 있고, Server-Sent Events나 streamable HTTP로 원격 접근을 열 수도 있습니다. 프로토콜은 OAuth 같은 authorization mechanism을 지원합니다. 문제는 지원과 강제가 다르다는 점입니다. 구현자가 인증을 붙이지 않거나, 배포자가 실험용 endpoint를 인터넷에 노출하면 MCP 서버는 곧 도구 호출 API가 됩니다.

이 위험은 일반 API 노출보다 더 까다롭습니다. 전통적인 API는 보통 기능 단위가 비교적 명확합니다. 반면 MCP server는 ticketing system, HR system, private code repository, database, browser automation, shell execution 같은 도구를 agent에게 제공할 수 있습니다. 즉 인증 없는 MCP endpoint는 단순한 데이터 조회 API가 아니라 "내부 업무를 대신 수행하는 remote control surface"가 될 수 있습니다.

Microsoft는 특히 insecure MCP server implementation이 tool action을 user 또는 agent의 security context가 아니라 server의 security context에서 실행하는 문제를 지적합니다. 이 말은 중요합니다. 누가 요청했는지와 별개로 서버가 가진 권한으로 행동한다면, 익명 사용자는 서버 권한을 빌려 내부 시스템을 만질 수 있습니다. AI agent 보안에서 identity가 왜 별도 보안 primitive가 되어야 하는지 보여주는 사례입니다.

Mage AI, 기본 설치가 공격 경로가 된 사례

Microsoft가 공개한 첫 구체 사례는 Mage AI입니다. Mage AI는 data와 AI pipeline을 만들고 실행하고 orchestration하는 오픈소스 플랫폼입니다. Microsoft에 따르면 Mage AI를 Kubernetes에서 official Helm chart로 배포했을 때, 기본 설치가 port 6789의 internet-facing LoadBalancer를 열고 인증을 활성화하지 않는 상태였습니다. 노출된 web UI에는 shell command execution 기능이 있었고, 이 기능은 mounted service account를 통해 애플리케이션 내부에서 임의 명령 실행으로 이어질 수 있었습니다.

여기서 끝나면 "개발 UI가 공개됐다" 정도입니다. 그러나 Microsoft는 기본 service account가 매우 높은 권한의 role에 묶여 있어 사실상 cluster-admin 수준 capability를 부여했다고 설명했습니다. 공개 UI, no authentication, shell execution, privileged service account가 한 줄로 이어진 것입니다. Microsoft는 이 기본 설정이 실제 환경에서 관측됐고 active exploitation으로 이어졌다고 밝혔습니다.

이 사례는 AI 앱 보안의 새로움과 낡음을 동시에 보여줍니다. 낡은 부분은 Kubernetes 보안의 고전입니다. LoadBalancer를 열었고, auth가 없고, service account가 과도합니다. 새로운 부분은 이 실수가 AI pipeline tooling에서 빠르게 반복된다는 점입니다. AI 팀은 모델 실험과 데이터 파이프라인을 빨리 돌려야 하고, Helm chart 기본값은 "일단 보이게 만들기"에 최적화되기 쉽습니다. 그러다 실험용 배포가 production network에 남습니다.

Microsoft는 이 문제를 Mage AI에 responsible disclosure했고, 현재는 authentication이 기본으로 활성화됐다고 밝혔습니다. 좋은 대응입니다. 하지만 더 큰 교훈은 특정 프로젝트 하나의 수정이 아닙니다. AI workload용 Helm chart와 quickstart가 secure default를 갖추지 않으면, 사용자들은 거의 반드시 insecure default를 운영 환경으로 가져갑니다.

kagent는 공개 기본값이 아니어도 위험합니다

두 번째 사례는 kagent입니다. kagent는 Kubernetes 위에서 AI agent를 실행하기 위한 오픈소스 framework이며, CNCF CNAI landscape에도 올라와 있습니다. Microsoft 설명에 따르면 kagent를 official Helm chart로 배포하면 k8s-agent 같은 여러 AI agent가 Kubernetes service로 구성됩니다. 사용자는 이 agent와 대화하며 cluster operation을 지시할 수 있습니다. 예를 들어 privileged pod 배포 같은 작업을 요청할 수 있습니다.

Microsoft가 분명히 구분한 지점이 있습니다. kagent는 기본적으로 public exposure가 아닙니다. 즉 "설치하면 곧바로 인터넷에 열린다"는 뜻은 아닙니다. 그러나 기본적으로 authentication이 없습니다. 그래서 사용자가 이것을 외부에 노출하면 anonymous user가 Kubernetes agent에게 작업을 지시할 수 있습니다. 그 작업에는 malicious privileged workload 배포, cluster-to-cloud lateral movement, 다른 workload credential 탈취, malicious model과 agent configuration 생성이 포함될 수 있습니다.

위 이미지는 Microsoft가 공개한 kagent 사례입니다. Azure OpenAI API key가 Kubernetes secret에 Base64로 저장돼 있고, 공격자가 agent와 상호작용해 이를 꺼내는 흐름을 보여줍니다. 여기서 흥미로운 점은 "취약점 exploit"이 아니라 "agent에게 요청"이라는 점입니다. 취약점은 코드 메모리 오류가 아니라 인증 없는 대화 경계입니다.

이 패턴은 앞으로 더 자주 등장할 가능성이 큽니다. AI agent는 원래 자연어 요청을 action으로 바꾸기 위해 존재합니다. 따라서 인증되지 않은 사용자가 agent endpoint에 접근할 수 있다면, 공격자는 exploit payload를 만들기보다 agent의 정상 기능을 악용합니다. "민감한 secret을 찾아줘", "privileged pod를 만들어줘", "내부 repo 내용을 읽어줘" 같은 요청은 agent의 관점에서는 task일 수 있습니다. 보안 경계가 app layer에 없으면 모델이 이를 스스로 막아주리라 기대하기 어렵습니다.

AutoGen Studio와 low-code agent builder의 함정

Microsoft AutoGen Studio 사례도 같은 축에 있습니다. AutoGen Studio는 multi-agent workflow를 구성하기 위한 low-code agentic framework입니다. 사용자는 agent skill을 설정하고, 모델을 할당하고, agent들이 작업을 조율하는 workflow를 설계할 수 있습니다. Microsoft는 AutoGen Studio가 기본적으로 authentication 없이 제공된다고 설명했습니다.

AutoGen Studio 역시 기본적으로 public exposure는 아닙니다. 그러나 공개 노출되면 공격자는 agent component를 조작하거나, malicious agent configuration을 배포하거나, linked AI service API key를 추출할 수 있습니다. Microsoft가 공개한 화면에는 공개 노출된 AutoGen Studio에서 AI service API key가 plaintext로 보이는 장면이 포함됐습니다.

이 사례는 low-code agent builder가 왜 더 민감한지 보여줍니다. 일반 admin dashboard는 설정을 바꿉니다. Agent builder는 행동하는 시스템의 지능, 도구, credential, workflow를 바꿉니다. 여기에 접근한 공격자는 단순히 키를 훔치는 것에서 멈추지 않고 agent가 수행할 미래 행동을 바꿀 수 있습니다. 데이터 유출과 pipeline tampering, malicious automation이 같은 화면에서 연결됩니다.

개발팀은 종종 이런 도구를 "내부 실험용"으로 취급합니다. 그러나 내부 실험용 UI가 VPN, ingress, port-forward, temporary LoadBalancer, demo domain을 거치며 의도치 않게 외부에 열리는 일은 드물지 않습니다. AI agent builder는 그 순간 일반 개발 도구보다 더 높은 위험을 가집니다. 모델 API key와 내부 tool connector, workflow 정의가 한곳에 모이기 때문입니다.

문제는 AI가 아니라 배포 속도입니다

Microsoft는 이번 연구에서 Mage AI, kagent, AutoGen Studio 외에도 Agentgateway, MLRun, Numaflow, OpenLIT, Microsoft Agent Framework Dev UI, Nvidia Nemo Agent Toolkit, Marimo, Comfy UI, Ray Dashboard, MCP Hub Dashboard에서 misconfiguration 사례를 관측했다고 밝혔습니다. 이 목록은 하나의 벤더나 하나의 프로젝트 문제가 아니라는 뜻입니다. AI 앱 생태계 전반이 빠르게 실험에서 운영으로 이동하면서, 기존 클라우드 보안 실수가 agent 시대의 권한 확대 장치와 결합하고 있습니다.

여기서 vibe coding 언급도 가볍게 넘기기 어렵습니다. Microsoft는 AI-assisted code가 약한 보안 관행으로 생성될 수 있고, 이런 코드와 설정이 insecure deployment로 이어질 수 있다고 지적합니다. 이것은 "AI가 나쁜 코드를 쓴다"는 단순 비판이 아닙니다. 더 정확히는 AI가 배포 속도를 높이는 만큼, secure default와 review gate가 없으면 잘못된 설정이 더 빠르게 확산된다는 뜻입니다.

AI 팀의 운영 현실을 생각해 보면 이해하기 쉽습니다. 새 agent demo를 띄워야 합니다. 내부 데이터베이스와 연결해야 합니다. 모델 API key를 넣어야 합니다. Slack, GitHub, Jira, HR, billing system과 붙여야 합니다. PM과 임원에게 보여주려면 외부 접속 가능한 URL이 필요합니다. 이 과정에서 "일단 auth는 나중에", "cluster role은 우선 넓게", "secret은 Kubernetes secret에 넣었으니 괜찮겠지" 같은 판단이 쌓입니다. 공격자는 바로 그 중간 상태를 찾습니다.

전통적 취약점 모델을 우회한다는 말의 의미

Microsoft는 exploitable misconfiguration이 traditional vulnerability model을 우회한다고 표현했습니다. 이 말은 꽤 실무적입니다. CVE가 없어도, patch가 없어도, exploit kit이 없어도 공격이 가능합니다. 시스템이 이미 공격 가능한 형태로 배포되어 있기 때문입니다.

보안 조직은 CVE feed, SCA, container image scanning, EDR, WAF, runtime anomaly detection에 익숙합니다. 그러나 no-auth AI dashboard와 overprivileged service account는 CVE feed로만 잡히지 않습니다. Helm chart default, Kubernetes Service type, ingress rule, authentication middleware, service account binding, secret exposure, agent tool 권한을 함께 봐야 합니다.

이것은 AI workload inventory 문제이기도 합니다. 조직은 "어떤 모델을 쓰는가"보다 먼저 "어떤 AI service가 어디에 떠 있고, 어떤 endpoint가 공개돼 있고, 어떤 identity로 어떤 도구를 호출하는가"를 알아야 합니다. AI 보안 거버넌스가 모델 registry와 prompt policy만으로 끝나지 않는 이유입니다.

개발자에게 필요한 체크리스트

이번 발표에서 바로 가져갈 수 있는 실무 원칙은 명확합니다. 첫째, public access는 명시적 보안 결정이어야 합니다. AI service가 외부에 열려야 할 수도 있습니다. 그러나 그 경우 authentication, authorization, network control이 함께 설계돼야 합니다. "LoadBalancer가 생겼으니 접근된다"는 상태는 설계가 아니라 사고입니다.

둘째, 내부 AI 서비스에도 인증을 강제해야 합니다. MCP server, agent builder, notebook, pipeline UI, dashboard는 "내부망이니까 괜찮다"는 전제를 견디기 어렵습니다. agent는 내부 도구와 데이터를 연결하므로, 내부자 오남용과 lateral movement에도 취약합니다.

셋째, workload는 authenticated user 또는 agent context에서 동작해야 합니다. 서버가 가진 broad service-level identity로 모든 tool action을 실행하면, 사용자 권한 경계가 무너집니다. Agent identity, task-scoped permission, time-limited credential, per-tool authorization이 필요합니다.

넷째, AI workload를 계속 inventory하고 audit해야 합니다. 새 agent, 새 MCP server, 새 dashboard가 어디서 생겼는지 모르면 막을 수 없습니다. Kubernetes에서는 Service, Ingress, Gateway, ExternalName, LoadBalancer, port-forward 패턴을 모두 봐야 합니다. IaC와 runtime state가 다를 수 있으므로 cluster에서 실제 노출 상태를 확인해야 합니다.

다섯째, quickstart와 Helm chart를 그대로 믿지 말아야 합니다. 데모가 잘 되는 기본값과 production에 안전한 기본값은 다를 수 있습니다. Chart를 설치하기 전에 service type, auth default, secret mount, RBAC, NetworkPolicy, pod security context를 확인해야 합니다. 특히 agent framework가 cluster operation을 수행한다면 기본 service account 권한은 최소로 시작해야 합니다.

MCP 보안 논의의 다음 단계

MCP는 agent 생태계의 중요한 표준으로 빠르게 자리 잡고 있습니다. 그러나 표준이 커질수록 "연결된다"는 사실보다 "어떤 권한으로 연결되는가"가 중요해집니다. OAuth를 지원한다는 사실만으로는 부족합니다. MCP server가 인증을 강제하는지, tool call마다 authorization을 확인하는지, user context와 server context를 분리하는지, audit log가 남는지, remote endpoint가 어디에 노출되는지 확인해야 합니다.

특히 remote MCP server는 cloud deployment와 만나는 순간 API security의 모든 숙제를 다시 떠안습니다. TLS, auth, rate limit, tenant boundary, egress control, secret management, tool allowlist, approval workflow가 필요합니다. 여기에 prompt injection과 tool poisoning까지 더해집니다. 사용자가 악성 문서를 열어 agent가 MCP tool을 호출하게 만들 수 있고, 인증 없는 MCP endpoint는 그 자체로 공격자에게 열린 tool plane이 됩니다.

이 관점에서 Microsoft의 15% 숫자는 단순한 통계가 아닙니다. MCP가 agent action layer의 표준이 되는 속도보다, MCP deployment의 보안 성숙도가 느릴 수 있다는 경고입니다. AI 개발자는 이제 model selection과 prompt engineering만이 아니라, tool server 운영 보안까지 책임져야 합니다.

보안 제품의 메시지도 바뀝니다

Microsoft는 Defender for Cloud가 exposed Kubernetes service를 감지해 위험을 우선순위화할 수 있다고 설명합니다. 물론 이 대목은 Microsoft 제품 메시지이기도 합니다. 그러나 방향 자체는 넓게 적용됩니다. AI security product가 앞으로 다뤄야 할 것은 prompt와 model output만이 아닙니다. Kubernetes exposure, identity graph, service account privilege, secret reachability, agent tool inventory, runtime call chain을 함께 봐야 합니다.

이 흐름은 최근 보안 시장의 움직임과도 맞물립니다. Endor Labs는 code를 만드는 agent 자체를 보호하는 방향으로 AURI를 확장했고, Sysdig는 agent가 headless로 보안을 운영하는 cloud security를 이야기합니다. Microsoft는 Agent 365와 Defender for Cloud에서 shadow agent와 exposed workload를 추적하려 합니다. 공통점은 AI 보안이 "모델을 감시하는 기능"에서 "AI가 붙은 소프트웨어 공급망과 운영 계층을 감시하는 기능"으로 이동한다는 점입니다.

개발 조직 입장에서는 벤더 선택보다 먼저 데이터 모델을 정리해야 합니다. Agent는 어떤 identity를 갖는가. Tool server는 어디에 떠 있는가. 각 tool은 어떤 action을 허용하는가. Credential은 어디에 저장되는가. 외부 노출은 누가 승인하는가. 사람이 승인해야 하는 action은 어디서 강제되는가. 이 질문에 답이 없으면 어떤 보안 제품도 표면적인 alert만 늘릴 가능성이 큽니다.

결론: AI 워크로드를 실험 도구로 취급하지 말아야 합니다

이번 Microsoft 연구의 핵심은 "AI 앱도 보안 설정을 잘하자"라는 상식이 아닙니다. 더 구체적으로는 AI 앱이 이제 내부 도구, credential, workflow, Kubernetes 권한을 결합하는 high-impact workload가 됐다는 사실입니다. 공개 노출과 인증 부재는 오래된 실수지만, agentic application에서는 그 결과가 더 빠르게 커집니다. 사용자가 누르던 버튼을 agent가 대신 누르고, 사람이 실행하던 스크립트를 tool server가 대신 실행하기 때문입니다.

AI 개발팀은 새 모델과 새 agent framework를 빠르게 붙이는 데 익숙해졌습니다. 이제 그 속도만큼 inventory, identity, auth, least privilege, network exposure review가 따라와야 합니다. MCP server를 띄울 때는 "연결됐다"가 완료 조건이 아닙니다. "누가 어떤 권한으로 어떤 tool을 호출할 수 있는가"가 완료 조건입니다. AutoGen Studio나 kagent 같은 agent builder를 띄울 때도 마찬가지입니다. 외부에 열리지 않는지, 열려야 한다면 인증과 권한 경계가 명확한지, API key가 UI에 노출되지 않는지 확인해야 합니다.

AI 보안의 다음 병목은 모델이 아닐 수 있습니다. 모델은 계속 강해지고, agent framework는 계속 쉬워질 것입니다. 오히려 위험은 쉬워진 배포가 남긴 기본 설정에 있습니다. Microsoft가 공개한 사례들은 그 전환을 잘 보여줍니다. 앞으로 AI 사고의 상당수는 "모델이 속았다"보다 "설정이 이미 문을 열어두고 있었다"에 가까울 가능성이 큽니다.