AWS는 마침내 MCP에 IAM Context Key를 붙였습니다.

이군·6일 전

2026년 5월 6일, AWS는 MCP에 IAM의 새 칼럼을 추가했다. 같은 달 비공식 MCP 서버는 CVSS 9.8을 두 번 받았다. 이 두 사건을 같은 도화지 위에 그려야 한다.

  • 2026년 5월 6일, AWS MCP Server가 GA됐습니다. AI 에이전트가 15,000개 이상의 AWS API를 단일 엔드포인트로 호출할 수 있습니다.
  • 핵심은 두 개의 새 IAM Condition Context Key — aws:ViaAWSMCPService(MCP 경유 여부)와 aws:CalledViaAWSMCP(어느 MCP 경유인지)입니다. IAM 정책에 “AI 에이전트 호출”과 “사람 호출”을 구분하는 칼럼이 생긴 것과 같습니다.
  • 단, 이 통제는 AWS 관리형 MCP 서버에만 적용됩니다. 비공식 aws-mcp-server는 2026년 4월 11일에 CVE-2026-5058 / CVE-2026-5059 두 건이 모두 CVSS 9.8 (Critical) 으로 공개됐고, 인증 없는 RCE입니다.
  • 2026년 5월 시점의 운영자가 던져야 할 질문은 단순합니다: 우리 조직의 MCP 서버는 어느 쪽인가? AWS 관리형 안으로 강제하는 SCP가 있는가?

1. 5월 6일에 일어난 일

AWS는 2026년 5월 6일에 AWS MCP Server의 일반 사용 가능(GA) 을 발표했습니다. AI 코딩 에이전트(Claude Code, Cursor, Codex, Kiro, Windsurf, Cline 등)가 Model Context Protocol을 통해 AWS 서비스에 접근하는 관리형 서버입니다. 같이 발표된 Agent Toolkit for AWS는 MCP Server + Skills + Plugins + Rules 네 요소로 구성됩니다.

기능 요약은 짧습니다:

  • 단일 엔드포인트로 15,000개 이상 AWS API 호출
  • CloudTrail 통합 감사 로깅
  • CloudWatch 메트릭 모니터링
  • 샌드박스 Python 스크립트 실행(run_script) — 에이전트가 짧은 Python을 서버 측에서 실행 가능. 샌드박스는 사용자 IAM 권한은 상속하지만 네트워크 접근이 없습니다.

그런데 진짜 중요한 변화는 기능이 아니라 IAM 모델 그 자체입니다.

Preview 시기의 어색한 모델

2025년 12월 re:Invent 시점의 preview 버전에서는 MCP Server를 호출하려면 aws-mcp:InvokeMcp, aws-mcp:CallReadOnlyTool, aws-mcp:CallReadWriteTool 같은 별도의 IAM 액션 권한을 부여해야 했습니다. MCP를 호출할 권한과 그 너머의 AWS 서비스를 호출할 권한이 별개로 존재하는 어색한 구조였습니다.

GA에서는 이 별도 권한이 전부 폐기됐습니다. 인증·인가는 모두 다운스트림 AWS 서비스 레벨에서 일어납니다. MCP Server는 그저 통과 지점입니다.

새 칼럼 두 개

대신 모든 MCP 요청에 자동으로 두 개의 글로벌 컨디션 키가 붙습니다.

키타입값
aws:ViaAWSMCPServiceBoolMCP 경유 요청이면 true
aws:CalledViaAWSMCPString경유한 MCP의 서비스 프린시펄 (예: aws-mcp.amazonaws.com, eks-mcp.amazonaws.com, ecs-mcp.amazonaws.com, sagemaker-mcp.amazonaws.com)

이게 왜 중요한가? IAM 정책의 표현력에 “이 호출이 AI 에이전트가 시작한 것인가, 사람이 직접 한 것인가”를 분리하는 칼럼이 추가된 것과 같기 때문입니다. 같은 IAM Role이라도 사람이 콘솔에서 누르는 행위와 에이전트가 MCP로 호출하는 행위에 서로 다른 거버넌스를 적용할 수 있게 됐습니다.

