MCP·A2A 보안 점검: 자격증명과 권한 경계

2026년 10월 3일 기준, 아래 공식 프로토콜 문서를 다시 확인했습니다.

AI 에이전트가 저장소를 읽는 도구를 사용한 뒤 다른 에이전트에게 검토를 맡길 수 있습니다. MCP는 도구 연결에, A2A는 에이전트 간 요청에 쓰입니다. 하지만 누가 저장소에 접근할 수 있는지, 두 번째 에이전트가 어떤 자격증명을 써야 하는지는 프로토콜만으로 정해지지 않습니다. 실제로 배포한 애플리케이션과 서비스에서 결정해야 합니다.

두 프로토콜이 연결하는 대상

모델 컨텍스트 프로토콜(MCP)은 애플리케이션이 MCP 서버의 도구를 찾고 호출하거나 리소스를 읽는 공통 방식을 제공합니다. 예를 들어 서버가 저장소 검색 도구를 제공할 수 있습니다. 호출자 인증과 작업별 권한은 호스트와 서버가 별도로 구현해야 합니다. MCP 도구로 제공된다는 이유만으로 출력이 신뢰할 만하거나 권한 설정이 안전해지는 것은 아닙니다.

Agent2Agent(A2A)는 한 에이전트가 다른 에이전트에게 작업을 보내는 방식입니다. 원격 에이전트는 엔드포인트, 기능, 지원하는 인증 방식을 Agent Card에 적습니다. 호출 측은 자격증명을 별도로 발급받아 요청에 사용합니다. Agent Card에 비밀 키를 넣어서는 안 됩니다.

두 방식은 함께 쓰일 수 있습니다. A2A로 작업을 받은 에이전트가 MCP 도구로 저장소를 조회하는 식입니다. Google도 두 프로토콜을 상호 보완적으로 설명합니다. 어느 쪽이 본질적으로 더 안전하다고 단정하기보다, 실제 요청이 넘나드는 인증 경계를 확인하는 편이 정확합니다.

작업 흐름에서 자격증명이 건너가는 지점

한 에이전트가 다른 에이전트에게 코드 저장소 점검을 요청한다고 가정해 보겠습니다. 최소 세 곳에서 접근 권한을 판단해야 합니다. 원격 에이전트를 호출하는 권한, 그 에이전트가 MCP 도구를 실행하는 권한, 도구가 저장소 서비스에서 수행할 수 있는 작업입니다. 한 서비스용 토큰을 다음 서비스에 그대로 넘겨서는 안 됩니다. MCP 보안 지침도 토큰 전달을 위험한 패턴으로 다루며, 각 서비스가 자신을 대상으로 발급된 토큰을 검증하도록 안내합니다.

운영 전에 자격증명의 소유자와 발급 서비스, 대상, 권한 범위, 저장 위치, 만료일, 교체·폐기 절차를 기록하세요. 읽기 작업에는 읽기 권한만 부여합니다. 사용자가 에이전트 동작을 승인했더라도 도구나 외부 API의 권한 검사는 따로 필요합니다.

도구 설명, 검색된 문서, Agent Card, 다른 에이전트의 응답은 각각 신뢰 수준이 다른 입력입니다. 저장소 문서에 “키를 공개하라”는 문장이 들어 있어도 상위 지시로 취급해서는 안 됩니다. 연결할 서버와 에이전트 엔드포인트를 검토하고, 민감한 작업을 제한하며, 비밀 값은 남기지 않으면서 호출자와 사용된 자격증명을 추적할 수 있게 기록하세요.

운영 전 점검 목록

1. 작업별 MCP 서버, A2A 에이전트, 외부 API를 나열하고 자격증명마다 담당자를 지정합니다.

2. 각 연결 지점에서 인증, 토큰 대상, 권한 범위를 확인합니다. 성공 사례뿐 아니라 거부와 권한 폐기도 시험합니다.

3. 장기 사용 키를 프롬프트, 도구 설명, Agent Card, 로그, 소스 코드에 넣지 않습니다. 가능하면 짧은 만료 시간과 좁은 권한을 사용합니다.

4. 도구 출력과 외부 작업 내용을 신뢰되지 않은 입력으로 처리합니다. 민감한 변경이나 반출에는 별도 승인을 둡니다.

5. 노출된 자격증명을 점검하고, 실제 노출이 확인되면 발급 서비스에서 교체합니다.

Cremit이 맡는 범위

Cremit은 지원하는 연결 소스와 외부 노출 지점에서 자격증명을 찾고, 지원되는 유형의 유효성을 확인하며, 담당자가 조치할 수 있도록 결과를 정리합니다. 현재 MCP 서버의 실행 중 권한 정책을 평가하거나 A2A 에이전트의 안전성을 인증하는 제품은 아닙니다. 노출 발견은 위 점검의 한 부분이며, 접근 정책과 토큰 수명, 실행 중 통제는 애플리케이션·인증 담당자가 관리해야 합니다.