에이전트 프로토콜 (Agent protocols)이 일반적인 소프트웨어 인프라에 통합되면서 통합이 더 쉬워지고 있습니다. 그리고 이는 소유권(ownership)을 더욱 모호하게 만들고 있습니다.

이 모든 것들은 통합을 더 쉽게 만들어 주므로, 에이전트들이 빠르게 협업하기를 원하는 제품 팀에게는 매우 좋은 일입니다. 하지만 이는 사양 (specification)에 더해 또 다른 실패 지점 (failure surface)이 됩니다. 이 경우, 콘텐츠는 빠르게 흐르며 위임 (delegation), 상태 (state) 및 기타 모든 것에 대한 서로 다른 표준들도 빠르게 흐릅니다. 반면, 소유권은 전통적으로 조직도 (org chart)를 통해 그보다 더 느리게 이동해 왔기 때문에, 이러한 불일치는 모두에게 문제가 됩니다.

서로 다른 에이전트 프로토콜의 통합과 그 구성 (composition)의 보안에 관한 연구가 등장하고 있습니다. 2026년 논문인 Formal Security Analysis of Agent Protocol Composition은 5개의 에이전트 프로토콜을 조사하여 35개의 사양 수준 (specification-level) 발견 사항을 찾아냈고, 이를 80개의 상세한 구현 테스트 (implementation tests)로 뒷받침했으며, 프로토콜들이 더 큰 시스템의 일부로서 함께 구성되었을 때 발견된 30개의 실패 사례를 추가했습니다.

마침내, AI 에이전트 벤더들이 서로 연결되도록 압박해 온 수년간의 노력이 결실을 맺기 시작하고 있습니다. 고립된 '에이전트'에 의해 수행될 수 있는 작업은 식은 죽 먹기입니다. 기업의 업무는 모든 방향으로 경계를 넘나드는 것입니다. 파일, 작업 항목 (work items), 일정, 데이터베이스, CRM 시스템의 고객 기록, 브라우저에서 조회하는 웹 페이지, 소프트웨어 저장소 (repositories), 그리고 내부 서비스를 위한 API를 가로질러야 합니다.

로컬에서는 깔끔하지만, 글로벌하게는 불투명합니다.

프로토콜은 통신을 표준화할 뿐, 책임을 표준화하지 않습니다

구매자 참고 사항: IBM의 유용한 정의에 따르면 AI 에이전트 프로토콜은 AI 에이전트 간, 그리고 에이전트와 다른 시스템 구성 요소 간의 통신을 표준화합니다. 프로토콜은 워크플로 조정 (workflow coordination), 실행 (execution) 또는 최적화 (optimization)를 표준화하지 않습니다. 프로토콜 지원이 제어 평면 (control plane) 기능까지 자동으로 포함한다고 믿는 어리석은 실수를 범하지 마십시오.

MCP (Model Context Protocol)는 에이전트가 도구 (tools)를 발견하고 호출할 수 있게 해줍니다. A2A (Agent to Agent)는 독립적인 에이전트들이 표준 인터페이스를 사용하여 서로 상호작용할 수 있게 합니다. ACP (Agent Communication Protocol)는 에이전트들이 REST 인터페이스(동기 및 비동기, 스트리밍, 상태 유지(stateful) 및 상태 비유지(stateless), 온라인 및 오프라인, 장기 실행(long running) 등)를 사용하여 서로 상호작용할 수 있게 합니다. 이는 두터운 문법 계층 (thick grammar layer)을 기술합니다.

문법은 누가 급여 명세에 접근할 수 있는지를 결정하지 않습니다.

A2A 1.0 명세서는 A2A를 세 가지 계층, 즉 정형 데이터 모델 (canonical data model), 추상적 연산 (abstract operations), 그리고 특정 프로토콜에 대한 바인딩 (bindings)의 관점에서 설명합니다. 부록 A는 기업용 패턴을 축소하여 보여줍니다. A2A 클라이언트 에이전트는 A2A 서버 에이전트에게 작업을 수행하도록 요청합니다. 그러면 서버 에이전트는 MCP가 지원하는 도구와 API를 사용할 수 있습니다. 이 아키텍처는 기업용 작업에 유용하며, 사람들이 AI 에이전트를 향해 나아가고 있는 정확한 방향입니다.

