2026년 AI 에이전트 보안: 경계는 더 이상 프롬프트가 아니다

에이전트가 채팅 데모에서 프로덕션 워크플로 (production workflows)로 이동함에 따라, 실제 보안 경계는 더 이상 프롬프트 (prompt)가 아닙니다. 그것은 에이전트가 무엇을 보고, 호출하고, 편집하고, 실행하고, 승인하고, 기억할 수 있는지에 달려 있습니다.

2025년 6월, Microsoft는 CVSS 점수 9.3을 기록한 CVE-2025-32711로 추적되는 EchoLeak이라는 취약점을 패치했습니다. 이는 AI 에이전트에 대한 최초로 기록된 제로 클릭 (zero-click) 공격이었습니다.

공격자는 조직 내 누구에게나 정교하게 제작된 이메일 한 통을 보냈습니다. Microsoft 365 Copilot은 설계된 대로 정확히 작동하며, 컨텍스트 (context)의 일부로 해당 이메일을 읽었고, 그 안에 숨겨진 지침을 따랐으며, 다음과 같은 민감한 내부 데이터를 유출했습니다:

채팅 로그 (Chat logs)
OneDrive 파일
SharePoint 콘텐츠

클릭도 없었습니다.

링크도 없었습니다.

사용자 상호작용도 없었습니다.

해당 공격에서 모델이 일반적인 의미의 "환각 (hallucinate)"을 일으킬 필요는 전혀 없었습니다. 모델은 유익하게 행동했을 뿐입니다.

피해는 에이전트에게 허용된 권한으로부터 발생했습니다:

개인적인 컨텍스트 (private context) 읽기
신뢰할 수 없는 콘텐츠 (untrusted content) 수용
외부로 통신

세 가지 평범한 기능이 하나로 연결된 것입니다.

이것이 2026년 에이전트 보안의 모습입니다.

프로덕션에서의 질문은 더 이상 다음과 같지 않습니다:

모델이 안전하게 답변했는가?

이제 질문은 다음과 같습니다:

에이전트가 무엇을 보고, 호출하고, 변경하고, 실행하고, 기억하도록 허용되었는가?

보안 경계가 이동했다

수년 동안 AI 안전 (AI safety) 논의는 주로 모델의 출력 (output)에 집중되었습니다.

모델이 유해한 콘텐츠를 생성할 것인가? 환각을 일으킬 것인가? 민감한 정보를 유출할 것인가? 정책을 준수할 것인가?

이러한 질문들은 여전히 중요하지만, 에이전트 시스템 (agentic systems)에게는 더 이상 충분하지 않습니다.

챗봇 (chatbot)은 텍스트를 생성합니다.

에이전트 (agent)는 행동을 취합니다.

이 한 가지 차이점이 보안 모델을 완전히 바꿉니다.

에이전트가 도구 (tools)를 호출하고, 개인 문서를 검색하고, 코드를 편집하고, 명령을 실행하거나, 워크플로 (workflows)를 트리거할 수 있을 때, 위험은 더 이상 모델이 제공하는 답변에 국한되지 않습니다. 그것은 에이전트가 취하는 행동으로까지 확장됩니다.

학문의 초점은 **프롬프트 안전성 (prompt safety)**에서 **실행 안전성 (execution safety)**으로 이동합니다.

프로덕션에서의 질문은 더 이상 다음과 같지 않습니다:

모델이 안전하게 답변했는가?

이제 질문은 다음과 같습니다:

에이전트가 무엇을 보고, 호출하고, 변경하고, 실행하고, 기억하도록 허용되었는가?

이 지점이 많은 에이전트 시스템이 위험해지는 구간입니다. 팀들이 에이전트를 둘러싼 제어 계층 (control layer)을 정의하기 전에 도구 (tools)들을 먼저 연결하기 때문입니다.

그들은 MCP 서버, 코딩 에이전트 (coding agents), 리포지토리 접근 권한 (repo access), 브라우저 도구, 데이터베이스 접근 권한, 그리고 내부 API를 추가하지만, 다음과 같은 사항에 대해 항상 명확한 규칙을 정의하는 것은 아닙니다:

