모델 컨텍스트 프로토콜을 사용한 에이전트 상호작용 보안을 위한 권장사항

모델 컨텍스트 프로토콜 (MCP)은 생성형 AI 에이전트가 Firestore에 연결하는 방식을 표준화합니다. 자율 에이전트의 고유한 위험으로 인해 프롬프트 삽입과 같은 취약점을 완화하려면 플랫폼 제어와 보안 애플리케이션 설계를 결합하는 공유 책임 모델이 필요합니다.
모델 컨텍스트 프로토콜 (MCP) 도구를 사용하는 AI 애플리케이션을 설계하고 배포하려면 Google Cloud 이 가이드의 권장사항을 따르세요.

시작하기 전에

MCP 도구를 사용하면 애플리케이션의 보안 상황이 에이전트의 상호작용 모델에 따라 달라집니다. 에이전트 사용이 MCP 서버와의 에이전트 통합과 관련된 보안 위험에 미치는 영향을 알아보려면 AI 보안 및 안전을 참고하세요.

보안 책임

고객은 에이전트 플랫폼의 보안 구성 및 운영을 책임집니다.

최소 권한의 원칙 준수

최소 범위 서비스 계정으로 에이전트를 실행합니다. 이는 첫 번째이자 가장 중요한 방어 계층입니다.

전용 ID: MCP 도구를 사용하여 고유한 에이전트 또는 애플리케이션마다 별도의 전용 서비스 계정을 만듭니다. 기존 SA, 특히 광범위한 권한이 있는 SA를 재사용하지 마세요.
최소 범위: 서비스 계정에 필요한 Identity and Access Management(IAM) 역할만 부여합니다(예: alloydb.admin이 아닌 alloydb.viewer). 에이전트가 특정 데이터 세트에 대한 읽기 액세스 권한만 필요한 경우 커스텀 IAM 역할을 사용하여 기능에 필요한 최소한의 액세스 권한으로 액세스를 제한합니다.
직무 분리: 에이전트가 데이터에 대한 읽기 액세스와 로그 또는 임시 저장소에 대한 쓰기 액세스가 모두 필요한 경우 두 개의 별도 서비스 계정을 사용합니다. 하나는 위험도가 높은 데이터 액세스 (최소 범위)용이고 다른 하나는 위험도가 낮은 운영 작업용입니다.

데이터베이스 네이티브 세부 제어 사용

가장 강력한 방어를 위해서는 IAM 역할을 데이터베이스 자체에서 제공하는 세분화된 액세스 제어와 결합하세요. 이렇게 하면 공격자가 에이전트의 IAM 토큰을 침해하더라도 데이터베이스 엔진의 내부 권한에 의해 피해 범위가 제한됩니다. 예를 들어 DROP TABLE

제품	세부 제어 메커니즘	포커스
Cloud SQL 및 AlloyDB	PostgreSQL 및 MySQL의 CREATE ROLE과 같은 데이터베이스 수준 역할	특정 데이터베이스 인스턴스 및 스키마의 권한을 관리합니다.
BigQuery	열 수준 액세스 제어 (정책 태그 사용)	승인된 테이블에서도 에이전트의 민감한 열(예: PII)에 대한 액세스를 제한합니다.
Spanner	세분화된 액세스 제어 (`GRANT/REVOKE`이 있는 데이터베이스 역할)	테이블과 열에 대한 정확한 읽기/쓰기/업데이트 권한을 적용합니다.
Firestore	Firestore 보안 규칙	애플리케이션의 논리 또는 요청 사용자 컨텍스트에 따라 문서 수준 또는 필드 수준 액세스를 제한합니다.
Bigtable	IAM 역할	Bigtable은 프로젝트, 인스턴스, 테이블 수준에서 IAM 역할을 통해 세부적인 제어를 제공합니다.

안전한 에이전트 설계

에이전트 전용 모델에는 시스템 프롬프트를 재정의하려고 시도하는 프롬프트 인젝션 공격에 대한 강력한 애플리케이션 수준 방어가 필요합니다. 자세한 내용은 AI 안전 및 보안을 참고하세요.

데이터와 사용자 입력을 신뢰할 수 없는 것으로 취급

최종 사용자의 입력 또는 에이전트가 웹 검색 결과나 서드 파티 문서와 같은 외부 소스에서 가져온 데이터를 신뢰할 수 없는 것으로 취급합니다.

작업 선택 패턴 구현

시스템이 상위 수준 작업 사양을 기계적 실행에서 분리하는 개방형 계획 및 실행 아키텍처를 피하세요. 대신 모델의 자유도를 제한하는 설계 패턴을 사용하세요.

작업 선택기 패턴: 모델의 유일한 작업은 사용자 요청을 미리 정의된 소규모의 안전한 함수 중 하나로 변환하는 것입니다. 작업 로직은 하드 코딩되어 있으며 LLM으로 수정할 수 없습니다. 이렇게 하면 에이전트가 제어 흐름을 타겟팅하는 삽입 공격에 면역이 됩니다.
이중 LLM 패턴: 핵심 작업을 실행하는 기본 LLM (작업 LLM)과 악의적인 의도가 있는지 사용자 프롬프트를 사전 검사하고 작업 LLM의 출력을 사후 검사하여 승인되지 않은 작업이나 데이터 유출을 방지하는 보조 보안 LLM (가드레일 LLM)을 사용합니다.

승인되지 않은 도구 체인 방지

상담사는 작업에 필요한 도구만 호출해야 합니다. 오케스트레이션 코드가 다음을 방지하는지 확인합니다.

