제12장 — 프로토콜 하드닝과 방어

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 열두 번째 글입니다. 지난 장의 모든 위협이 방어를 받지만, 어느 방어도 단일 해결책이 아니며, 그것들의 조합만이 실제로 배포할 수 있는 자세를 만듭니다.

이 장이 존재하는 이유

프로토콜은 배포된다고 안전해지지 않습니다. 맨 프로토콜이 하는 가정을 보상하는 스택 안에 배포될 때 안전해집니다. 제11장은 위협을 카탈로그했습니다. 이 장은 엔지니어링 깊이로 방어를 걸어 갑니다. 암호화 능력 증명이 발견과 능력 에스컬레이션 부류를 닫습니다. 사용자 위임 토큰을 가진 OAuth 2.1 범위 규율이 대리인과 패스스루 부류를 닫습니다. 유계 세션 수명이 세션 하이재킹 부류를 닫습니다. 샌드박싱이 예방이 놓치는 손상을 봉쇄합니다. 사람-개입 승인이 나머지 스택이 쓸모 있으려면 자동화해야 할 파괴적 작업을 잡아냅니다. 각 방어는 잔여 위험을 남기며, 조합이 잔여를 실용적으로 방어할 만큼 작게 만드는 것입니다.

12.1 AttestMCP: 암호화 능력 증명

첫 번째 방어는 거의 모든 위협을 관통하는 문제 — 호스트가 자기와 말하는 서버가 주장하는 것과 일치하는지 검증할 길이 없다 — 를 다룹니다. AttestMCP — MCPSec 또는 서명된 능력 매니페스트라고도 부릅니다 — 는 프로토콜의 메시지 구조 위에 암호화 증명 층을 더합니다. 발행자는 디렉터리나 투명성 로그에 등록된 장수명 서명 키를 보유합니다. 전체 능력 매니페스트는 릴리스 시 해시되고 서명됩니다. 호스트는 initialize 시 파일의 발행자 키에 대해 서명을 검증하고, 서버를 들이거나, 격리하거나, 연결을 거부합니다.

이점은 실제적입니다. 타이포스쿼트는 합법적 발행자로부터 유효한 서명을 만들 수 없습니다. list_changed 알림을 통한 능력 에스컬레이션은 새 매니페스트가 새 서명을 요구하므로 탐지 가능해집니다. 「GitHub 발행 서버는 저장소에는 신뢰하지만 이메일에는 아니다」 같은 세밀한 정책은 발행자 신원이 이제 주장이 아니라 검증 가능하므로 강제 가능해집니다. 비용도 실제적입니다. 발행자는 서명 인프라를 운영해야 하고, 투명성 로그는 신뢰할 수 있는 운영자가 필요하며, 호스트의 정책 층은 폐기를 이해해야 합니다. 정직한 프레이밍은 AttestMCP가 체크박스가 아니라 상당한 엔지니어링이라는 것입니다. 그리고 이름 붙일 만한 간격이 있습니다. 매니페스트는 서버가 자기에 대해 말하는 것에 서명하지, 런타임에 그것이 하는 일에는 서명하지 않습니다. 양성한 도구의 서명된 선언은 여전히 유출하는 구현을 출하할 수 있습니다. 증명은 필요하지만 충분하지 않으며, 그래서 이 장의 나머지가 존재합니다.

12.2 OAuth 2.1 범위와 유계 세션 수명

두 번째 군집은 자격 증명과 세션 모델을 조입니다. OAuth 2.1의 흐름은 성숙합니다. 엔지니어링은 그것을 올바르게 쓰는 데 있습니다. 첫 규율은 좁은 범위입니다 — 선언된 도구 표면이 필요로 하는 것만 요청합니다. 범위가 좁을수록 폭발 반경이 작아집니다. 규율은 들리는 것보다 어렵습니다. 상류 서비스가 종종 범위를 거칠게 정의하고, 좁은 길은 지루하며, 넓은 범위는 첫 시도에 작동해 진전처럼 느껴지기 때문입니다. 좁은 범위의 비용은 엔지니어가 지불합니다. 넓은 범위의 비용은 무언가가 잘못될 때 사용자가 지불합니다.

범위 규율만으로는 제공하지 않는 Confused Deputy에 대한 방어는 사용자 위임 토큰입니다. 상류가 그것을 지원하는 곳에서 각 사용자는 자기 OAuth 흐름을 완료하고, 서버는 자기 서비스 신원이 아니라 사용자의 토큰으로 행동합니다. 서버가 더 이상 자기 권한으로 행동하지 않으므로 대리인이 사라집니다. Token Passthrough는 다른 수정이 있습니다. 토큰을 통과시키지 마십시오. 서버는 등록 시 설립된 자기 자격 증명을 보유하고, 호스트와 서버 사이의 경계는 결코 토큰을 운반하지 않습니다. 유계 세션 수명은 하이재킹을 다룹니다. 위험이 큰 작업에는 분, 일상 작업에는 시간이며, 그 위에 내구성 있는 워크플로 신원이 층을 이뤄 다중 시간 작업이 사용자에게 매 15분마다 재프롬프트하지 않고도 전송 세션을 갱신할 수 있게 합니다. 세션별 능력 결합과 세션 갱신 시 능력 재확인이 규율을 완성합니다 — 둘 다 호스트가 명시적으로 해야 할 상태 관리 작업이며, 많은 구현이 하지 않았습니다.