도구 가시성 (Tool visibility)
권한 (Permissions)
승인 (Approval)
로깅 (Logging)
롤백 (Rollback)

이 글은 바로 그 간극에 대해 다룹니다.

업계는 이제 이를 하나의 독립된 전문 분야로 다루고 있습니다.

2025년 12월, OWASP GenAI Security Project는 100명 이상의 기여자가 참여하여 검토한 프레임워크인 OWASP Top 10 for Agentic Applications 2026을 발표했습니다. 이 프레임워크는 에이전트 보안 이슈 (Agentic Security Issues)에 대한 새로운 어휘 체계인 ASI01부터 ASI10을 중심으로 구성되어 있습니다.

아래의 각 리스크는 해당 ASI 카테고리에 매핑됩니다. 왜냐하면 이 분류 체계 (taxonomy)가 이 문제에 대한 공통 언어로 빠르게 자리 잡고 있기 때문입니다.

2026년에 무엇이 변했는가

에이전트는 더 이상 실험적인 데모가 아닙니다.

팀들은 다음과 같은 실제 워크플로 (workflows) 내에서 에이전트를 실행하고 있습니다:

코딩 (Coding)
리서치 (Research)
지원 (Support)
문서 처리 (Document processing)
데이터 운영 (Data operations)
고객 커뮤니케이션 (Customer communication)
내부 자동화 (Internal automation)

이러한 변화는 보안에 대한 기대치를 변화시킵니다.

데모 에이전트는 접근 권한이 제한되어 있기 때문에 안전하게 실패합니다.

반면, 프로덕션 에이전트는 리포지토리, 고객 데이터, 내부 API 및 워크플로 트리거 (workflow triggers)에 접근할 수 있기 때문에 실패할 경우 실질적인 결과(consequences)를 초래합니다.

1,300명 이상의 실무자를 대상으로 조사한 LangChain의 2026 State of Agent Engineering 보고서는 이러한 변화를 명확히 보여줍니다:

응답자의 57.3%가 이미 프로덕션에서 에이전트를 실행 중임
또 다른 30.4%는 배포 계획을 가지고 에이전트를 활발히 개발 중임
거의 89%가 관측 가능성 (observability)을 구현함
평가 (Eval) 도입률은 52%에 머무름
품질 (Quality)이 프로덕션 도입의 가장 큰 장벽임
직원 2,000명 이상의 기업의 경우, 보안이 24.9%로 두 번째로 큰 관심사임

더 어려운 문제는 도입이 아닙니다.

바로 제어 (control)입니다.

에이전트가 프로덕션 (production) 환경으로 이동함에 따라, 팀들은 다음과 같은 구체적인 질문들에 답해야 합니다:

에이전트가 어떤 도구(tools)를 볼 수 있는가?
에이전트가 어떤 도구를 호출(call)할 수 있는가?
에이전트가 어떤 컨텍스트 (context)를 읽을 수 있는가?
어떤 작업에 인간의 승인이 필요한가?
무엇이 로그 (log)에 기록되는가?
에이전트가 잘못되었을 경우 어떤 일이 발생하는가?
도구의 응답이 악의적(malicious)일 경우 어떤 일이 발생하는가?
에이전트가 코드를 변경하거나, 메시지를 보내거나, 워크플로 (workflow)를 트리거할 경우 어떤 일이 발생하는가?

이것들은 프롬프트 엔지니어링 (prompt-engineering)에 관한 질문이 아닙니다.

이것들은 아키텍처 (architecture)에 관한 질문입니다.

MCP는 에이전트를 더 유용하게 만들지만, 동시에 더 민감하게 만든다

Model Context Protocol (MCP)가 중요한 이유는 AI 애플리케이션이 도구, 데이터 및 외부 시스템에 연결되는 방식을 표준화하기 때문입니다.

공통 프로토콜이 없다면, 모든 애플리케이션은 맞춤형 통합 (custom integrations)이 필요합니다.

MCP를 사용하면 도구와 컨텍스트를 여러 에이전트에서 재사용할 수 있게 됩니다.

OpenAI의 Agents SDK는 MCP를 "AI 애플리케이션을 위한 USB-C 포트"라고 설명합니다. 즉, 모델이 다양한 데이터 소스 및 도구에 연결되는 표준화된 방식입니다.

