지난 몇 주 동안 저는 AI 에이전트(AI agents)의 보안을 살펴보는 데 많은 시간을 보냈습니다.

모델 그 자체가 아니라,

그 주변의 인프라(infrastructure)를 말입니다.

구체적으로는, MCP 서버(MCP servers)입니다.

더 많은 기업이 AI 에이전트를 도입함에 따라, MCP 서버는 모델과 현실 세계를 잇는 가교 역할을 하고 있습니다. 이들은 에이전트를 도구(tools), 데이터베이스(databases), API, 파일 시스템(file systems), 내부 서비스(internal services) 및 외부 워크플로(external workflows)와 연결합니다.

이로 인해 한 가지 생각이 들었습니다:

이 서버들이 인터넷에 노출되면 어떤 일이 벌어질까?

그래서 직접 확인해 보기로 했습니다.

저는 공개적으로 접근 가능한 492개의 MCP 서버를 분석하고, 이들을 대상으로 일련의 행동 보안 테스트(behavioral security tests)를 수행했습니다.

목표는 착취(exploitation)가 아니었습니다.

목표는 이러한 시스템이 적대적 입력(adversarial inputs)을 만났을 때 어떻게 행동하는지 이해하는 것이었습니다.

스캔 방법

각 MCP 서버에 대해 저는 다음과 같은 방법들을 조합하여 수행했습니다:

• 도구 열거 (Tool enumeration)
• 권한 경계 분석 (Permission boundary analysis)
• 프롬프트 인젝션 (Prompt injection) 테스트
• 명령 실행 (Command execution) 테스트
• 컨텍스트 조작 (Context manipulation) 테스트
• 행동 보안 평가 (Behavioral security evaluation)

전통적인 취약점 스캐닝(vulnerability scanning)에 집중한 것이 아닙니다.

대신, 저는 다른 질문에 답하고 싶었습니다:

공격자가 단순히 지침(instructions)을 조작함으로써 AI와 연결된 도구가 수행하는 작업에 영향을 미칠 수 있는가?

불행하게도, 대답은 종종 '예'였습니다.

가장 놀라운 발견

분석된 492개의 MCP 서버 중:

43%가 명령 인젝션(command injection) 취약성 징후를 보였습니다.

구식 소프트웨어를 실행하고 있어서가 아니었습니다.

인증(authentication)이 깨져서도 아니었습니다.

많은 시스템이 에이전트가 생성한 지침을 암묵적으로 신뢰했기 때문입니다.

그 신뢰가 위험을 초래했습니다.

패턴 #1: 자연어가 셸 명령어가 되다

한 가지 흔한 패턴은 다음과 같았습니다:

사용자가 요청합니다:

"프로젝트의 모든 파일을 나열해줘."

MCP 서버는 해당 요청을 셸 명령어(shell command)로 변환합니다.

문제는 취약한 검증(validation)으로 인해 동일한 경로가 의도한 것보다 훨씬 더 많은 것을 처리할 수 있다는 점입니다.

에이전트가 제어하는 입력값이 셸 실행(shell execution)에 도달하면, 상황은 매우 빠르게 위험해질 수 있습니다.

한 줄 해결책:

에이전트가 제어하는 입력값을 셸 실행(shell execution)에 직접 전달하지 마세요. 허용 목록(allowlist)에 있는 명령어를 사용하고 구조화된 파라미터(structured parameters)를 사용하세요.

패턴 #2: 자유 형식의 지시문이 데이터베이스 쿼리가 되는 경우

또 다른 반복적인 문제는 데이터베이스 접근과 관련되어 있었습니다.

에이전트는 자연어 요청(natural language request)을 받습니다.

그 요청은 쿼리(query)로 변환됩니다.

엄격한 제어가 없다면, 해당 쿼리의 범위는 원래 의도했던 범위를 훨씬 넘어 확장될 수 있습니다.

그 결과가 항상 전통적인 인젝션 취약점(injection vulnerability)인 것은 아닙니다.

