원문은 tamiz.pro에 게시되었습니다.

소프트웨어 개발 생명주기(Software Development Lifecycle)에 대규모 언어 모델 (LLMs)이 통합되면서, 수동적인 코드 완성 단계에서 저장소를 읽고, 테스트를 실행하며, 인프라를 배포할 수 있는 능동적이고 자율적인 에이전트(Agents)로 진화했습니다. 이러한 변화는 기존의 사이버 보안 모델이 다루기 어려운 중대한 아키텍처적 취약점인 '사용자로서의 에이전트(agent-as-a-user)' 문제를 야기합니다.

수십 년 동안 인증 및 인가 (AuthZ/AuthN)는 인간 운영자나 정적 범위(static scopes)를 가진 장기 서비스 계정을 위해 설계되어 왔습니다. 그러나 자율 에이전트는 동적이며, 문맥 의존적(context-dependent)이고, 종종 엄격한 토큰 예산과 시간 제약 하에서 작동합니다. 이러한 에이전트가 Model Context Protocol (MCP)과 같은 프로토콜을 통해 외부 시스템과 상호 작용할 때, 자격 증명 유출, 권한 상승(privilege escalation), 그리고 공급망 공격(supply chain attacks)의 공격 표면은 기하급수적으로 확장됩니다.

이 글에서는 에이전트 중심 워크플로에서 현재 자격 증명 관리의 실패 모드를 해부하고, MCP의 구체적인 보안 함의를 분석하며, 안전한 에이전트 인증을 위한 새로운 아키텍처 패턴을 제안합니다.

사용자로서의 에이전트 역설 (The Agent-as-a-User Paradox)

자율 개발 도구의 핵심적인 갈등은 인간 중심의 보안 모델과 에이전트 중심의 운영 요구 사항 사이의 불일치에 있습니다. 전통적인 역할 기반 액세스 제어 (RBAC)는 사용자 ID와 권한 세트 간의 정적 매핑을 가정합니다. 예를 들어, "개발자" 역할은 Git 저장소에 대한 읽기/쓰기 권한과 스테이징 데이터베이스에 대한 읽기 권한을 가질 수 있습니다.

하지만 자율 에이전트는 개발자 "자체"가 아닙니다. 에이전트는 개발자를 "대신하여" 행동하며, 종종 원래의 의도를 초과하는 작업을 수행합니다. "결제 서비스의 버그 수정"이라는 임무를 맡은 에이전트를 생각해 보십시오. 이를 효과적으로 수행하기 위해 에이전트는 다음과 같은 작업이 필요할 수 있습니다:

1. 운영 데이터베이스 (production database) 로그 읽기 (오류 재현을 위해).
2. 스테이징 환경 (staging environment)에 코드 작성.
3. 배포 파이프라인 (deployment pipeline) 트리거.

전통적인 RBAC (역할 기반 액세스 제어) 모델에서는 에이전트에게 필요한 권한을 부여하기 위해 광범위한 권한을 가진 서비스 계정 (service account)을 할당해야 합니다. 이는 "갓 모드 (God Mode)" 문제를 야기합니다. 만약 에이전트가 해킹당하거나 악의적인 행동을 환각 (hallucinate)한다면 (예: 쿼리를 수정하는 대신 테이블을 삭제하는 경우), 그 피해 범위 (blast radius)는 막대합니다. 반대로, 에이전트의 권한을 좁게 제한하면 에이전트가 무용지물이 되는 경우가 많아, 개발자가 수동으로 개입해야 하며 자동화 루프 (automation loop)가 깨지게 됩니다.

게다가 에이전트는 일시적 (ephemeral)입니다. 에이전트는 작업별로 생성되어 몇 분 또는 몇 시간 동안 실행된 후 종료됩니다. 이러한 일시적인 엔티티 (entities)를 위해 정적 자격 증명 (static credentials)을 관리하는 것은 비효율적이며 오류가 발생하기 쉽습니다. 에이전트의 프롬프트 (prompts)나 설정 파일에 API 키를 하드코딩하는 것은 심각한 취약점입니다. 프롬프트는 종종 로그에 기록되거나 공유, 또는 캐싱 (cached)되기 때문입니다.

모델 컨텍스트 프로토콜 (Model Context Protocol, MCP) 공격 표면

모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 LLM (대규모 언어 모델)을 외부 데이터 소스 및 도구와 연결하기 위한 표준으로 부상했습니다. MCP를 통해 에이전트는 표준화된 JSON-RPC 인터페이스를 통해 컨텍스트를 제공하는 "서버" (예: 데이터베이스, 파일 시스템, API)를 발견하고 사용할 수 있습니다. MCP는 통합을 단순화하지만, 전통적인 API 상호작용에는 존재하지 않는 새로운 보안 위험을 도입합니다.