12.3 샌드박싱과 런타임 격리

세 번째 군집은 모든 위협이 예방될 수는 없으며 방어 가능한 자세가 예방이 실패할 때 피해를 봉쇄해야 함을 인식합니다. 로컬 서버에 대한 프로세스 샌드박싱 — Linux의 seccomp, macOS의 App Sandbox, Windows의 AppContainer, 더 강한 격리를 위한 gVisor — 은 기본적으로 파일시스템, 네트워크, 프로세스 접근을 거부하고 서버가 필요로 하는 특정 접근만 부여합니다. 비밀번호 파일을 읽거나 공격자 엔드포인트로 유출하려는 손상된 서버는 서버의 코드가 자제해서가 아니라 샌드박스가 거부했기 때문에 OS 층에서 작업이 거부되는 것을 발견합니다. 원격 서버에 대한 네트워크 정책 — mTLS, 허용 목록 엔드포인트, 출구 필터링 — 은 손상된 원격 서버가 닿을 수 있는 표면을 좁힙니다. 호스트 안의 콘텐츠 격리는 반환된 콘텐츠가 모델의 컨텍스트로 떨어지기 전에 알맞은 의심으로 다룹니다. 신뢰할 수 없는 마커, HTML 정화, 내장 URL 따르기 거부. 능력 인식 정책을 통한 도구 호출 샌드박싱은 호스트가 호출 인자를 검사하고 허용, 거부, 또는 사용자 승인으로 에스컬레이션할지 결정하게 합니다. 이름 붙일 만한 특정 위험은 합법적 도구를 통한 사이드 채널 유출입니다 — 자격 증명을 검색 쿼리에 인코딩하는 악의적 모델 — 인데, 정책 층이 엔드포인트가 아니라 인자를 검사해 잡아냅니다. 공급망 격리가 루프를 닫습니다. 바이너리의 해시는 설치와 갱신 시 투명성 로그의 서명된 값에 대해 검증되며, 변조된 바이너리는 매니페스트가 확인되어도 돌 수 없습니다.

12.4 사람-개입 승인 게이트

네 번째 군집은 일부 작업이 결코 자동화되어서는 안 됨을 인식합니다. 파괴적, 되돌릴 수 없는, 또는 영향이 큰 호출 — 돈 보내기, 파일 삭제하기, 프로덕션 수정하기 — 은 일어나는 순간에 명시적 사람 결정을 받을 가치가 있습니다. 메커니즘은 HITL 게이트이고, 엔지니어링은 시스템을 쓸 수 없게 만들지 않으면서 효과적으로 만드는 데 있습니다. 가역성으로 분류하십시오. 읽기 전용 작업은 자동으로 진행하고, 상태 변경 작업은 게이트합니다. 의미 있게 제시하십시오. 「도구 실행을 허용합니까?」라고 하는 모달은 고무 도장입니다. 유용한 게이트는 도구, 전체 인자, 평이한 언어로의 결과, 출처를 보입니다. 사용자가 「지난 분기 고객에게 송장을 보내라」를 시작했을 때 일괄을 한 번 승인하고 매 이메일에 20번 승인하지 않는 일괄 맥락 승인으로 승인 피로를 피하십시오. 위험이 큰 작업을 대역 외 — 하드웨어 토큰, 두 번째 기기, 금융 산업에서 빌린 단계 상승 인증 — 로 라우팅하십시오. 작업을 가시적, 감사 가능, 되돌릴 수 있게 유지하십시오. 샘플링 주도 호출은 에이전트 시작 호출과 동일한 게이트를 통과합니다. 서버 시작 추론의 사이드 채널은 사용자가 알아채지 않고 사이드 이펙트로 끝나지 않습니다.

제12장이 준비하는 것

엔지니어링 그림의 보안 절반이 이제 완성되었습니다. 다른 절반 — 프레임워크, 배포 패턴, 성능 특성, 그리고 시스템이 프로덕션에서 작동함을 확인하는 테스트 — 은 남은 장이 다룹니다. 제13장은 그 호를 엽니다. 2025년과 2026년에 자리잡은 프레임워크와 클라우드 통합을 걸어 갑니다. Amazon Bedrock과 함께한 Strands, AWS 상태 층 패턴, Microsoft Agent Framework, LangChain, Semantic Kernel. 프레임워크는 아무도 원시 프로토콜에서 프로덕션 MCP를 짓지 않기에 중요하며, 그것들 중에서의 선택은 프로토콜 층만으로는 결정하지 않는 방식으로 엔지니어링과 보안 자세를 형성합니다.

다음 → 제13장: 프레임워크와 클라우드 통합. Bedrock과 함께한 Strands, AWS 상태 층, Microsoft의 Agent Framework, LangChain, Semantic Kernel, 그리고 팀이 독립적으로 거듭 도착하는 세 가지 프로덕션 통합 패턴.