ACP는 명시적으로 말하기 어려운 부분을 직접 언급합니다. Agent Communication Protocol 문서는 서로 다른 프레임워크, 팀, 인프라 간의 상호 운용성 (interoperability)을 제안합니다. ACP는 REST API를 노출하며, 따라서 API를 호출하는 메서드(method) 입장에서는 내부가 불투명합니다 (opaque). 이는 장기 실행 작업, 취소, 메시지 스트리밍 및 발견 (discovery)을 지원합니다. 하지만 언제나 그렇듯, 메서드 호출로서 유효해 보이는 것이 더 긴 복합 작업 경로 (composed path of actions)의 일부로서 런타임 (runtime)에 실행될 때는 여전히 잘못될 수 있습니다.

Architecture map showing an A2A client delegating to an A2A server that calls MCP tools while runtime policy and trace audit span the protocol seam.

위험한 경계는 로컬에서 유효한 프로토콜 호출들이 하나의 복합 경로가 되는 지점입니다.

이것이 바로 MCP 보안이 도구 승인 이후에 시작되는 이유입니다. 서버를 승인하고, 도구를 등록하며, 스키마 (schema)를 확인하는 것은 단지 로컬 구성 요소가 클라이언트가 인식할 수 있는 형태를 갖추고 있음을 증명할 뿐입니다. 런타임 (Runtime) 보안은 시스템이 다음과 같은 일련의 질문을 던질 때 시작됩니다: 무엇이 변했는가? 어떤 권한 (authority)이 전달되고 있는가? 어떤 콘텐츠가 모델의 컨텍스트 (context)에 입력되었는가? 작업이 수행된 후에는 어떤 증거가 남게 되는가?

실패는 콘텐츠, 위임, 그리고 권한을 통해 이동합니다

AgentThread 논문에는 단순하지만 보안 팀이 주의 깊게 살펴봐야 할 예시가 포함되어 있습니다. 하나의 MCP 서버가 공격자가 제어하는 웹 콘텐츠를 가져옵니다. 숨겨진 지시 사항이 모델 컨텍스트 (model context)로 유입됩니다. 두 번째 MCP 서버는 파일 접근 권한을 가지고 있습니다. 에이전트 (agent)는 로컬 데이터를 읽고 이를 첫 번째 서버를 통해 다시 외부로 전송합니다. 논문은 이러한 불안전한 동작을 구성 (composition), 암묵적 권한 전송 (implicit authority transfer), 동의 누락 (missing consent), 그리고 에이전트 런타임 전반에 걸친 취약한 감사 가시성 (weak audit visibility)으로 설명합니다.

단일 작업 하나하나가 비정상적일 필요는 없습니다. 웹 페이지를 가져오고, 로컬 파일을 읽고, 그 결과를 전송하는 것뿐입니다.

실패는 바로 그 경로 (path)에 있습니다.

MCP 보안을 단일 서버에 대한 체크리스트로 보는 기존의 프레임워크는 너무 협소합니다. CoSAI의 Model Context Protocol Security 백서는 MCP를 신원 (identity), 접근 제어 (access control), 입력 및 데이터 경계 (input and data boundaries), 신뢰 경계 (trust boundaries), 라이프사이클 거버넌스 (lifecycle governance), 로깅 (logging), 모니터링 (monitoring), 그리고 감사 가능성 (auditability)을 포함하여 12개의 위협 카테고리와 거의 40개의 위협으로 매핑합니다. 이러한 분류 체계 (taxonomy)는 배포 설계 (deployment design) 단계에서 다루어져야 합니다.

이는 도구 호출 경계 (tool-call boundary)에 관한 이전 포스트와 관련이 있습니다. AI 에이전트 보안은 도구 호출 단계에서 발생합니다. 하지만 이제 도구 호출이 더 큰 복합 경로 (composed route) 내의 하나의 노드 (node)가 됨에 따라, 런타임 (runtime)은 해당 도구를 호출하기 전에 발생했던 콘텐츠와 위임 (delegation)을 기억해야 합니다. 도구 호출만을 확인하는 런타임은 건물 안에 터널이 있음에도 불구하고 단 하나의 문에서만 경비원 역할을 수행하는 것과 같습니다.

