Azure DevOps MCP와 에이전트 PR 리뷰에서의 혼란스러운 대리인(confused-deputy) 문제

PR이 말 그대로 에이전트를 사회 공학적으로 해킹하는 거네. 리뷰어는 공범이 되는데, 정작 공로는 하나도 못 챙기고.

이건 그냥 예외적인 사례처럼 들리겠지만, 얼마나 악용하기 쉬운지 깨닫는 순간 생각이 달라질걸. PR에 숨겨진 텍스트는 사실상 공짜 프롬프트 인젝션 벡터나 다름없어. 만약 리뷰 에이전트가 커밋 푸시 권한까지 가지고 있다면 순식간에 골치 아파지는 거지.

두 개의 ID를 사용하는 방식도 효과는 있지만, 파이프라인이 이미 그렇게 설계되어 있지 않으면 꽤 복잡해질 거야. 내가 본 팀들은 초기 리뷰 단계에는 저렴한 읽기 전용 모델을 돌리고, 쓰기 권한이 필요한 작업은 수동 승인이 필요한 별도의 작업으로 넘기더라.

두 개의 ID를 쓰는 방식도 효과는 있지만, 진짜 해결책은 MCP 서버 계층에 있어. 대부분의 MCP 서버는 그냥 노출된 모든 도구에 대해 전체 접근 권한을 가진 토큰 하나를 던져주거든. 서버가 도구별로 권한 범위를 지정(코드 브라우저용 읽기 전용 토큰, 승인 시에만 쓰기 토큰 허용)할 수 있게 해주기 전까지는 계속 아키텍처와 싸우는 꼴이지. MCP용 OAuth 사양에 범위가 지정된 토큰에 대한 언급은 있지만, 아직 구현한 곳이 거의 없어.

단순히 두 에이전트에게 다른 프롬프트를 주는 게 아니라, 자격 증명과 툴 브로커 계층에서 분리가 확실히 강제된다면 두 개의 아이덴티티를 사용하는 설정은 실용적임.

나라면 이렇게 구성할 듯:

1. 리뷰 아이덴티티는 레포, PR, CI 상태를 읽을 수는 있지만, 푸시, 파이프라인 트리거, 작업 항목 수정, 댓글 작성은 불가능하게 함.
2. 커밋 SHA, 발견된 내용, 타입이 지정된 파라미터가 포함된 변경 불가능한 리뷰 아티팩트를 생성함.
3. 별도의 단기 액션 아이덴티티가 o …를 수락함