표준화는 책임 또한 증가시킵니다.

도구를 연결하기가 쉬워지면, 안전하지 않은 도구에 노출되기도 쉬워집니다.

컨텍스트를 전달하기가 쉬워지면, 민감한 컨텍스트가 유출되기도 쉬워집니다.

OpenAI의 MCP 및 커넥터 가이드 노트에 따르면, 원격 MCP 서버는 프로토콜을 구현하는 공개 인터넷 서버라면 무엇이든 될 수 있습니다. 이러한 서버는 모델이 외부 서비스에 접근하고 제어할 수 있도록 허용할 수 있으며, 도구 호출은 자동으로 허용하거나 개발자의 명시적인 승인 뒤로 제한할 수 있습니다.

프로덕션 환경에서 MCP는 단순한 통합 계층이 아닙니다.

그것은 권한 경계 (permission boundary)입니다.

첫 번째 리스크: 권한 경계 없는 도구 접근

ASI02: 도구 오용 및 악용 (Tool Misuse & Exploitation)에 해당

에이전트가 도구를 호출할 수 있게 되는 순간, 보안은 프롬프트 설계에서 권한 설계 (permission design)로 이동합니다.

도구는 단순한 함수가 아닙니다.

그것은 하나의 역량 (capability)입니다.

어떤 도구는 읽기만 수행합니다. 어떤 도구는 상태 (state)를 수정합니다. 어떤 도구는 메시지를 보내고, 티켓을 생성하며, 파일을 삭제하고, 데이터베이스를 업데이트하며, 코드를 배포하거나 워크플로를 트리거합니다.

이들을 동일하게 취급해서는 안 됩니다.

운영 환경의 에이전트 (Production agent)는 기본적으로 사용 가능한 모든 도구를 볼 수 있어서는 안 됩니다. 현재의 작업, 사용자, 역할 및 환경에 필요한 도구만을 볼 수 있어야 합니다.

더 안전한 설계는 도구를 다음과 같은 카테고리로 분리합니다:

읽기 전용 도구 (Read-only tools)
쓰기 도구 (Write tools)
외부 통신 도구 (External communication tools)
운영 영향 도구 (Production-impacting tools)
코드 실행 도구 (Code execution tools)
민감 데이터 도구 (Sensitive-data tools)

그런 다음 각 도구에 서로 다른 제어 (Controls)를 적용합니다.

읽기 전용 도구는 자동으로 실행될 수 있습니다.

쓰기 도구는 승인이 필요할 수 있습니다.

운영 영향 도구는 명시적인 인간의 확인 (Human confirmation)을 요구해야 합니다.

비밀 정보 접근 도구 (Secret-access tools)는 일반적으로 완전히 차단되어야 합니다.

이것이 바로 OWASP가 ASI02로 분류한 실패 사례입니다.

이는 실제 사례에서도 나타납니다. 2025년, 연쇄된 지시 (Chained instruction)를 따르던 Google AI 에이전트가 사용자의 Drive 전체를 삭제했습니다. 해당 도구는 정당한 것이었고 권한도 부여된 상태였으며, 바로 이 점 때문에 피해가 발생할 수 있었습니다.

범위 지정 (Scoping)의 목표는 모든 에이전트의 속도를 늦추는 것이 아닙니다.

조용히 발생하는 고위험 실행 (Silent high-risk execution)을 방지하는 것입니다.

두 번째 리스크: 원격 MCP 서버와 신뢰

ASI04: 에이전트 공급망 취약점 (Agentic Supply Chain Vulnerabilities)에 해당

원격 MCP 서버는 외부 시스템의 유용한 기능들을 노출하기 때문에 강력합니다.

하지만 이들은 애플리케이션 경계 (Application boundary) 밖에 위치하기 때문에 민감합니다.

질문은 단지 다음과 같아서는 안 됩니다:

이 도구가 작업을 해결할 수 있는가?

다음과 같이 질문해야 합니다:

에이전트가 보낼 수 있는 데이터를 이 서버에 맡겨도 신뢰할 수 있는가?