1. 도구 정의를 통한 컨텍스트 포이즈닝 (Context Poisoning)

MCP는 도구 정의 (tool definitions)에 의존합니다. 도구 정의란 도구가 무엇을 하는지, 그리고 어떤 매개변수 (parameters)를 수락하는지를 설명하는 JSON 스키마 (JSON schemas)입니다. 에이전트는 어떤 도구를 호출할지 결정하기 위해 이러한 정의를 사용합니다. 만약 MCP 서버가 침해당하거나 악의적이라면, 잘못된 도구 정의를 제공할 수 있습니다.

예를 들어, MCP 서버가 안전해 보이는 read_file 도구를 정의하면서, 실제로는 기본 설명에는 생략되어 있지만 백엔드에서는 여전히 허용되는 send_to_external_server라는 숨겨진 파라미터를 포함할 수 있습니다. 스키마(Schema)를 신뢰하는 에이전트는 의도치 않게 민감한 데이터를 신뢰할 수 없는 엔드포인트(Endpoint)로 전달할 수 있습니다. 이는 에이전트가 이해하는 도구의 동작과 실제 실행이 일치하지 않는 일종의 "컨텍스트 포이즈닝 (Context Poisoning)" 형태입니다.

2. 도구 출력에서의 자격 증명 유출 (Credential Leakage)

MCP 서버는 종종 하위 시스템으로부터 가공되지 않은 데이터(Raw data)를 반환합니다. 만약 데이터베이스 MCP 서버가 실수로 노출된 자격 증명(Credentials), 개인정보(PII), 또는 내부 네트워크 토폴로지(Topology)가 포함된 결과 집합을 반환한다면, 이 정보는 에이전트의 컨텍스트 윈도우(Context window)의 일부가 됩니다. 일단 컨텍스트 윈도우에 포함되면, 이 데이터는 다음과 같이 활용될 수 있습니다:

• 에이전트의 다음 도구 호출에 실수로 포함됨 (예: 비밀 키를 커밋 메시지에 복사하여 붙여넣기).
• 에이전트의 LLM 제공업체가 프롬프트와 응답을 기록(Log)하는 경우 외부로 유출됨.
• 악의적인 에이전트가 추가적인 무단 작업을 수행하는 데 사용됨.

전통적인 API 게이트웨이는 상태 코드(Status codes)나 단순한 정규 표현식(Regex)을 기반으로 응답을 필터링합니다. MCP는 표준화된 응답 필터링 계층이 부족하여, 데이터를 정화(Sanitize)해야 하는 책임이 클라이언트(에이전트)에게 전가되는데, 이는 종종 LLM의 역량을 벗어나는 일입니다.

3. 동적 권한 상승 (Dynamic Scope Escalation)

MCP 서버는 부수 효과(Side effects)를 가진 도구(예: deploy_code, delete_resource)를 노출할 수 있습니다. 여기서의 보안 위험은 동적 권한 상승(Dynamic scope escalation)입니다. 에이전트는 파일 시스템에 대한 읽기 전용(Read-only) 액세스로 시작할 수 있습니다. 그러나 여러 개의 읽기 전용 도구를 체이닝(Chaining)하여 경로 구조를 추론할 수 있다면, 이후 느슨하게 정의된 별도의 도구를 사용하여 해당 경로에 쓰기 작업을 수행할 수도 있습니다. MCP에서 도구는 종 thường 런타임(Runtime)에 동적으로 발견됩니다. 에이전트가 쓰기 권한을 부여하는 새로운 도구를 발견하면, 시스템 관리자가 예상하지 못한 의도치 않은 권한 상승(Privilege escalation)으로 이어질 수 있습니다.

전통적인 자격 증명 관리의 한계

에이전트를 보호하기 위한 현재의 접근 방식은 정적 토큰 (Static tokens), API 키 (API keys), 그리고 환경 변수 (Environment variables)에 크게 의존하고 있습니다. 이러한 방식은 자율 에이전트 (Autonomous agents)에게 있어 다음 세 가지 이유로 근본적인 결함이 있습니다.

1. 세밀한 감사 (Granular Auditing)의 부재

에이전트가 정적 API 키를 사용할 때, 모든 작업은 해당 키의 소유로 귀속됩니다. 선량한 에이전트가 수행한 정당한 작업과 탈취된 에이전트가 수행한 악의적인 작업을 구분하는 것은 불가능합니다. 작업 단위의 세밀한 감사 (Granular auditing)가 없다면, 사고 대응 (Incident response)은 사후 약방문식이며 눈먼 대응이 될 수밖에 없습니다.

2. 정적 권한 vs 동적 요구사항