2. IAM Context Key를 실전에 어떻게 쓰는가

공식 예시 두 개를 살펴보겠습니다.

예시 ①: MCP 경유 모든 호출 차단 (강력한 게이트)

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:ViaAWSMCPService": "true" }
  }
}

특정 IAM Role(예: 운영팀의 break-glass 역할)이 절대 AI 에이전트를 통해 사용되지 않도록 못 박는 정책입니다. SCP로 OU 단위에 적용하면, 그 OU의 모든 계정에서 민감 작업은 사람만 수행하도록 강제됩니다.

예시 ②: 특정 MCP 서버를 통한 파괴 작업만 차단

{
  "Effect": "Deny",
  "Action": ["s3:DeleteBucket", "s3:DeleteObject"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com"
    }
  }
}

AWS MCP Server 경유의 S3 삭제는 막되, EKS MCP나 ECS MCP 경유는 그대로 두는 방식의 fine-grained 통제입니다.

실무에서 쓸 만한 패턴들

지영님 같은 보안 아키텍트 관점에서 정리해 보면, 다음 다섯 가지가 SCP/IAM 정책의 시작점입니다.

Pattern 1. AI 에이전트는 Read-only로 시작

{
  "Effect": "Deny",
  "Action": [
    "iam:*", "kms:Schedule*", "kms:Disable*",
    "s3:Delete*", "s3:PutBucketPolicy",
    "ec2:Terminate*", "rds:Delete*",
    "secretsmanager:Delete*",
    "*:Delete*", "*:Update*", "*:Put*"
  ],
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:ViaAWSMCPService": "true" }
  }
}

처음 도입할 땐 mutating 액션을 전부 막고, CloudTrail 로그를 보며 점진적으로 화이트리스트를 넓힙니다.

Pattern 2. 운영 환경에서는 AI 에이전트 자체를 차단

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:ViaAWSMCPService": "true" },
    "StringEquals": { "aws:ResourceTag/Environment": "production" }
  }
}

태그 기반으로 production 리소스에 대해서는 MCP 경유 호출 일체 거부.

Pattern 3. 특정 MCP만 허용

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:ViaAWSMCPService": "true" },
    "StringNotEquals": {
      "aws:CalledViaAWSMCP": [
        "aws-mcp.amazonaws.com",
        "eks-mcp.amazonaws.com"
      ]
    }
  }
}

AWS가 관리형 MCP를 추가로 출시할 때마다 명시적으로 허용 목록에 넣지 않으면 사용 불가. default-deny 거버넌스.

Pattern 4. 시간대 기반 게이트

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:ViaAWSMCPService": "true" },
    "DateGreaterThan": { "aws:CurrentTime": "2026-05-13T18:00:00Z" },
    "DateLessThan":    { "aws:CurrentTime": "2026-05-14T09:00:00Z" }
  }
}

업무 시간 외에 AI 에이전트가 자율적으로 작업하는 것을 막는 야간 게이트.

Pattern 5. CloudTrail 알람으로 mutating 행위 추적

{
  "$.userIdentity.invokedBy" exists,
  "$.requestParameters.viaAWSMCPService" = "true",
  "$.eventName" matches /^(Delete|Put|Update|Modify|Terminate).*/
}

CloudTrail Insights / Athena / CloudWatch Logs Insights 쿼리로 MCP 경유의 변경 작업만 골라 보는 대시보드. AI agent action audit의 시작점입니다.

3. 잠깐, 빠진 게 있습니다 — VPC Endpoint와 리전

여기까지만 들으면 깔끔한 그림 같습니다. 하지만 2026년 5월 6일 GA 시점의 현실에는 두 개의 큰 별표가 붙어 있습니다.

별표 ①: VPC Endpoint는 아직 없습니다

