MCP 액세스 거버넌스: 누가 어떤 도구와 데이터를 사용할 수 있는가

MCP 액세스 거버넌스의 의미

Model Context Protocol(MCP)을 사용하면 Claude Code, Cursor, Codex 같은 AI 클라이언트가 티켓 대기열 검색, 문서 읽기, 고객 레코드 업데이트 같은 도구를 제공하는 서버를 통해 회사 시스템에 연결할 수 있습니다. 각 도구 요청은 누군가를 대신해 시스템에 접근합니다.

액세스 거버넌스는 ID 관리 팀이 이미 모든 애플리케이션에 대해 묻고 있는 질문을 이러한 요청에 적용합니다. 누가 이 연결을 사용할 수 있습니까? 각 사람에게 어떤 도구와 데이터가 필요합니까? 누가 그 접근 권한에 동의했으며, 역할이 바뀌면 그 권한은 얼마나 빨리 종료됩니까?

한 가지 중요한 차이가 있습니다. 에이전트는 방금 읽은 콘텐츠를 바탕으로 어떤 도구를 호출하고 무엇을 보낼지 정하는 경우가 많습니다. 어떤 사람에게 도구를 사용할 권한이 있다고 해서, 에이전트가 그 도구로 보낼 수 있는 모든 요청을 그 사람이 의도한 것은 아닙니다. 그래서 좁은 권한과 각 요청에 대한 명확한 기록이 평소보다 더 중요합니다.

접근 권한은 여러 계층에서 결정됩니다

도구 요청 하나도 여러 단계의 접근 권한 결정을 거칩니다. 이를 정리해 보면 어느 시스템이 각 결정을 적용하는지, 어디에 빈틈이 남아 있는지 알 수 있습니다.

업스트림 시스템 자체의 권한이 최종 한도입니다. 게이트웨이 규칙은 게이트웨이를 통해 할 수 있는 일을 좁힐 수는 있지만, 자격 증명에 없는 권한을 부여할 수는 없습니다.

모든 요청을 사람 단위로 식별하세요

공유 API 키는 액세스 거버넌스가 무너지기 쉬운 대표적인 지점입니다. 모든 사람의 에이전트가 하나의 토큰을 사용하면 업스트림 시스템에는 사용자가 한 명으로 보이고, 토큰을 폐기하면 모든 사람이 영향을 받으며, 누가 무엇을 요청했는지 기록으로 확인할 수 없습니다.

업스트림 시스템에는 보통 OAuth를 통해 각 개인이 직접 권한을 부여하는 방식을 우선하고, 게이트웨이를 쓴다면 평소 사용하는 ID 공급자로 로그인하게 하세요. MCP 접근 권한 부여 사양은 OAuth 2.1을 기반으로 합니다. 이 사양은 서버가 자신을 위해 발급된 토큰만 수락하도록 요구하며, 클라이언트의 토큰을 다른 서비스로 그대로 전달하는 것을 금지합니다.

사람이 개입하지 않는 예약 작업처럼 서비스 ID가 적합한 업무도 있습니다. 이러한 ID에는 책임 담당자, 작동에 필요한 가장 좁은 권한, 별도의 기록을 부여해, 그 활동이 사람의 활동으로 오인되지 않도록 하세요.

팀 단위로 접근 권한을 부여하세요

연결을 한 사람씩 할당하면 검토하기 어렵고 잊어버리기 쉽습니다. 대신 팀에 할당하세요. 가능하면 ID 공급자에서 가져온 그룹을 사용하면, 디렉터리가 변경될 때 새로 합류한 사람은 적절한 접근 권한을 받고 떠난 사람은 권한을 잃습니다.

좁게 시작하세요. 민감한 연결은 조직 전체가 아니라 필요한 팀에만 제공한 다음, 특정 도구나 리소스에 조건을 추가하세요. 예를 들어 재무팀이라면 모든 팀원이 한 폴더의 청구서를 읽을 수 있게 하고, 그보다 작은 그룹만 결제 정보를 수정할 수 있게 할 수 있습니다.

간접적으로 주어지는 접근 권한에 주의하세요. 두 팀에 속한 사람은 어느 팀을 통해서든 연결에 접근할 수 있으므로, 한 팀에서 제외한다고 해서 반드시 접근 권한이 사라지는 것은 아닙니다.

에이전트의 접근 권한은 업무에 필요한 만큼만 부여하세요

OWASP는 대규모 언어 모델 기반 애플리케이션의 주요 위험 중 하나로 과도한 에이전시(Excessive Agency)를 꼽습니다. 작업에 필요한 것보다 많은 기능, 권한, 자율성을 가진 에이전트는 잘못 유도되거나 단순히 판단을 그르쳤을 때 피해를 일으킬 수 있습니다. 에이전트가 읽는 텍스트가 에이전트의 행동을 다른 방향으로 돌리려 하는 프롬프트 인젝션이 그런 경우 중 하나입니다.

MCP의 최소 권한은 세 가지 수준에서 적용됩니다. 워크플로에 필요한 도구만 활성화하세요. 그 도구가 업무와 관련된 리소스에만 접근하도록 제한하세요. 연결의 토큰은 일반적으로 해당 연결의 모든 도구가 사용할 수 있으므로, 활성화된 도구에 필요한 OAuth 범위만 요청하세요. MCP 보안 가이드는 최소한의 범위로 시작하고 필요할 때만 범위를 추가로 요청하라고 권장합니다.

