이 시리즈의 마지막 두 부분에서는 모델 컨텍스트 프로토콜이 화물 API에 어떻게 적용되는지와 2026년에 출시된 프레이트 MCP 서버를 철거했습니다.를 다뤘습니다. 두 부분 모두 동일한 열린 질문으로 끝났으므로, 이번 부분에서는 그 질문에 직접 답합니다. 에이전트가 실제 화물을 예약할 수 있게 되면, 잘못된 사람에게 잘못된 상품을 예약하는 것을 어떻게 막을 수 있을까요? 보안은 화물 MCP 서버가 개발자 장난감처럼 보이지 않고 돈과 트럭을 움직이는 시스템처럼 보이게 만드는 부분입니다.
저는 API를 제공하는 마켓플레이스의 위치에서 이를 실행하므로, 제 편견은 학술적이라기보다는 실용적입니다. 아래의 위협들은 인간의 개입 없이 에이전트가 호출할 수 있는 도구를 결정할 때 실제로 모델링하는 것들입니다.
프레이트 서버가 판돈을 높이는 이유
일반 MCP 서버가 캘린더를 읽을 때 오류가 발생하면 정보가 유출됩니다. 화물 서버가 짐을 예약할 때 더 비싼 일이 발생합니다. 잘못된 지시는 트럭을 잘못된 야드로 보내거나, 실시간 운송의 수하인을 변경하거나, 고객이 기대하는 예약을 취소하거나, 계정에서 절대 나가서는 안 되는 선하증권을 취소할 수 있습니다. 이것은 데이터 노출 버그가 아닙니다. 입력되지 않은 지시에 따라 돈과 실물 상품이 이동하는 것입니다.
이 차이로 인해 전체 문제가 재구성됩니다. 챗봇의 경우 최악의 상황은 당황스러운 답변입니다. 화물의 경우 최악의 상황은 운송 송장이 첨부되고 화물이 의도하지 않은 곳에 있는 것입니다. 따라서 질문은 결코 추상적으로 "이 서버가 안전한가"가 아닙니다. 그것은 "에이전트가 취할 수 있는 특정 행동은 무엇이며, 잘못될 경우 각각의 비용은 얼마인가"입니다.
두 가지 걱정할 만한 고장 모드
2026년 대부분의 MCP 위험은 두 가지 패턴으로 축소되며, 운송이 두 가지 모두를 악화시킵니다.
프롬프트 주입은 낡은 웹 문제가 새로운 옷을 입은 것입니다. 에이전트는 완전히 제어하지 못하는 곳, 즉 운송장, PDF, 이메일 본문 등에서 텍스트를 읽고, 그 텍스트는 모델이 따르는 지침을 포함합니다. 운송업계에서는 악의적인 텍스트가 예약 주석, 세관 설명, 운송업체의 상태 업데이트 등 합법적인 채널을 통해 매일 들어옵니다. 예약 도구가 모델이 전달하는 모든 것을 신뢰한다면, 배송 메모에 숨겨진 한 문장이 실제 취소가 될 수 있습니다.
도구 오염은 미묘하며 MCP에 특화되어 있습니다. 이 프로토콜을 통해 서버는 자체 도구를 설명할 수 있으며, 에이전트는 해당 설명을 읽고 어떤 도구를 호출할지 결정합니다. 악의적이거나 손상된 서버는 모델에게 API 키를 유출하거나 배송을 재라우팅하도록 조용히 지시하는 설명을 작성할 수 있으며, 사용자는 해당 텍스트를 전혀 보지 못합니다. Anthropic과 독립 연구원들은 2026년 초에 이의 변종들을 문서화하는 데 시간을 보냈으며, 그 교훈은 명확합니다: 설명 계층은 실행 가능하므로, 제3자 도구 설명을 제3자 코드를 대하는 것과 동일한 의심으로 취급해야 합니다.
읽기 대 쓰기: 인증을 결정해야 할 경계
제가 내린 가장 유용한 보안 결정은 "MCP 서버"를 하나의 신뢰 경계로 생각하는 것을 멈추고 각 도구가 세상에 미치는 영향별로 분리한 것입니다.
무엇을 열어둘 수 있나요?
차선 견적, 용량 목록, 운송 예상 시간 계산, 항구 코드 조회. 이 중 어느 것도 아무것도 바꾸지 않습니다. 에이전트가 거의 또는 전혀 마찰 없이 그들에게 연락할 수 있도록 하는 것이 핵심이며, 이것이 일상적인 가치가 있는 부분입니다. 세 가지 경로를 비교하고 싶은 독자가 이를 위해 토큰을 발행할 필요는 없습니다. 분해된 서버들 전반에 걸쳐, 진지한 곳에서는 바로 이 이유로 낮은 마찰의 견적 및 참조 도구를 유지했습니다.
무엇을 제한해야 합니까
예약, 취소, 수하인 변경, 주소 편집, 문서 검색 등 송장에 관련된 모든 것. 이 모든 것은 실세계에 기록되며, 모든 것은 그 뒤에 인증되고 권한이 부여되며 감사 가능한 호출을 필요로 합니다. 우리가 따르는 규칙은 말하기는 쉽지만 시행하기는 더 어렵습니다. 읽기 도구는 공개될 수 있지만 쓰기 도구는 절대 공개될 수 없습니다.
OAuth 2.1 및 PKCE, 설정 파일에 오래 지속되는 키는 아님
MCP 승인 사양은 원격 서버에 OAuth 2.1을 채택했으며, 그 선택은 운송에 실질적인 영향을 미칩니다. 정적 API 키를 구성 파일에 붙여넣는 것은 자신의 기계에서 stdio를 통해 서버를 실행하는 솔로 개발자에게는 괜찮습니다. 하지만 서버가 HTTP를 통해 접근 가능하고 에이전트가 공유 계정 내의 명명된 사용자 대신 행동하는 순간에는 잘못된 모델입니다.
세 가지 속성이 핵심적인 역할을 합니다. 스코프 지정된 토큰은 인용을 위해 발급된 토큰이 예약을 할 수 없다는 것을 의미합니다. 단기 토큰은 유출된 자격 증명이 영원히 로그에 남는 대신 자체적으로 만료된다는 것을 의미합니다. 취소 가능한 토큰은 문제가 발생했을 때 모두가 의존하는 공유 키를 순환하는 대신 몇 초 만에 액세스를 차단할 수 있다는 것을 의미합니다. OAuth 2.1은 또한 권한 부여 코드 흐름에서 PKCE를 요구하는데, 이는 이전 OAuth 배포에서 열려 있던 가로채기 간극을 닫습니다. 이 중 어느 것도 이국적인 것은 아닙니다. 이는 결제 API가 겪었던 것과 동일한 강화 조치를 에이전트가 "예약하라"고 말하는 순간에 적용한 것입니다.
저희가 적용하는 경계의 형태는 다음과 같으며, 모든 화물 서버가 게시해주었으면 하는 표로 작성했습니다.
| **에이전트 행동** | **읽기 또는 쓰기** | 필요한 인증 | 잘못될 경우 |
| 견적 받기 | 읽기 | 열림 또는 기본 키 | 헛된 전화, 피해 없음 |
| 용량, 운송, 추적 확인 | 읽기 | 열림 또는 기본 키 | 최악의 경우 낡은 답변 |
| 배송 예약 | 쓰기 | 범위가 지정된 OAuth 토큰, 확인 단계 | 실제 비용, 실제 트럭 |
| 취소 또는 재예약 | 쓰기 | 스코프 토큰, 멱등성 키 | 분실된 슬롯, 벌금 |
| 수하인 또는 주소 변경 | 쓰기 | 스키핑 토큰, 사람 확인 | 오배송, 사기 |
| 선하증권 또는 송장을 요청하세요 | 민감한 읽기 | 스코프 토큰, 문서별 확인 | 데이터 및 문서 유출 |
그 테이블의 패턴이 실제 제품 결정입니다. 읽기는 왼쪽에 있고 저렴하게 유지됩니다. 쓰기는 오른쪽에 있으며 마찰을 감수합니다.
노출된 인스턴스 문제
MCP 위험의 놀라운 양은 전혀 영리하지 않습니다. 그것은 단순히 로컬에서 실행되도록 만들어진 서버인데, 인증 없이 공개 인터넷에 노출된 것입니다. 그것을 그렇게 배포하는 것이 더 쉬웠기 때문입니다. 이 프로토콜은 두 가지 전송 방식을 지원합니다. stdio 서버는 클라이언트가 실행하는 로컬 프로세스로 실행되므로, 서버가 사용자의 컴퓨터에 남아 있고 네트워크에 노출되지 않도록 합니다. 호스팅된 HTTP 서버는 해당 URL을 찾을 수 있는 모든 것에 의해 접근할 수 있습니다.
실행만 가능한 유틸리티 서버의 경우 HTTP 노출은 대부분 무해합니다. 예약 기능이 있는 서버의 경우 이는 전적으로 중요합니다. 쓰기 기능에 대한 접근이 공개 HTTP를 통해 가능하다면, 인증은 나중에 추가하는 기능이 아니라 낯선 사람과 예약 큐 사이에 있는 것입니다. 저희 규칙은 예약 및 문서 도구는 절대 인증되지 않은 HTTP 엔드포인트를 통해 제공되지 않는다는 것입니다. 의심스러울 경우, 쓰기 가능한 서버는 기본적으로 stdio와 로컬 실행을 사용해야 하며, 위의 OAuth 흐름이 적용된 후에야 호스팅된 HTTP로 전환해야 합니다.
설명 계층을 도구 오염으로부터 방어
도구 설명은 모델을 유도하므로 배포하는 코드와 동일한 제어 기능을 제공해야 합니다. 세 가지 습관이면 대부분의 노출을 다룰 수 있습니다.
- 연결하는 서버를 고정하고 검토하세요. 알려진 서버 세트에 연결된 에이전트는 레지스트리에서 제공하는 모든 것을 설치하는 에이전트보다 표적이 되기 어렵습니다. 새로운 서버는 새로운 종속성과 같으므로 그렇게 취급하십시오.
- 모든 작성마다 사람을 참여시키세요. 수하인 정보를 예약, 취소 또는 변경하기 전에 확인 단계를 거치면, 자동으로 삽입된 지시가 사용자에게 표시되어 거부할 수 있는 요청으로 변환됩니다. 이는 가장 저렴하면서도 가장 높은 효과를 얻을 수 있는 통제 방법입니다.
- API에서 검증하세요. 프롬프트에서는 안 됩니다. 모델이 타당한 호출을 만들었다고 신뢰하는 대신, 서버는 수신하는 모든 매개변수를 계정의 실제 권한 및 예약의 실제 상태와 비교하여 다시 확인해야 합니다. 모델이 제안하고 API가 결정합니다.
단일 캐리어가 건너뛸 수 있도록 마켓플레이스 서버가 적용해야 하는 부분은 무엇입니까?
단일 통신사 서버는 자체 네트워크에서만 작동하므로 공격 범위가 한 명의 운영자에게 국한됩니다. 마켓플레이스 서버는 여러 사용자를 대신하여 여러 통신사 간의 거래를 견적하고 예약하므로 보안 업무가 두 가지 방식으로 변경됩니다.
먼저, 스코핑은 서버별이 아니라 사용자별 및 캐리어별이어야 합니다. 한 에이전트가 특정 캐리어와 예약을 할 수 있도록 허용하는 토큰이 다른 캐리어에 암묵적으로 도달해서는 안 되며, 한 고객의 에이전트는 다른 고객의 문서를 절대 볼 수 없어야 합니다. 둘째, 감사 추적이 더 중요합니다. 에이전트가 마켓플레이스 전체에서 예약을 할 때 매번 "어떤 사용자, 어떤 토큰, 어떤 캐리어, 언제"에 대한 응답이 필요하기 때문입니다. 우리는 이 로그를 애프터마켓이 아닌 제품의 일부로 취급합니다. 이 로그 덕분에 모든 것을 중단시키는 대신 제한적으로 취소할 수 있기 때문입니다.
예약 공개 전 실용적인 체크리스트
- 읽기 도구와 쓰기 도구를 분리하고, 에이전트와 당신의 팀 모두 볼 수 있는 곳에 분리 결과를 작성하세요.
- 일상의 가치가 유지될 수 있도록 인용 및 참조 도구를 사용하기 쉽게 유지하세요.
- 모든 쓰기를 PKCE가 적용된, 범위가 제한되고, 짧은 수명을 가지며, 취소 가능한 OAuth 2.1 토큰 뒤에 두세요.
- 예약, 취소, 수하인 및 주소 변경 시 확인 단계를 요구합니다.
- API의 모든 매개변수를 실제 권한 및 실제 배송 상태를 기준으로 다시 유효성 검사하십시오.
- 인증되지 않은 HTTP를 통해 쓰기 도구를 절대 제공하지 말고, 기본적으로 쓰기 가능한 서버를 로컬 stdio로 설정하세요.
- 에이전트가 연결하는 서버를 고정하고 새 코드처럼 새로운 서버를 검토하세요.
- 사용자, 토큰, 캐리어 및 시간별로 모든 쓰기를 기록하고, 필요하기 전에 철회 절차를 숙지하십시오.
이것들 중 어느 것도 인공 지능에만 국한된 것은 아닙니다. 이들은 이미 화물 및 결제에서 사용하는 제어 기능을 새로운 발신 지점으로 향하게 하는 것입니다. 에이전트는 새로운 규칙이 아니라 새로운 발신자입니다.
자주 묻는 질문
AI 에이전트가 화물 예약을 전적으로 맡기기에 안전할까요?
네, 예약은 인증 및 권한 부여된 호출 뒤에 확인 단계를 거치고, 서버가 모델을 신뢰하는 대신 모든 매개변수를 다시 확인할 때 수행됩니다. 안전하지 않은 버전은 사람의 개입이 없는 개방형 쓰기 도구입니다. 예약을 돈을 움직이는 다른 모든 작업처럼 취급하고 에이전트를 또 다른 인증된 호출자로 만드세요.
간단한 API 키 대신 OAuth 2.1을 사용하는 이유는 무엇인가요?
정적 키는 수명이 길고, 범위가 넓으며, 공유하는 모든 사람에게 영향을 주지 않고 폐기하기 어렵다는 단점이 있습니다. OAuth 2.1은 범위를 지정할 수 있고, 수명이 짧으며, 폐기 가능한 토큰을 제공하고, 인가 흐름에 PKCE를 요구합니다. 로컬 stdio 서버의 경우 키를 사용해도 괜찮지만, HTTP를 통해 접근 가능하고 쓰기 권한이 있는 모든 것은 OAuth 모델을 사용해야 합니다.
MCP에서 툴 포이즈닝이란 무엇인가요?
도구 독성(Tool poisoning)은 에이전트가 호출할 도구를 결정하기 위해 읽는 서버의 도구 설명에, 키 유출이나 배송 재경로와 같은 위험한 행동으로 모델을 유도하는 숨겨진 지침이 포함되는 경우를 말합니다. 설명이 행동에 영향을 미치기 때문에, 신뢰할 수 있는 서버 고정, 작성자에 대한 인력 유지, API에서의 검증과 같이 코드를 방어하는 방식으로 도구 설명을 방어해야 합니다.
프레이트 MCP 서버를 stdio로 실행해야 할까요, 아니면 호스팅된 HTTP로 실행해야 할까요?
읽기 전용 유틸리티 서버는 호스팅된 HTTP 위에서 작동해도 괜찮습니다. 예약 또는 문서 도구를 갖춘 서버는 기본적으로 로컬 stdio를 사용해야 하며, 범위 지정된 OAuth가 적용된 후에만 호스팅된 HTTP로 전환해야 합니다. 왜냐하면 인증 없는 쓰기 엔드포인트는 URL을 찾는 누구나 접근할 수 있기 때문입니다.
이것으로 이 시리즈의 시작이 마무리됩니다. 이전 부분을 읽지 않으셨다면, 프로토콜 총람는 화물 API가 도구 모음으로 어떻게 발전하는지 설명하고, 해체는 배송된 서버가 실제로 이러한 경계를 어떻게 설정했는지 보여줍니다.