공식 블로그가 “coming soon”이라고 명시한 그대로입니다. 즉, 현재 시점의 모든 MCP 트래픽은 퍼블릭 인터넷 엔드포인트를 거칩니다. 규제 산업이나 폐쇄망 요건이 있는 조직은 이 점을 반드시 인지해야 합니다.

VPC Endpoint가 GA되면 추가되는 보안 통제는:

  • two-stage authorization — VPC Endpoint 레벨에서 1차 인가, 다운스트림 서비스에서 2차 인가
  • 네트워크 경계 통제 — Endpoint policy로 어떤 MCP 서버를 어떤 VPC에서 호출할 수 있는지 결정

VPC Endpoint policy + IAM context key 조합은 defense-in-depth의 모범 예시가 될 것입니다. 그러나 그건 미래의 이야기이고, 지금 도입하는 조직은 퍼블릭 엔드포인트 위에서 IAM 정책 하나로 통제를 시작해야 합니다.

별표 ②: 리전이 두 개뿐입니다

2026년 5월 6일 GA 시점에 지원 리전은 us-east-1(N. Virginia) 과 eu-central-1(Frankfurt) 둘뿐입니다.

서울 리전(ap-northeast-1)을 비롯한 아시아·태평양은 미지원입니다. 데이터 거주성·개인정보 국외이전 요건이 있는 한국 조직 입장에서는 현시점 도입은 보류·검증 단계로 운영하는 것이 현실적입니다. 사용자 자격증명을 사용해 다운스트림 API를 호출하는 구조라 사용자 데이터 자체는 리전에 머무르지만, MCP 처리 메타데이터·로그·텔레메트리가 어디로 흐르는지에 대한 별도 검토가 필요합니다.

4. 같은 달, 같은 이름의 비공식 MCP 서버는 CVSS 9.8을 두 번 받았습니다

여기가 이 글의 진짜 흥미로운 지점입니다.

AWS가 5월 6일에 IAM Context Key로 공식 MCP의 거버넌스를 마무리하기 정확히 25일 전, 비공식 aws-mcp-server 에서 두 건의 CVE가 동시에 공개됐습니다.

CVE공개일CVSS유형인증
CVE-2026-5058 (ZDI-26-246, ZDI-CAN-27968)2026.4.119.8 CriticalCommand Injection RCE불필요
CVE-2026-5059 (ZDI-26-245, ZDI-CAN-27969)2026.4.119.8 CriticalAWS CLI Command Injection RCE불필요

CWE-78 (OS Command Injection)의 교과서적 케이스입니다. allowed commands list 처리에서 사용자 입력을 충분히 검증하지 않고 시스템 콜에 넘긴 것이 원인입니다. 공격자는 ;, |, &&, 백틱 등 셸 메타 문자를 주입해 임의 명령을 실행할 수 있고, 그 권한은 MCP 서버 프로세스의 권한입니다.

문제는 그 권한이 무엇인가입니다. Trend Micro가 정리한 표현 그대로 옮기면:

“EC2 인스턴스에서 도는 aws-mcp-server에 광범위한 AWS 리소스 관리 권한의 IAM Role이 붙어 있다고 가정하자. command injection 취약점을 익스플로잇한 공격자는 이제 그 EC2 인스턴스의 권한으로 명령을 실행한다.”

즉, MCP 서버에 IAM Role이 붙어 있으면 — 그 IAM Role이 가진 모든 권한이 인증 없는 공격자 손에 들어갑니다. MCP 서버는 클라우드 환경 전체로 가는 발사대가 됩니다.

비공식 vs 관리형의 보안 모델 차이

측면AWS 관리형 MCP Server비공식 aws-mcp-server (ZDI 보고 대상)
호스팅AWS가 직접 운영사용자가 EC2/컨테이너에 배포
인증SigV4 via Proxy종종 인증 없음 또는 하드코딩 자격증명
입력 검증AWS가 책임메인테이너 책임 — 위 두 CVE가 발생한 이유
IAM 모델aws:ViaAWSMCPService 컨디션 키로 fine-grained서버에 붙은 EC2 Instance Role 권한 = 공격자 권한
패치 채널AWS 자동메인테이너 릴리스 → 사용자 수동 업데이트
폭발 반경AWS 계정 + IAM Role 권한 범위EC2 호스트 + 인접 네트워크 + IAM Role 권한 범위

