AI 도구의 권한을 설명 밖에서 확인하는 법

MCP의 읽기 전용·파괴적 변경·멱등성·외부 상호작용 힌트가 뜻하는 바를 살피고, 도구 설명을 실제 접근 통제와 연결해 업무 자동화를 검증하는 방법을 설명한다.

GPT Image 2로 생성한 개념 이미지입니다. 특정 제품의 구조나 실제 보안 장치를 재현한 그림이 아닙니다.

문서를 찾아주는 AI 도구 옆에 ‘읽기 전용’이라는 표시가 있다. 사용자는 그 도구가 원본을 바꾸지 않을 것이라 기대한다. 운영 담당자도 확인창을 줄일 근거로 삼고 싶다. 그런데 그 표시는 누가 붙였고, 약속과 다른 실행을 막는 장치는 어디에 있을까.

AI가 여러 업무 도구를 연결해 쓰기 시작하면 이름과 설명만으로 실행 범위를 파악하기 어려워진다. ‘미리보기’가 실제로는 서버에 초안을 저장할 수도 있고, ‘추가’가 외부 고객에게 새 메시지를 보내는 일일 수도 있다. 도구를 잘 설명하는 일과 허용된 동작만 실행하게 만드는 일은 함께 설계해야 한다.

MCP(Model Context Protocol)는 모델이 사용할 도구의 이름, 입력 구조, 동작에 관한 메타데이터를 전달한다. 그중 ToolAnnotations는 도구가 환경을 바꾸는지, 같은 호출을 반복해도 추가 효과가 없는지 등을 알려주는 힌트다. 이 정보를 어떻게 읽고 어디까지 믿을지 정하면, 자동화의 편의와 실행 권한을 더 구체적으로 다룰 수 있다.

네 가지 힌트가 서로 다른 질문에 답한다

이 글에서 확인한 MCP 2026-07-28 명세의 ToolAnnotations 스키마는 참·거짓으로 표시하는 다음 네 가지 힌트를 정의한다. 표의 기본값은 속성을 생략했을 때의 명세상 해석이며, 특정 앱이 실제로 보여주는 표시나 승인 정책을 뜻하지 않는다.

destructiveHint와 idempotentHint는 readOnlyHint가 거짓일 때 의미가 있다. 읽기 전용이 아닌 도구의 변경 성격을 더 설명하는 속성이기 때문이다. 주석을 생략한 도구를 읽기 전용으로 간주하거나, 비어 있는 값을 모두 낮은 위험으로 해석하면 기본값의 방향을 잘못 읽게 된다.

각 힌트의 질문도 구분해야 한다. 파괴적 변경을 하지 않는 도구라도 새 문서를 만들거나 메시지를 추가할 수 있다. 외부 수신자에게 새 메시지를 보내는 동작은 기존 자료를 지우지 않아도 업무상 영향이 크다. ‘추가만 한다’는 설명에서 승인 불필요라는 결론은 나오지 않는다.

멱등성은 같은 인자의 반복 호출이 환경에 추가 효과를 남기는지에 관한 성질이다. 호출할 때마다 같은 문장이 반환된다는 뜻도, 그 호출을 할 권한이 있다는 뜻도 아니다. 마찬가지로 닫힌 범위와 상호작용한다는 openWorldHint: false가 데이터의 공개성이나 실행 환경의 격리를 보장하지는 않는다. 내부 자료만 읽는 도구에도 접근 범위가 필요하다.

설명을 믿는 근거와 실행을 막는 장치를 연결한다

스키마는 제목을 포함한 모든 주석이 실제 동작을 충실하게 설명한다고 보장하지 않는다고 명시한다. 신뢰하지 않는 서버에서 받은 주석을 도구 사용 결정의 근거로 삼아서는 안 된다는 설명도 있다. Tools 명세는 신뢰하는 서버가 제공한 경우를 제외하면 클라이언트가 주석을 신뢰하지 않는 정보로 취급해야 한다고 규정한다.

이는 힌트를 버리라는 뜻으로 읽을 필요는 없다. 서버의 운영 주체와 구현을 확인한 환경에서는 도구를 분류하거나 확인 화면의 내용을 정하는 입력으로 쓸 수 있다. 다만 어떤 근거로 그 서버의 설명을 신뢰하는지, 구현이 바뀌면 무엇을 다시 확인하는지가 있어야 한다. 설치 버튼을 눌렀다는 사실만으로 모든 설명의 정확성이 검증되지는 않는다.

실행을 제한하는 역할은 더 구체적인 계층에 놓인다. 예를 들어 문서 조회용 연결에는 지정된 저장소를 읽을 수 있는 권한만 주고, 초안 생성용 연결에는 검토 폴더에 쓸 수 있는 범위만 준다. 외부 전송은 허용된 대상과 작업 조건을 서버에서 검사하게 한다. 모델이 다른 인자를 골라도 범위 밖의 요청이 거절되어야 한다. 이런 설계는 도구가 스스로 붙인 표시의 정확성에만 기대지 않는다.