이 점에 대해 OpenAI의 가이드는 매우 직설적입니다. 원격 MCP 서버는 자체 약관을 따르는 제3자 서비스입니다. 이들은 데이터를 송수신하고, 조치를 취할 수 있으므로 주의 깊게 검토되어야 합니다. 개발자는 공식 서버를 선호해야 하며, 제3자와 공유되는 데이터를 검토하고, 해당 사용을 로그 (Log)로 남겨야 합니다.

이 리스크는 가설이 아닙니다.

2026년 1월, Anthropic의 공식 Git MCP 서버에서 세 가지 프롬프트 인젝션 (Prompt-injection) 취약점인 CVE-2025-68143, CVE-2025-68144, CVE-2025-68145가 공개되었습니다. 악의적인 README 파일이나 오염된 이슈 (Issue) 설명만으로도 코드 실행 (Code execution) 또는 데이터 유출 (Data exfiltration)을 유발하기에 충분했습니다.

프런티어 랩 (Frontier lab)의 공식 서버조차 그러한 리스크를 안고 있다면, 검증되지 않은 제3자 프록시 (Third-party proxy)는 훨씬 더 큰 리스크를 가집니다.

서버를 채택하기 전에 던져야 할 질문들은 구체적이어야 합니다:

누가 운영하는가?
어떤 데이터를 받게 되는가?
해당 데이터를 저장하거나 전달하는가?
읽기 또는 쓰기 권한을 노출하는가?
도구 (Tool)의 동작이 시간이 지남에 따라 변할 수 있는가?
공식 서버인가, 셀프 호스팅 (Self-hosted)인가, 아니면 제3자 프록시인가?
모든 호출이 로그 (Log)로 남는가?
민감한 작업에 대해 승인이 필요한가?

내부 시스템의 경우, 가장 안전한 기본 설정은 명확한 권한 부여 (Authorization), 로깅 (Logging), 그리고 데이터 보존 (Data-retention) 기대치가 정의된 셀프 호스팅 또는 공식 서버를 사용하는 것입니다.

MCP 서버는 단순한 커넥터 (Connector)가 아닙니다.

그것은 신뢰에 대한 결정입니다.

세 번째 리스크: 프롬프트 표면으로서의 도구 설명 (Tool Descriptions)

ASI01: Agent Goal Hijack에 해당

전통적인 소프트웨어에서 함수 설명 (Function description)은 문서 (Documentation)입니다.

에이전트 시스템에서 도구 설명 (Tool description)은 모델의 운영 컨텍스트 (Operating context)의 일부가 됩니다. 즉, 도구 메타데이터 (Tool metadata)가 동작에 영향을 미칠 수 있음을 의미합니다.

만약 악의적이거나 침해된 도구가 자신의 설명이나 출력값에 숨겨진 지침을 포함한다면, 모델은 이를 신뢰할 수 있는 컨텍스트로 취급할 수 있습니다.

이는 이론적인 이야기가 아닙니다.

2025년, Invariant Labs는 모델에는 보이지만 도구 목록을 검토하는 사용자에게는 보이지 않는 도구 설명 내부에 악의적인 지침을 숨기는 MCP "도구 오염 (Tool-poisoning)" 공격을 공개했습니다.

OpenAI의 문서도 이 경고를 되풀이합니다: 악의적인 MCP 서버는 모델이 예상치 못한 방식으로 동작하도록 설계된 숨겨진 지침을 포함할 수 있으며, 서버의 동작은 호출 사이에 변할 수 있습니다.

OWASP는 이러한 종류의 리디렉션 (Redirection)을 ASI01: Agent Goal Hijack으로 분류하며, 여기서 주입된 콘텐츠는 에이전트가 수행하려는 작업을 조용히 변경합니다.

따라서 도구 설명 (tool descriptions)은 해롭지 않은 텍스트로 취급되어서는 안 됩니다.

안전한 플랫폼은 다음과 같은 조치를 취해야 합니다:

도구 설명을 노출하기 전에 검토할 것
설명을 짧고 목적에 특화되게 유지할 것
제3자 도구가 광범위한 행동 지침을 주입하는 것을 방지할 것
실행 중에 어떤 도구 정의가 가시적이었는지 로그를 남길 것
서버가 변경될 때마다 정의를 재검증할 것

