에이전트 AI의 물결이 빠르게 가속화되고 있습니다. 단순한 도구를 탑재한 챗봇으로 시작한 에이전트는 이제 기업 워크플로에 깊숙이 통합된 자율적인 디지털 워커로 진화하고 있습니다.
이러한 배포가 성숙해짐에 따라 중요한 보안 공백이 점점 더 분명해지고 있습니다.
현재 많은 에이전트 아키텍처는 여전히 갓 키 모델이라고 할 수 있는, 광범위하고 수명이 긴 자격 증명을 통해 사용자 ID, 권한 부여 및 도구 액세스를 하나의 공유된 비밀로 통합하는 방식에 의존하고 있습니다.
이 접근 방식은 안전하게 확장할 수 없습니다.
대규모로 에이전트를 운영하려는 기업의 경우, 위임된 ID 및 AI 인식 시행 메커니즘으로 전환할 필요가 있습니다.
아래에서 실제 문제와 프로덕션급 솔루션에 대해 자세히 살펴보세요.
1. 실제 위험: 과도한 권한이 부여된 상담원 자격 증명
LangChain 스타일 도구, 사용자 지정 MCP 서버, 내부 도구 게이트웨이와 같은 많은 초기 에이전트 배포에서 인증은 종종 정적 서비스 자격 증명을 사용하여 관리됩니다:
- 수명이 긴 API 키
- 공유 서비스 계정
- 광범위한 OAuth 클라이언트 자격 증명
- 또는 거친 워크로드 아이덴티티
명확히 말씀드리자면, MCP 자체에는 정적 키가 필요하지 않습니다. 이 프로토콜은 적절한 OAuth 및 위임된 신원 모델을 지원합니다. 하지만 실제 구현에서는 여전히 많은 에이전트가 개별 MCP 서버와 통신할 때 범위가 지나치게 넓고 사용자에 구속되지 않는 자격 증명을 사용합니다.
이것이 바로 위험의 근원입니다.
공유 신원 문제(교차 사용자 어트리뷰션)
다음과 같은 시나리오를 생각해 보세요:
- 50명의 직원이 단일 마케팅 에이전트 사용
- 에이전트는 하나의 서비스 자격 증명을 사용하여 깃허브를 호출합니다.
이 설정에서는 GitHub 로그에 간단히 표시됩니다: 에이전트_서비스_계정이 리포지토리 X를 삭제했습니다.
누락된 내용:
- 어떤 사람이 작업을 시작했는지
- 사용자에게 권한이 부여되었는지 여부
- 예상된 행동인지 여부
감사 및 포렌식 관점에서 볼 때 어트리뷰션이 손실됩니다. 이는 MCP의 결함이 아니라 많은 에이전트 배포에 존재하는 ID 전파 격차 때문입니다.
광범위한 권한 문제(교차 도구 범위)
여러 도구를 노출하는 MCP 서버를 생각해 보세요:
- 읽기_파일
- 목록_파일
- 삭제_파일
에이전트가 광범위한 범위의 단일 자격 증명으로 인증하는 경우, 프롬프트 인젝션이나 에이전트의 잘못된 행동이 성공하면 잠재적으로 더 위험한 도구를 호출할 수 있습니다. MCP를 통해 서버가 도구별 인증을 시행할 수 있지만, 오늘날 많은 MCP 서비스는 주로 도구 기능에 중점을 두고 있으며 전체 기업 정책 시행 지점 역할을 하도록 설계되지 않았습니다.
이로 인해 상당한 아키텍처 격차가 발생합니다.
2. 아키텍처 현실: MCP 서버는 ZTNA 게이트웨이가 아닙니다.
대부분의 기업에서 내부 애플리케이션은 포괄적인 인증, 권한 부여 및 위험 정책 로직을 직접 구현하지 않습니다. 대신, 이러한 책임은 일반적으로 기업 애플리케이션 앞에 있는 제로 트러스트 네트워크 액세스(ZTNA) 계층에서 중앙 집중화됩니다.
MCP 서비스도 같은 방식으로 보아야 합니다.
실제로는 많은 MCP 서버가 있습니다:
- 도구 실행에 집중
- 업스트림 ID 신뢰
- 거친 또는 서비스 수준 인증 구현
- 심층적인 사용자/그룹 정책 모델 부족
- 토큰 교환을 수행하지 마십시오.
- 즉각적인 위험 결정을 처리하도록 설계되지 않았습니다.
모든 MCP 서버가 완전한 제로 트러스트 적용 엔진으로 작동하기를 기대하는 것은 현실적이지 않으며 확장성도 떨어집니다.
3. ZTNA가 자연스러운 제어 지점인 이유
ZTNA는 이미 기업 보안 분야에서 확고한 역할을 하고 있습니다:
- 내부 애플리케이션 전면 배치
- 인증 중앙 집중화
- 액세스 정책 적용
- 단일 제어 평면 제공
- 애플리케이션 팀의 부담 감소
이 모델을 MCP 서비스에 적용하면 조직은 기존 애플리케이션과 AI 기반 도구 액세스를 모두 보호하는 통합된 접근 방식을 사용할 수 있습니다.
기존 앱과 AI 기반 도구 액세스를 모두 보호하는 일관된 방법 중 하나입니다.
그러나 AI는 ZTNA 솔루션에 새로운 요구 사항을 도입합니다.
4. 기존 ZTNA는 AI 행동에 맹목적입니다.
기존 ZTNA 솔루션은 다음과 같은 요소를 기반으로 결정을 내립니다:
- 사용자 신원
- 장치 자세
- 네트워크 컨텍스트
- 애플리케이션 ID
에이전트 AI 트래픽은 다음과 같은 새로운 위험 차원을 추가합니다:
- 어떤 MCP 도구가 호출되고 있는지
- 어떤 인수가 전달되고 있는지
- 요청이 프롬프트 생성되었는지 여부
- 행동이 고위험을 나타내는지 여부
- 사용자가 해당 특정 도구에 대한 권한이 있는지 여부
기존 ZTNA 솔루션은 이 계층에서 제어를 확인하거나 시행할 수 없습니다. MCP 서비스를 안전하게 앞당기려면 ZTNA가 MCP 프로토콜을 인식하고 AI를 인식해야 합니다.
필요한 것은 ZTNA를 대체하는 것이 아니라 이를 발전시키는 것입니다.
MCP 인식 ZTNA: 필요한 진화
기존의 ZTNA는 MCP 서비스를 포함한 엔터프라이즈 애플리케이션을 위한 올바른 아키텍처의 프런트 도어입니다. 애플리케이션 외부에서 액세스 제어를 중앙 집중화하는 것은 확장성, 감사 가능성, 운영 효율성이 입증되었습니다.
그러나 상담원 중심 워크플로에는 기존 ZTNA가 처리하도록 설계되지 않은 두 가지 새로운 요구 사항이 도입되었습니다:
도구 실행을 위한 사용자 수준 위임 ID
MCP 도구 활동에 대한 프로토콜 수준의 가시성 확보
이러한 요구 사항을 충족한다고 해서 ZTNA가 대체되는 것이 아니라 발전하는 것입니다.
MCP 인식 ZTNA 계층은 ID 위임과 프로토콜 인식 권한 부여라는 두 가지 중요한 측면에서 기존 제로 트러스트 모델을 확장합니다.
위임된 신원: 토큰 교환이 필요한 이유
AI 에이전트가 MCP 도구를 호출할 때 다운스트림 서비스는 근본적인 질문에 답할 수 있어야 합니다:
이 작업은 어떤 사람을 대신하여 수행되고 있나요?
광범위하고 수명이 긴 사용자 토큰을 모든 MCP 서비스에 직접 전달하는 것은 안전하지도 않고 확장성이 떨어집니다. 토큰이 오용될 경우 과도한 신뢰 전파가 발생하고 폭발 반경이 커집니다.
대신 최신 제로 트러스트 아키텍처는 위임된 ID를 사용합니다.
이 모델에서는
- 사용자가 엔터프라이즈 IdP로 인증합니다.
- 에이전트가 사용자의 신원을 전파합니다.
- ZTNA 적용 계층이 사용자의 유효성을 검사합니다.
- 집행 계층이 토큰 교환을 수행합니다.
- 특정 MCP 서비스에 대해 수명이 짧고 범위가 좁은 자격 증명이 발급됩니다.
이 접근 방식은 다운스트림 서비스가 요청된 작업에 필요한 최소한의 권한만 받도록 보장합니다.
위임형 토큰 교환을 통해 기업은 다음을 수행할 수도 있습니다:
- 일관된 수명 관리 시행
- 잠재 고객 표준화
- 토큰 폭발 반경 감소
- 완전한 사용자 어트리뷰션 유지
하지만 정체성만으로는 충분하지 않습니다.
MCP 프로토콜 인식이 중요한 이유
완벽한 신원 확인이 가능하더라도 기존 ZTNA는 에이전트가 실제로 무엇을 하고 있는지에 대한 가시성이 여전히 부족합니다.
네트워크 관점에서 MCP 트래픽은 종종 표준 HTTPS로 나타납니다. 프로토콜 인식이 없으면 시행 계층은 이를 확인할 수 없습니다:
- 어떤 MCP 도구가 호출되고 있는지
- 어떤 인수가 전달되고 있는지
- 행동이 고위험인지 여부
- 사용자가 해당 특정 도구에 대한 권한이 있는지 여부
이것이 바로 핵심 사각지대입니다.
MCP 인식 ZTNA 계층에는 추출할 수 있는 심층 프로토콜 파싱이 포함되어 있습니다:
- 도구 이름
- 도구 인수
- 세션 컨텍스트
- 사용자 클레임
이러한 신호는 단순한 애플리케이션 액세스 결정을 훨씬 뛰어넘는 세분화된 AI 인식 권한 부여 정책을 가능하게 합니다.
ID 위임과 MCP 수준의 검사가 모두 이루어진 후에야 에이전트 워크플로에 대한 진정한 최소 권한 시행을 달성할 수 있습니다.
중요 구현 세부 사항: 에이전트는 사용자 신원을 전파해야 합니다.
위임된 ID가 엔드투엔드로 작동하려면 에이전트 런타임이 사용자 ID 정보를 능동적으로 전파해야 합니다. 현재 많은 배포에서 사용자는 프런트엔드에서 인증되지만(예: ZTNA 및 OIDC 사용), 다운스트림 툴 호출은 여전히 정적 서비스 자격 증명으로 이루어집니다. 이 경우 사용자 어트리뷰션이 손실되고 최소 권한 제어가 무너지게 됩니다.
AI 인식 제로 트러스트를 사용 설정하려면 에이전트 또는 에이전트 프레임워크에서 아웃바운드 MCP 또는 툴 요청이 AI>보안으로 확인 가능한 사용자 바인딩된 자격 증명을 전달하도록 해야 합니다. 이 기능은 대부분의 에이전트 프레임워크에서 자동으로 제공되지 않으며 일반적으로 명시적인 구성이 필요하고 경우에 따라 약간의 코드 변경이 필요합니다.
권장 제작 패턴: 이중 ID 헤더
프로덕션 AI > 보안 배포에서 요청에는 일반적으로 독립적으로 확인할 수 있는 두 개의 ID가 포함됩니다:
상담원 신원:
권한 부여: 권한: 무기명
사용자 신원:
X-AI-사용자 어설션:
업스트림 위임:
권한 부여: 권한: 무기명
두 토큰 모두 정책 평가가 이루어지기 전에 AI>Secure에서 독립적으로 검증합니다.
에이전트에서 변경되는 사항(최소)
대부분의 상담원 프레임워크는 이 패턴을 지원하기 위해 약간의 변경만 필요합니다:
- MCP 엔드포인트를 AI>보안으로 지정합니다.
- 기존 에이전트 JWT를 계속 전송합니다.
- 사용자 JWT를 전달하는 아웃바운드 헤더를 추가합니다.
OpenClaw와 같은 최신 프레임워크는 일반적으로 사용자 지정 아웃바운드 헤더를 지원하므로 이러한 전환이 간단합니다. MCP 프로토콜을 변경할 필요가 없습니다.
AI>보안이 최소 권한을 적용하는 방법
요청이 AI>보안 단계에 도달하면 다음 단계가 진행됩니다:
- 상담원 신원 확인
- 사용자 신원 확인
- MCP 트래픽이 구문 분석됩니다.
- 세분화된 정책 평가
- AI>보안이 토큰 교환을 수행합니다.
- 수명이 짧은 위임 토큰이 업스트림으로 전송됩니다.
요청을 전달하기 전에 AI>보안은 원본 자격 증명을 제거하고 삽입합니다:
권한 부여: 권한: 무기명
이렇게 하면 MCP 서버가 적절한 범위의 ID만 수신할 수 있습니다.
AI>보안이 구성해야 하는 항목
MCP 서버당 업스트림 인증
각 MCP 서버에 대해 AI>보안은 적절한 업스트림 인증 방법으로 구성되며, 여기에는 다음이 포함될 수 있습니다:
- OAuth 무기명
- API 키
- mTLS
- 기타 지원되는 방법
세분화된 권한 부여 정책
AI>보안 정책을 시행할 수 있습니다:
- 도구 허용/거부 규칙
- 인수 검사
- 사용자/그룹 컨트롤
- 위험 기반 조건
ID 브로커 구성
AI>보안 ID 브로커는 다음 작업을 처리합니다:
- 들어오는 사용자 토큰 유효성 검사
- 발급자 및 대상 확인
- OAuth 토큰 교환 수행
- 단기 위임 토큰 발행
- 토큰을 대상 MCP 서비스로 범위 지정하기
- 수명 제한 적용
- 선택적으로 클레임 변환
이러한 메커니즘을 통해 MCP 서버는 최소 권한 자격 증명만 수신하며 복잡한 신원 로직을 직접 구현할 필요가 없습니다.
결론
문제는 MCP 프로토콜의 결함이 아닙니다. 핵심 문제는 많은 초기(또는 지금도) 에이전트 배포가 권한이 과도하고 적절한 어트리뷰션이 없는 자격 증명에 의존한다는 것입니다. 이러한 자격 증명은 과도한 권한을 부여하고 어떤 사용자나 상담원이 특정 작업을 수행했는지 명확하게 식별하지 못합니다. 그 결과 MCP 서비스는 처리하도록 설계되지 않은 보안 제어 및 액세스 정책을 시행하도록 요청받고 있으며, 이로 인해 구현에 과도한 부담이 가중되고 있습니다.
기업은 MCP 서비스 앞에 AI 인식 ZTNA 계층을 배치함으로써 다음과 같은 이점을 누릴 수 있습니다:
- 액세스 제어 중앙 집중화
- 사용자 어트리뷰션 보존
- 도구별 최소 권한 적용
- MCP 서비스 구현에 과도한 부담 방지
AI 시대에 맞게 제로 트러스트 아키텍처를 조정하는 조직은 디지털 직원을 안전하게 확장할 수 있는 가장 유리한 위치에 서게 됩니다. 자율 에이전트 시대에 제로 트러스트는 누가 연결할 수 있는지를 넘어 AI가 실제로 무엇을 할 수 있도록 허용하는지에까지 확장되어야 합니다.