같은 이름의 aws-mcp-server라는 카테고리에 두 가지가 공존합니다. 운영자가 두 가지를 구분하지 못하는 게 가장 큰 위험입니다.

5. 그래서 — IAM Context Key는 충분한가?

답: MCP 트래픽이 AWS 관리형으로 강제될 때만 충분합니다.

aws:ViaAWSMCPService = true 조건은 비공식 MCP 서버에는 절대 붙지 않습니다. 비공식 MCP 서버는 다운스트림 AWS API를 호출할 때 그냥 EC2 Instance Role의 자격증명으로 호출하고, CloudTrail에는 평범한 API 호출로 찍힙니다. IAM Context Key 기반 통제 정책의 사각지대에 있습니다.

여기서 핵심 정책 패턴이 도출됩니다.

강제 패턴 — “MCP는 관리형 외에는 금지”

SCP 레벨에서, 또는 IAM Identity Center 영구 세션 정책으로:

{
  "Effect": "Deny",
  "NotAction": [
    "sts:AssumeRole",
    "sts:AssumeRoleWithSAML",
    "sts:AssumeRoleWithWebIdentity"
  ],
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:userid": "*:agent-*"
    },
    "Null": {
      "aws:ViaAWSMCPService": "true"
    }
  }
}

“세션 ID에 agent-가 포함된 호출이 aws:ViaAWSMCPService를 가지지 않으면 거부”

즉, 에이전트로 동작하는 세션은 반드시 관리형 MCP를 통과해야 한다는 규칙을 IAM 레벨에서 강제합니다. 위 정책은 개념 예시이며, 조직의 명명 규약·세션 태깅 방식에 맞춰 다듬어야 합니다. 실무에서는 IAM Identity Center session tag 또는 별도 aws:RequestTag/AgentMode 같은 커스텀 태깅을 권장합니다.

보강: 자격증명 폴백 함정

부수적으로, 일본 Serverworks 엔지니어가 GA 직후 발견한 디테일이 한 가지 있습니다. AWS_PROFILE 환경 변수를 비워두고 MCP Proxy를 시작했을 때, 프록시는 ~/.aws/credentials의 default 프로필로 silent fallback 한다는 것입니다. 즉, “프로파일 안 줬으니 동작 안 하겠지” 라는 가정은 틀립니다. 명시적으로 존재하지 않는 프로파일을 주거나, AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY를 빈 값으로 두는 게 안전합니다.

이건 작은 디테일처럼 보이지만, 개발자 워크스테이션에 흩어진 admin 권한 default profile이 예기치 못한 시점에 에이전트에게 상속되는 경로를 만듭니다. EKS Pod Identity의 평문 자격증명 사건과 같은 결, 예기치 못한 자격증명 상속입니다.

6. 실무 도입 체크리스트

조직에서 AWS MCP Server를 도입한다면, 2026년 5월 시점의 현실적 도입 절차는 다음과 같습니다.

Phase 0 — 인벤토리

  • 클러스터·서버·노트북에서 도는 모든 MCP 서버 카탈로그화. 비공식 aws-mcp-server, awslabs/mcp, GitHub fork 등을 식별.
  • 각 MCP 서버에 붙은 IAM Role / 자격증명 발견.
  • CVE-2026-5058 / CVE-2026-5059 영향 여부 확인 후 즉시 차단 또는 격리.

Phase 1 — 관리형 강제

  • AWS MCP Server 사용을 지원 리전(us-east-1, eu-central-1)에서 검증 환경으로 한정해 도입.
  • aws:ViaAWSMCPService = true 가 없는 에이전트 세션 거부 SCP 적용 (조직 명명·태깅 규약 정의 필요).
  • 비공식 MCP 서버의 EC2 Instance Role 권한 즉시 최소화 — 이상적으로는 인스턴스 자체 종료.