SDK 준수 (conformance)는 런타임 안전성 (runtime safety)이 아니다

저는 표준 (standards)을 선호합니다. 커스텀 커넥터 (custom connectors)가 줄어들기를 바랍니다. 에이전트가 상응하는 데이터 객체 (data objects) 간의 필드 매핑에 6개월을 허비하지 않고도 도구, 에이전트, 서버에 연결할 수 있기를 바랍니다.

AgentThread 저자들은 프로토콜 수준에서의 보안 실패를 다음과 같이 별개의 문제로 세분화하여 설명합니다: 단일 프로토콜 내의 안전하지 않은 동작, SDK 권장 사항의 누락, 배포 경화 (deployment hardening)의 누락, 그리고 프로토콜 간 사례에서의 할당되지 않은 책임. 궁극적으로 저자들은 에이전트-프로토콜의 불안전성이 프로토콜, SDK, 그리고 배포 전반에 걸친 책임의 공백에서 기인한다는 것을 발견했습니다. 이는 의미론적 콘텐츠 (semantic content), 위임된 권한 (delegated authority), 그리고 도구 접근 권한이 프로토콜 경계를 넘나들 때 발생하는 실패입니다.

에이전트-프로토콜 상호작용을 보안하기 위해 필요한 일련의 기능들이 세 개의 SDK에 분산되어 있고 위키 (wiki)에 문서화되어 있다면, 결국 그 경계면 (seam)을 책임지는 사람은 아무도 없게 됩니다.

멀티 에이전트 시스템 (multi-agent systems)은 보안이라는 추가적인 복잡성 없이도 이미 이러한 종류의 문제를 드러내고 있습니다. 우리는 멀티 에이전트 시스템이 협업 평면 (collaboration plane), 즉 에이전트 간의 주장 (claims), 발견 (findings), 인계 (handoffs), 그리고 공유 상태 (shared-state) 수준에서 어떻게 무너지는지에 대해 작성한 바 있습니다. 최악의 경우, 유실된 발견 사항은 보안 사고로 이어지고, 유실된 권한 경계는 침해 보고서 (breach report)로 이어집니다.

프로토콜 스택 상단의 경계면 (seam)을 책임져라

해결책은 프로토콜 구성 (protocol composition)을 런타임 표면 (runtime surface)으로 취급하는 것에서 시작됩니다.

표준 위원회(Standards committees)는 문법(grammar)을 개선할 수 있습니다. 벤더(Vendors)는 더 나은 SDK를 출시할 수 있습니다. 보안 팀은 인기 있는 서버들을 검토할 수 있습니다. 좋습니다. 하지만 MCP, A2A, ACP, AG-UI, 브라우저 도구(browser tools), 파일 도구(file tools), 그리고 내부 API(internal APIs)를 결합하는 런타임(runtime)은 여전히 구성 정책(composition policy)을 소유해야 합니다.

Responsibility matrix showing protocol specs and SDKs handling local grammar while runtime and application owners handle cross-protocol intent, authority, content labels, trace context, and rollback.

표준은 문법을 정의합니다. 시스템 소유권(System ownership)은 그 상위 단계에서 할당되어야 합니다.

첫째, 프로토콜 경계(protocol boundaries)를 가로지르는 모든 단계는 실행 기록(execution record)을 남겨야 합니다. 여기에는 주체(principal, 사용자 또는 후원자), 원래의 목적(original objective), 위임된 목적(delegated objective), 소스 콘텐츠 분류(source-content classification), 요청된 도구 또는 작업(requested tool or action), 대상 리소스(target resource), 자격 증명 범위(credential scope), 정책 결정(policy decision), 그리고 결과물(resulting artifact)이 포함되어야 합니다. 이를 "원장(ledger)", "영수증 체인(receipt chain)", 또는 "프로토콜 구성 기록(protocol-composition record)"이라고 부를 수 있습니다. 중요한 점은 이 기록이 전체 구성 경로(composition path)에 대해 존재해야 하며, 실행이 지속되는 동안 보존되어야 한다는 것입니다.