MCP의 2026년 3월 공식 해설도 힌트를 정책 판단에 활용하는 일과 네트워크 통제·샌드박스 같은 실행 제한을 구분한다. 이 해설에 나오는 새 주석 제안과 보급 현황은 작성 당시의 논의다. 여기서는 현재 모든 클라이언트에 같은 기능이 구현됐다는 근거로 사용하지 않는다.

문서 한 장이 세 도구를 거칠 때

가상의 팀이 내부 제품 메모를 읽어 고객 안내문을 만드는 업무를 생각해 보자. 첫 도구는 승인된 내부 메모를 조회한다. 두 번째 도구는 검토용 초안을 저장한다. 세 번째 도구는 최종 문서를 외부에 전송한다. 아래는 특정 제품의 기능 설명이 아니라, 힌트를 업무 설계에 적용하는 예시다.

조회 도구에 readOnlyHint: true가 정확하게 붙어 있더라도 읽어 온 내용에는 아직 공개하지 않은 정보가 있을 수 있다. 원문을 바꾸지 않았다는 사실과 그 원문을 외부로 보내도 된다는 판단은 별개다. 조회 도구의 제한은 읽을 수 있는 문서 범위에서 시작하고, 전송 단계에서는 전달할 내용과 목적지를 다시 확인해야 한다.

초안 저장 도구는 새 파일을 만들므로 읽기 전용으로 설명하면 안 된다. 기존 문서를 덮어쓰지 않고 추가만 한다면 그 성격을 주석으로 표현할 수 있다. 쓸 수 있는 폴더와 파일 크기 같은 실제 범위는 별도 통제로 정한다. ‘미리보기’라는 화면 이름도 저장소 변경 여부를 대신 설명해 주지 않는다.

전송 도구는 같은 인자에 대해 중복 발송을 막도록 구현할 수 있다. 이때 멱등성 힌트는 재호출 판단에 도움이 된다. 하지만 최초 발송의 대상이 맞는지, 첨부 문서가 공개 가능한지까지 확인해 주지는 않는다. 반환된 성공 메시지와 실제 전송 상태를 대조하는 절차도 여전히 필요하다.

세 도구를 한 세션에 연결하면 검토할 단위가 넓어진다. 내부 정보를 읽는 능력과 외부에 내보내는 능력이 함께 생기기 때문이다. 개별 도구의 힌트뿐 아니라, 어떤 자료가 어느 단계까지 이동하고 다음 도구의 입력으로 들어가는지 살펴야 한다. 승인 대상의 내용과 범위를 고정하는 방법은 에이전트 업무의 승인선 설계와 연결해 볼 수 있다.

허용되는 동작과 거절되는 동작을 함께 시험한다

도입 검수에서는 도구 목록에 좋은 설명이 붙었는지와 실제 제한이 작동하는지를 따로 기록할 수 있다. 먼저 시험용 자료와 계정을 두고, 조회·저장·전송의 허용 범위를 정한다. 그런 다음 정상 호출이 성공하는지와 함께 범위를 벗어난 요청이 실제 변경 전에 거절되는지 확인한다.

조회용 연결로 쓰기를 시도했을 때, 검토 폴더 밖에 초안을 저장하려 했을 때, 허용되지 않은 목적지로 전송하려 했을 때를 시험할 수 있다. 검증 대상은 경고 문장의 유무뿐 아니라 저장소와 외부 대상에 남은 실제 상태다. 허용되지 않은 요청이 먼저 실행된 뒤 오류를 반환한다면 기대한 제한이 작동한 것이 아니다.

주석을 바꿨을 때 실행 범위가 어떻게 달라지는지도 확인할 만하다. 도구가 스스로 읽기 전용이라고 선언했다는 이유만으로 더 넓은 계정 권한을 얻거나 필수 검사를 통과해서는 안 된다. 검증한 구현과 주석이 어긋나면 운영자는 그 도구의 자동 실행 범위를 줄이고 원인을 확인할 수 있다. 이 시험과 대응은 이 글의 운영 제안이며, MCP가 자동으로 제공하는 보안 시험 기능은 아니다.

명세는 서버에 도구 입력 검증과 적절한 접근 통제 등을 요구한다. 클라이언트에는 민감한 작업의 사용자 확인, 호출 전 입력 표시, 결과 검증 등을 권고한다. 도구를 모델이 찾아 호출할 수 있도록 설계했다는 사실이 모든 호출을 무조건 자동 승인해야 한다는 의미는 아니다. 구체적인 사용자 경험과 정책은 구현마다 확인해야 한다.

도구 설명은 운영자가 같은 단어로 동작을 이해하게 해 준다. 그 설명을 신뢰할 근거, 실행을 제한하는 권한, 결과를 확인하는 시험이 연결될 때 업무에 적용할 범위도 분명해진다. 자동화의 수준을 높이는 출발점은 힌트를 더 많이 붙이는 것보다, 각 힌트가 어떤 검증과 통제로 이어지는지 설명할 수 있게 만드는 데 있다.