Phase 2 — Fine-grained 통제

  • 위 Pattern 1 (read-only default) SCP 적용.
  • 위 Pattern 2 (production 리소스 차단) SCP 적용.
  • CloudTrail Insights / Athena 쿼리로 MCP 경유 mutating action 알람 설정.
  • run_script 샌드박스 사용 정책 문서화 — 네트워크 접근이 없으므로 데이터 유출 경로는 제한적이지만, IAM 권한 상속이라는 점에서 사용 가능 권한을 명시.

Phase 3 — 네트워크 경계

  • VPC Endpoint GA 알림 모니터링 (AWS What’s New, blog).
  • VPC Endpoint 출시 즉시 도입 + Endpoint policy로 어느 VPC에서 어느 MCP를 호출할 수 있는가 결정.
  • 퍼블릭 엔드포인트 경유 호출을 SCP로 차단하는 정책 준비.

Phase 4 — 거버넌스

  • AI agent 호출 vs human 호출 구분 대시보드 (CloudWatch Logs Insights).
  • MCP 경유 행위에 대한 별도 분기 incident response runbook.
  • IAM Identity Center session tag 표준화 — AgentMode=true/false, AgentVendor=anthropic/aws/...

7. 마치며 — IAM의 표현력은 충분히 따라왔는가

지난 10년의 AWS IAM 진화를 한 줄로 요약하면, 컨디션 키가 늘어난 역사입니다. aws:SourceIp → aws:VpcSourceIp → aws:PrincipalOrgID → aws:CalledVia → aws:CalledViaFirst → … 매번 새로운 추상화 계층이 등장할 때마다, IAM은 그 계층을 표현하는 새 칼럼을 추가해 왔습니다.

aws:ViaAWSMCPService는 그 진화의 AI 에이전트 시대 첫 칼럼입니다. 의미는 큽니다. 지금까지 IAM 정책의 주어는 사람 또는 서비스였습니다. 이제 “AI 에이전트가 시작한 호출”이라는 제3의 주어가 정책 표현력에 들어왔습니다.

그러나 이 칼럼이 모든 곳에 자동으로 붙는 게 아닙니다. AWS가 관리하는 MCP 서버에만 붙습니다. 조직이 MCP 트래픽을 그쪽으로 강제하는 정책을 따로 설계하지 않으면, 이 컨디션 키는 잘 만든 도구가 사용되지 않는 상태로 남습니다.

비공식 aws-mcp-server는 같은 달 CVSS 9.8을 두 번 받았습니다. 둘 다 인증 없이 RCE입니다. 그 서버에 EC2 Instance Role이 붙어 있다면 — 그 Role의 권한은 사실상 인터넷에 공개된 것입니다. 이 두 사실을 같은 도화지 위에 그려야 합니다.

Prompt Injection은 SQL Injection의 환생이라고 했습니다. MCP 보안은 그 환생의 다음 장입니다. 어떤 입력 채널이 신뢰되는가, 어떤 채널은 untrusted인가, 어떤 추상화 계층에서 인가가 강제되는가 라는 동일한 질문이, 단지 SQL 쿼리에서 자연어 도구 호출로 옮겨갔을 뿐입니다.

IAM Context Key는 좋은 시작입니다. 그러나 시작에 머무르지 않으려면, 조직이 MCP 트래픽을 관리형으로 강제하는 거버넌스가 함께 가야 합니다. 도구가 잘 만들어진 것과 도구가 잘 쓰이는 것은 다른 문제입니다.

참고

profile
이군
이군의 보안, 그리고 생각을 다룹니다.
이전 포스트

에이전트가 마우스 커서를 잡았을 때 — Amazon WorkSpaces for AI Agents 위협 모델링

0개의 댓글