동적 도구: 에이전트가 새 도구를 동적으로 등록하거나 기존 도구의 권한을 변경할 수 없어야 합니다.
허용 목록 시행: 에이전트가 초기 시스템 프롬프트와 백엔드 코드에서 액세스할 수 있는 함수 또는 데이터베이스 테이블의 허용 목록을 선언합니다. Gemini CLI 예는 도구 액세스 제한을 참고하세요.

보안 및 안전 구성

Firestore는 플랫폼 수준에서 안전 경계를 적용하는 Model Armor를 제공합니다. 이러한 설정을 사용 설정하고 구성해야 합니다.

Model Armor 사용 설정

Google Cloud CLI를 사용하여 모델 배포에서 Model Armor를 사용 설정합니다. 이렇게 하면 인젝션 및 탈옥과 같은 알려진 공격 벡터에 대한 기본 제공 보호가 활성화됩니다.

다음 예에서는 Vertex AI 엔드포인트에서 Model Armor를 사용 설정합니다.

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

자세한 내용과 예시는 Google Cloud에서 MCP용 Model Armor 보호 구성을 참고하세요.

민감한 데이터 작업에 최소 안전 기준점 적용

Model Armor를 사용하면 민감한 데이터 작업(예: 개인 식별 정보(PII) 감지 및 비식별화)에 최소 안전 기준을 적용할 수 있습니다. 모델이 손상된 경우에도 민감한 정보가 사용자에게 반환되기 전에 민감한 정보를 수정하거나 마스킹하려면 민감한 정보 보호 DeidentifyTemplate를 사용하세요.

다음은 구성의 개념적 예입니다.

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

다음 예에서 model_armor_config.json은 DLP 템플릿을 참조할 수 있습니다.

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

감사 및 관측 가능성

에이전트 작업에 대한 가시성은 사고 후 분석과 손상된 에이전트 감지에 매우 중요합니다.

데이터 복구 전략 구현

IAM 및 데이터베이스 네이티브 역할과 같은 계층화된 컨트롤은 파괴적인 작업을 방지하도록 설계되었지만 이러한 방어가 실패할 경우를 대비하여 복구 계획이 있어야 합니다. 쓰기 권한이 있는 손상된 또는 순진한 에이전트('에이전트 전용' 위험)가 DROP TABLE와 같은 파괴적인 명령어를 실행하거나 데이터를 손상하도록 속일 수 있습니다.

이 시나리오에 대한 기본 방어는 강력한 복구 전략입니다.

거의 모든 Data Cloud 제품은 기존 백업, PITR (point-in-time recovery) 또는 데이터 스냅샷을 통해 데이터 복구 기능을 제공합니다. 이러한 기능을 사용 설정하고 구성하는 것은 사용자의 책임입니다.

제품	백업 및 복구 메커니즘
Cloud SQL	주문형 백업과 자동 백업을 모두 지원하므로 인스턴스를 이전 상태로 복원할 수 있습니다. 또한 PITR (point-in-time recovery)도 지원합니다.
AlloyDB	기본적으로 지속적인 백업 및 복구를 제공합니다. 이렇게 하면 마이크로초 단위로 PITR이 가능해지므로 보관 기간 내의 어느 시점으로든 클러스터를 복원할 수 있습니다.
BigQuery	데이터 복구는 지난 7일 이내의 어느 시점에서든 데이터에 액세스하고 데이터를 복원할 수 있는 '시간 이동'을 사용하여 이루어집니다. 장기 보관의 경우 테이블 스냅샷을 만들 수 있습니다.
Spanner	주문형 백업과 PITR을 모두 지원합니다.
Firestore	관리형 내보내기/가져오기를 백업으로 지원합니다. 또한 실수로 인한 삭제나 쓰기를 방지하기 위해 기본적으로 사용 중지된 PITR을 제공합니다.
Bigtable	주문형 및 자동 백업을 지원합니다. 이러한 백업은 완전 관리형이며 새 테이블로 복원할 수 있습니다.

Cloud 감사 로그 사용 설정

MCP와 BigQuery, Cloud SQL, AlloyDB, Spanner와 같은 모든 관련 Google Cloud 서비스에 대해 데이터 액세스 감사 로그가 사용 설정되어 있는지 확인합니다. 기본적으로 관리자 활동 감사 로그만 사용 설정됩니다. 데이터 액세스 감사 로그는 에이전트가 실행한 모든 읽기 및 쓰기 작업을 기록합니다. 자세한 내용은 MCP의 데이터 액세스 감사 로그를 참고하세요.

민감한 작업 감사

Cloud Logging에서 알림을 구성하여 비정상적이거나 위험도가 높은 작업을 감지합니다. 로그 탐색기 쿼리는 Firestore에서 데이터 쓰기 작업을 실행하는 서비스 계정을 식별합니다. 이는 유출 또는 파괴적인 공격의 일반적인 타겟입니다.

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

에이전트별 로깅 사용

Cloud 감사 로그 외에도 애플리케이션 코드가 모든 에이전트 결정에 대해 다음 데이터를 로깅해야 합니다.

도구 실행: 호출된 MCP 도구입니다.
원시 명령어: LLM에서 생성한 정확한 명령어(예: SQL 쿼리 또는 문서 경로)입니다.
최종 작업: 작업이 실행되는지 (상담사 전용 모델) 또는 승인되는지 (Human-in-the-Middle) 여부입니다. 자세한 내용은 에이전트 사용 이해하기를 참고하세요.
사용자 및 세션 ID: 요청을 시작한 최종 사용자의 식별자입니다.