도구의 표면적 (tool surface)이 넓어질수록, 에이전트가 잘못된 기능을 선택하거나 잘못된 지침을 흡수하기가 더 쉬워집니다.

이것이 바로 "더 많은 도구"가 "더 나은 에이전트"를 의미하지 않는 이유 중 하나입니다.

때로는 그저 더 넓은 공격 표면 (attack surface)을 의미할 뿐입니다.

네 번째 리스크: 리포지토리 가드레일 없는 코드베이스 접근

ASI05: Unexpected Code Execution에 해당함

코딩 에이전트 (Coding agents)가 유용한 이유는 코드를 읽고, 변경 사항을 제안하며, 파일을 업데이트하고, 테스트를 실행하며, 리뷰를 보조하기 때문입니다.

이는 또한 에이전트가 민감한 엔지니어링 환경 내부에서 작동함을 의미합니다.

코딩 에이전트가 위험을 초래하기 위해 프로덕션 루트 권한 (production root access)까지 가질 필요는 없습니다. 잘못된 파일에 대한 쓰기 권한만으로도 충분합니다.

에이전트는 다음과 같은 행위를 할 수 있습니다:

보안에 취약한 코드 도입
의존성 (dependencies) 변경
테스트 수정
로그나 프롬프트에 비밀 정보 (secrets) 노출
컨벤션 (conventions) 우회
올바르게 보이지만 유지보수성을 조용히 약화시키는 코드 생성

AGENTS.md, CLAUDE.md, 리포지토리 규칙, 브랜치 정책과 같은 지침이 도움이 되지만, 그것만으로는 충분하지 않습니다.

이것들은 컨텍스트 (context)일 뿐, 강제 집행 수단 (enforcement)이 아닙니다.

실질적인 설정은 지침과 강력한 통제 수단을 결합하는 것입니다:

코딩 에이전트를 main 브랜치에 직접 실행하지 않고 브랜치에서 실행할 것
머지 (merge) 전 리뷰를 요구할 것
비밀 파일에 대한 접근을 차단할 것
테스트와 린터 (linters)를 자동으로 실행할 것
의존성 변경 시 명시적인 승인을 요구할 것
에이전트가 읽고 수정하는 파일을 로그로 남길 것

OWASP는 여기서 최악의 사례를 ASI05로 정의하며, 이는 에이전트가 생성하거나 호출한 코드가 의도하지 않은 실행 경로 (execution path)가 되는 경우를 말합니다.

원칙은 간단합니다:

코딩 에이전트는 지침을 받아야 할 뿐만 아니라, 제약 (constrained)을 받아야 합니다.

다섯 번째 리스크: 컨텍스트 및 메모리 유출

ASI06: Memory & Context Poisoning (메모리 및 컨텍스트 오염)에 해당

컨텍스트 (Context)는 AI 시스템 설계에서 가장 중요한 부분 중 하나입니다.

또한 이는 양방향의 보안 경계 (security boundary)이기도 합니다.

아웃바운드 유출 (Outbound leakage)

RAG (검색 증강 생성) 시스템은 내부 문서, 고객 기록, 티켓, 코드 또는 이메일을 검색할 수 있으며, 이는 이후 프롬프트 (prompt), 도구 호출 (tool calls), 그리고 향후 동작으로 흘러 들어갑니다.

유출은 다음과 같은 경우에 발생합니다:

민감한 문서가 프롬프트에 포함될 때
검색 결과가 사용자의 권한 범위를 벗어난 문서를 반환할 때
에이전트가 기밀 데이터를 응답으로 요약할 때
한 세션의 컨텍스트가 다른 세션으로 흘러 들어갈 때

인바운드 오염 (Inbound poisoning)

인바운드는 EchoLeak 및 Gemini 공격이 악용한 방향입니다.

2025년, 한 연구자가 악성 이메일을 통해 Gemini의 지속성 메모리 (persistent memory)를 오염시켰습니다. 이어서 진행된 Gemini Enterprise의 Jira 연동을 통한 공격은 작업 설명 (task description)을 통해 피해자의 메모리를 조용히 삭제했으며, 이로 인해 15,000달러의 버그 바운티 (bounty)를 받았습니다.