때로는 단순히 과도한 접근 권한이 발생하는 문제일 뿐입니다.

한 줄 해결책:

파라미터화된 쿼리(parameterized queries)를 사용하고 엄격한 범위 제한(scope enforcement)을 적용하세요. 자유 형식의 지시문으로부터 직접 쿼리를 생성하지 마세요.

패턴 #3: 도구 체이닝(Tool Chaining)이 새로운 능력을 생성함

이것은 아마도 가장 흥미로운 카테고리였을 것입니다.

개별적으로 보았을 때, 도구들은 안전해 보였습니다.

검색 도구.

파일 접근 도구.

HTTP 요청 도구.

특별할 것 없는 것들이었습니다.

하지만 자율 에이전트(autonomous agent)에 의해 이들이 체이닝(chained)되었을 때, 완전히 새로운 능력들이 나타났습니다.

검색은 검색(retrieval)이 되었습니다.

검색(retrieval)은 추출(extraction)이 되었습니다.

추출(extraction)은 전송(transmission)이 되었습니다.

문제는 도구가 아니었습니다.

그것은 조합(combination)이었습니다.

한 줄 해결책:

에이전트가 시작될 때뿐만 아니라, 모든 도구 경계(tool boundary)에서 권한을 검증하세요.

더 큰 문제

수백 개의 MCP 서버를 검토한 후, 한 가지 사실이 명확해졌습니다.

대부분의 보안 팀은 여전히 전통적인 애플리케이션 보안 모델을 사용하여 AI 인프라를 생각하고 있다는 점입니다.

그들은 다음과 같이 질문합니다:

• 인증(authentication)이 활성화되어 있는가?
• API가 보호되고 있는가?
• 네트워크가 안전한가?

그러한 질문들도 여전히 중요합니다.

하지만 AI 시스템은 새로운 무언가를 도입합니다.

행동 보안 (Behavioral security).

시스템이 반드시 침해(compromised)되는 것은 아닙니다.

설득(persuaded)당하는 것입니다.

그리고 그것은 근본적으로 다른 도전 과제입니다.

내가 이를 위한 도구를 만든 이유

수백 개의 MCP 서버를 수동으로 평가한 후, 이 프로세스는 확장성(scale)을 가질 수 없다는 것이 분명해졌습니다.

그것이 제가 다음을 자동화하기 위한 프레임워크를 구축한 이유입니다:

• MCP 검색 (discovery)
• 행동 테스트 (Behavioral testing)
• 프롬프트 인젝션 평가 (Prompt injection evaluation)
• 커맨드 인젝션 탐지 (Command injection detection)
• 권한 경계 분석 (Permission boundary analysis)
• 툴체인 보안 테스트 (Tool-chain security testing)

목표는 버그를 찾는 것이 아닙니다.

목표는 공격자가 하기 전에 위험한 행동을 식별하는 것입니다.

마치며

492개의 MCP 서버를 스캔하며 얻은 가장 큰 교훈은 AI 시스템이 보안에 취약하다는 것이 아니었습니다.

그것은 많은 AI 시스템이 지켜야 할 수준보다 훨씬 더 지시 사항을 신뢰한다는 점이었습니다.

AI 에이전트가 더 많은 도구, 더 많은 데이터, 그리고 더 많은 자율성에 접근하게 됨에 따라, 보안은 더 이상 인프라 단계에서 멈출 수 없습니다.

우리는 행동(behavior) 또한 테스트해야 합니다.

그것이 제가 Crucible을 구축하기 시작한 이유 중 하나입니다. Crucible은 실제 적대적 시나리오(adversarial scenarios)에 대해 AI 에이전트, MCP 서버 및 에이전트 시스템(agentic systems)을 테스트하기 위한 오픈 소스 보안 프레임워크입니다.

cybersecurity #artificialintelligence #opensource #githubopensource #security #buildinpublic #aiagents