변경 작업뿐 아니라 읽기에도 주의가 필요합니다. 고객 레코드를 읽기만 할 수 있는 도구도 그 레코드를 노출할 수 있습니다. 실용적인 방법은 파일럿 그룹에 읽기 전용 접근 권한을 주고, 경계가 제대로 유지되는지 확인한 뒤, 팀이 에이전트의 동작 방식을 이해하면 변경 작업을 허용하는 것입니다.

접근 권한을 검토하고 권한 회수를 테스트하세요

접근 권한은 시간이 지나면서 조금씩 어긋납니다. 프로젝트가 끝나고, 사람들이 팀을 옮기고, 임시 예외가 영구화됩니다. 이미 진행하고 있는 접근 권한 검토에 MCP 연결을 포함하고, 각 연결의 담당자가 누가 접근 권한을 유지해야 하는지 확인하게 하세요. 유용한 검토는 다음 사항을 다룹니다.

그런 다음 권한 회수를 직접 테스트하세요. 테스트용 구성원을 제거하고, 이미 로그인된 클라이언트에서 요청을 다시 보내 보세요. 요청은 거부되어야 하며, 이전 승인으로 접근 권한이 되살아나서도 안 됩니다.

• 현재 각 연결을 사용할 수 있는 사람과, 그 권한이 어떤 팀 또는 예외를 통해 주어졌는지.
• 활성화된 도구와 리소스, 그리고 각각이 여전히 필요한지 여부.
• 연결이 누구의 자격 증명을 사용하며, 그 자격 증명이 어떤 범위를 부여하는지.
• 활성 상태로 남아 있는 클라이언트 세션, 특히 조직을 떠난 사람의 세션.
• 검토 기간 동안 실제로 사용된 것과 허용된 것의 비교.

요청과 승인을 분리하세요

대금 지급, 레코드 삭제, 고객 대상 이메일 발송처럼 결과가 중대한 작업에는 접근 권한만으로는 충분하지 않을 수 있습니다. 작업이 실행되기 전에 다른 사람이 제안된 작업을 검토하게 할 수 있습니다. 이때 검토자는 요청자가 아니어야 하며, 결정은 포괄적인 권한을 부여하는 대신 해당 작업에만 적용되어야 합니다.

검토는 위험에 비례하는 수준으로 유지하세요. 사소한 작업까지 모두 검토하게 하면 피로가 쌓이고 중요한 요청을 알아보기 어려워집니다. 실수가 얼마나 큰 피해를 낼 수 있는지를 기준으로 검토가 필요한 작업을 고르세요.

접근 권한과 사용에 대한 증거를 보관하세요

두 종류의 증거는 서로 다른 질문에 답합니다. 현재 접근 권한은 지금 누가 왜 연결을 사용할 수 있는지 보여 주고, 요청 기록은 누가 실제로 연결을 사용했고, 어떤 결정이 내려졌으며, 그 후 무슨 일이 있었는지 보여 줍니다. 접근 권한 검토에는 두 가지가 모두 필요합니다.

기록도 필요한 만큼만 남기세요. 결정 기록에 프롬프트나 응답 전문이 필요한 경우는 드물며, 이를 저장하면 그 자체로 개인정보 보호 의무가 생깁니다. 또한 기록은 관찰하는 경로만 다루므로, 게이트웨이를 우회하는 요청에는 별도의 통제가 필요합니다.

Durin가 맞는 곳

Durin은 자체 게이트웨이를 통해 라우팅되는 MCP 요청에 액세스 거버넌스를 적용합니다. 각 요청은 팀 규칙이 적용되기 전에 현재 신원, 멤버십, 팀, 연결, 자격 증명, 검토된 도구, 리소스에 대한 확인과 콘텐츠 검사를 모두 통과해야 합니다. 연결은 팀 단위로 사용 범위를 지정할 수 있고, 팀 규칙으로 특정 도구, 리소스, 사람에 대한 조건을 추가할 수 있습니다.

사용자는 자신의 Durin 엔드포인트에 로그인하고, 업스트림 요청에는 해당 연결에 설정된 공급자 자격 증명이 사용됩니다. Durin은 자체 토큰을 공급자에게 전달하지 않습니다. 멤버십이나 클라이언트 세션을 취소하면 이후 요청에 적용되며, 이전 승인으로 접근 권한을 되살릴 수 없습니다. Enterprise 조직은 ID 공급자에서 사용자와 그룹을 동기화할 수 있으며, 로컬 사용자, 그룹, 초대 기능은 모든 패키지에서 사용할 수 있습니다.

이러한 확인을 통과한 검토된 요청은 기본적으로 진행될 수 있습니다. 관리자는 기본적으로 도구 접근을 거부하도록 설정하거나, 제안된 변경 작업을 다른 관리자가 검토하도록 요구할 수 있습니다. 액세스 그래프에서는 현재 누가 어떤 이유로 연결을 사용할 수 있는지 확인할 수 있고, 감사에서는 요청이 실행될 때 기록된 결정을 확인할 수 있습니다. Durin을 거치지 않는 요청에는 별도의 통제가 필요합니다.