앞서 논의한 바와 같이, 에이전트는 동적인 요구사항을 가집니다. 광범위한 권한을 가진 정적 토큰은 보안에 취약하며, 좁은 권한을 가진 토큰은 효율성이 떨어집니다. 에이전트의 현재 작업에 따라 "최근 한 시간 내에 수정된 파일에 대한 읽기 권한" 또는 "스테이징 환경 (Staging environments)에 대해서만 쓰기 권한"을 동적으로 부여할 수 있는 메커니즘이 존재하지 않습니다.

3. 자격 증명 순환 (Credential Rotations) 및 생명주기

에이전트는 수명이 짧습니다. 수천 개의 일시적인 (Ephemeral) 에이전트를 위해 자격 증명을 순환시키는 것은 운영 비용이 많이 듭니다. 대부분의 조직은 에이전트 자격 증명을 빈번하게 교체하지 않으며, 이로 인해 토큰이 유출될 경우 장기간 노출될 위험에 처하게 됩니다.

새로운 패러다임: 적시 (Just-in-Time, JIT) 자격 증명 및 코드로서의 정책 (Policy-as-Code)

자율 에이전트를 보호하기 위해서는 정적인 ID 기반 인증 (Identity-based authentication)에서 동적인 정책 기반 인가 (Policy-based authorization)로 전환해야 합니다. 여기에는 세 가지 핵심적인 아키텍처 변화가 포함됩니다.

1. 적시 (Just-in-Time, JIT) 자격 증명 발급

에이전트에게 수명이 긴 토큰을 제공하는 대신, 시스템은 에이전트의 생명주기 중 특정 작업과 기간에 맞춰 범위가 제한된 (Scoped) JIT 자격 증명을 발급해야 합니다. 이는 다음과 같은 방법을 통해 달성할 수 있습니다:

• 단기 토큰 (Short-Lived Tokens, JWTs): 몇 분 또는 몇 시간 내에 만료되는 토큰입니다.
• OAuth 2.0 토큰 교환 (OAuth 2.0 Token Exchange): 에이전트가 필요한 정확한 리소스와 작업을 지정하여 ID 제공자 (Identity Provider, IdP)로부터 토큰을 요청합니다.
• SPIFFE/SPIRE: 클라우드 네이티브 (Cloud-native) 환경에서 보안 서비스 ID를 위해, 에이전트는 비밀 정보 (Secrets)를 하드코딩하지 않고도 SPIFFE ID를 사용하여 다른 서비스와 인증할 수 있습니다.

예시: 스테이징 환경에 수정 사항을 배포하는 임무를 맡은 에이전트가 ID 제공자 (IdP)에게 JWT를 요청합니다. IdP는 staging:deploy로 범위가 제한되고 만료 시간이 15분인 토큰을 발급합니다. 에이전트는 이 토큰을 사용하여 배포 API를 호출합니다. 작업이 완료되면 토큰은 자동으로 만료됩니다.

2. OPA (Open Policy Agent)를 활용한 코드형 정책 (Policy-as-Code)

권한 부여 (Authorization) 결정은 애플리케이션 코드에 내장되는 것이 아니라, 중앙 집중식 정책 엔진 (Policy Engine)에 의해 이루어져야 합니다. OPA는 이를 위한 대중적인 도구입니다. 정책은 Rego 언어로 정의되며 런타임 (Runtime)에 평가됩니다.

MCP 서버의 경우, 사이드카 프록시 (Sidecar Proxy)가 모든 MCP 도구 호출을 가로챌 수 있습니다. 도구가 실행되기 전에 사이드카는 에이전트의 토큰을 OPA 정책과 대조하여 확인합니다. 정책은 다음과 같은 규칙을 강제할 수 있습니다:

• "deployer 역할을 가진 에이전트만 deploy_code를 호출할 수 있다."
• "project-alpha에서 작업 중인 에이전트만 database-alpha에 접근할 수 있다."
• "어떤 에이전트도 유지보수 시간 외에는 delete_resource를 호출할 수 없다."

이를 통해 에이전트가 유효한 토큰을 가지고 있더라도 권한이 없는 작업을 수행할 수 없도록 보장합니다.

3. MCP 전용 보안 제어 (MCP-Specific Security Controls)

MCP 계층 자체를 보호하기 위해서는 다음과 같은 특정 제어 수단이 필요합니다:

• 도구 정의 검증 (Tool Definition Validation): 클라이언트는 MCP 도구 정의를 실행하기 전에 신뢰할 수 있는 스키마(known-good schema)와 대조하여 검증해야 합니다. 예상된 스키마에서 벗어나는 모든 사항은 플래그(flag)로 표시되어야 합니다.
• 응답 정화 (Response Sanitization): MCP 서버는 콘텐츠 보안 정책 (Content Security Policy) 엔진과 통합하여 응답을 정화해야 하며, 에이전트에게 응답을 반환하기 전에 비밀 정보(secrets), 개인 식별 정보 (PII), 또는 내부 IP와 같은 민감한 데이터를 제거해야 합니다.
• 샌드박스 실행 (Sandboxed Execution): MCP 서버는 최소한의 권한을 가진 격리된 환경(컨테이너 또는 샌드박스)에서 실행되어야 합니다. MCP 서버는 운영 데이터베이스(production databases)나 운영 파일 시스템(production file systems)에 직접 접근해서는 안 됩니다.