프로토콜 간 작업(cross-protocol actions)이 실행됨에 따라, 프로토콜 내 이전 단계에 부여된 권한은 제한되어야 합니다. 즉, 프로토콜의 후속 단계들이 위에서 식별한 권한 축소(authority narrowdowns)에 따라 추가적인 정당성 입증이나 승인(authorization)을 요구하도록 해야 합니다. 특히, A2A 위임(delegation)은 호출 주체(calling principal)의 주변 권한(ambient authority)을 후속 에이전트(agents)에게 전달해서는 안 됩니다. MCP 도구 호출(tool calls)은 인간의 세션(human's session)이 아닌 현재 작업에 범위가 제한된 자격 증명(credentials scoped to the task at hand)으로 실행되어야 하며, 브라우저 측 에이전트(browser-side agents)는 편리한 프로토콜 브리지(protocol bridge)의 결과로 백엔드 권한(backend privileges)을 암묵적으로 상속받아서는 안 됩니다.

셋째, 신뢰할 수 없는 콘텐츠(untrusted content)는 런타임(runtime)에 의해 그 출처가 라벨링(labelled)되어야 합니다. 이를 통해 정책(policy)이 이후의 콘텐츠가 해당 신뢰할 수 없는 콘텐츠의 모델 처리(model processing)를 포함하는 동작을 정당화하는 데 사용될 수 있는지 여부를 결정할 수 있습니다. 모델에 새로운 텍스트가 주입될 때 이를 스캔하기만 하는 단순한 프롬프트 인젝션(prompt-injection) 방어 기제는, 주입된 텍스트가 예를 들어 웹 페이지, 티켓 댓글, 이메일 본문 등으로 구성되어 있다면 효과적이지 않을 것입니다. 이러한 콘텐츠를 단순히 "사용자(user)"로부터 유래한 것으로 라벨링하는 것만으로는 그 사용을 제어하기에 불충분합니다. 왜냐하면 해당 콘텐츠가 사실상 거의 모든 후속 동작을 정당화하는 데 사용되는 것이 허용될 것이기 때문입니다.

넷째, 프로토콜 경계(protocol boundaries)를 가로질러 트레이스 컨텍스트(trace context)를 함께 전달해야 합니다. 앞서 언급했듯이, 에이전트 트레이스는 MCP 경계를 넘어야 합니다. 그렇지 않으면 도구/서비스 스팬(tool/service spans)이 없는 플래너 트레이스(planner traces)만 남게 되는데, 이는 범죄 현장이 빠진 유용한 이야기와 같습니다. 하지만 프로토콜 구성(protocol composition)이 포함되는 경우, A2A 또는 ACP에 의해 수행되는 다운스트림 호출(downstream calls) 또한 MCP 경계를 넘을 수 있으며, 따라서 그들이 생성하는 트레이스 역시 경계를 넘어야 합니다. 만약 각기 다른 프로토콜이 서로 간의 상관관계가 없는 별개의 트레이스를 생성한다면, 사고 후 검토(post-incident review)는 순수한 고고학 작업이 될 것입니다.

다섯째, 실패 시 무엇을 되돌릴지(rollback)에 대한 추적 또한 구성된 경로(composed path)에 부착되어야 합니다. 되돌려야 할 단계의 수는 이미 작업을 완료하는 데 필요한 단계의 수를 쉽게 초과할 수 있습니다. 만약 도구가 티켓을 생성하고, 파일을 업데이트하고, 고객에게 이메일을 보내고, Salesforce와 같은 CRM을 업데이트하고, 메모리에 무언가를 저장한다면, 이 모든 단계는 전체로서 되돌릴 수 있어야 합니다. 그렇지 않으면 실패 시 할 수 있는 유일한 일은 수동으로 난장판을 치우는 것뿐이며, 이는 이미 기업 환경에서 일어나고 있는 일입니다(전형적인 사례입니다).

런타임은 구매자가 실제로 얻게 되는 보안 경계입니다

프로토콜 생태계는 올바른 방향으로 나아가고 있습니다. MCP는 도구 통합의 마찰을 줄였습니다. A2A는 독립적인 에이전트들에게 작업 상태를 위임하고 보고할 수 있는 공유된 방식을 제공합니다. ACP는 팀들에게 에이전트 상호운용성 (interoperability)을 위한 간단한 HTTP 경로를 제공합니다. 이것들은 유용한 워크플로우 (workflow)를 구축하기 위한 좋은 도구들입니다.

하지만 이것들은 설계상으로도 불완전합니다.