보안 에이전트 인증 구현: 실무 예시

Python과 MCP 서버를 위한 fastapi 프레임워크, 그리고 토큰 처리를 위한 pyjwt를 사용하여 MCP 에이전트를 위한 JIT 자격 증명 (JIT credentials)의 실제 구현 사례를 살펴보겠습니다.

1단계: JWT 검증을 포함한 MCP 서버 정의

from fastapi import FastAPI, HTTPException, Depends
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
import jwt
...

2단계: 클라이언트 측 토큰 요청

에이전트(클라이언트)는 MCP 호출을 수행하기 전에 ID 공급자 (IdP)로부터 토큰을 요청해야 합니다.

import requests
import jwt

...

이 패턴은 에이전트가 필요한 기간 동안 필요한 권한만을 갖도록 보장합니다. 만약 토큰이 유출되더라도 빠르게 만료되므로, 피해 범위 (blast radius)를 제한할 수 있습니다.

인간 참여형 (Human-in-the-Loop, HITL)의 역할

JIT 자격 증명과 정책 엔진이 권한 부여를 자동화하지만, 이것이 높은 위험이 따르는 시나리오에서 인간의 감독 필요성을 대체하지는 않습니다. 운영 환경 배포(production deployments)나 데이터베이스 스키마 변경과 같은 작업의 경우, 인간 참여형 (Human-in-the-Loop, HITL) 체크포인트가 필수적입니다.

이 모델에서 에이전트는 작업(예: "운영 환경에 버전 2.1을 배포하겠습니다")을 제안합니다. MCP 서버 또는 전용 오케스트레이터(Orchestrator)는 실행을 일시 중단하고 인간 승인자에게 알림을 보냅니다. 인간은 에이전트의 추론 과정(컨텍스트 윈도우(Context Window)에 포함될 수 있음)을 검토하고 해당 작업을 승인하거나 거부합니다.

이는 개발 속도를 크게 늦추지 않으며, 고위험 작업에 대해서만 병목 현상을 추가할 뿐입니다. 또한 이는 "에이전트 X가 Y를 제안했고, 인간 Z가 이를 승인함"과 같은 가치 있는 감사 추적(Audit Trail)을 제공합니다.

결론: 일급 시민으로서의 보안 (Security as a First-Class Citizen)

자율 개발 도구의 시대가 도래했으며, 이는 사라지지 않을 것입니다. 에이전트의 능력이 향상됨에 따라 자격 증명 관리(Credential Management) 및 프로토콜 상호작용과 관련된 보안 위험도 커질 것입니다. 인간과 정적 시스템을 위해 설계된 전통적인 보안 모델은 이러한 새로운 현실에 불충분합니다.

자율 에이전트를 보호하기 위해 우리는 다음을 채택해야 합니다:

1. 적시 자격 증명 (Just-in-Time Credentials): 에이전트의 작업 수명 주기(Lifecycle)와 일치하는 수명이 짧고 범위가 제한된 토큰.
2. 코드로서의 정책 (Policy-as-Code): 세밀한 권한을 강제하는 중앙 집중식의 동적 권한 부여 엔진 (예: OPA).
3. MCP 전용 제어 (MCP-Specific Controls): 도구 정의(Tool Definition) 검증, 응답 정화(Sanitization), 그리고 샌드박스 실행(Sandboxed Execution).
4. 인간 참여형 (Human-in-the-Loop): 인간의 감독을 보장하기 위한 고위험 작업에 대한 체크포인트.

에이전트 주도 개발에서 보안은 사후 고려 사항이 되어서는 안 됩니다. 보안은 에이전트, 프로토콜, 그리고 에이전트가 상호작용하는 인프라의 아키텍처 내에 내장되어야 합니다. 자격 증명 관리를 재고하고 동적이며 정책 기반인 보안을 수용함으로써, 우리는 시스템의 무결성을 해치지 않으면서 자율 에이전트의 잠재력을 온전히 끌어낼 수 있습니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: 에이전트에 기존 OAuth2 플로우를 사용할 수 있나요?
A: 네, OAuth 2.0은 좋은 기반이 됩니다. 하지만 머신 간 인증 (machine-to-machine authentication)을 위해서는 "클라이언트 자격 증명 (Client Credentials)" 승인 유형을 사용해야 합니다. 발급된 토큰은 수명이 짧아야 하며, 에이전트의 특정 작업에 맞춰 범위 (scope)가 좁게 설정되었는지 확인해야 합니다.