M2. 도구 연결과 4단계 조사 — Gateway (★ 핵심)

M2는 워크샵의 하이라이트 모듈입니다. Gateway로 5개 로그 그룹을 조회하는 3개의 도구(query_security_logs / get_waf_blocked_requests / get_incident_history)와 web-search 커넥터 타겟을 MCP 도구로 노출하고, 조사 티어(GPT 5.6 Luna) + 판정 티어(Claude Fable 5) 하이브리드 에이전트가 4단계 조사 프로토콜로 “경고 수백 건 → 공격 1건”을 압축해 냅니다.

M2 아키텍처 — Runtime의 하이브리드 에이전트가 IAM 서명 SigV4로 Gateway(MCP)에 붙어 log-query-tools Lambda 타겟(3개 도구)과 web-search 커넥터 타겟을 호출하고, 조사관(Luna)+판정관(Fable 5)이 함께 동작합니다.

M2에서 만드는 부분입니다. Gateway가 MCP 프로토콜로 도구를 노출하고, IAM 인바운드 auth를 통해 Runtime의 에이전트가 SigV4 서명으로 붙습니다.

이 모듈에서 다루는 개념

AgentCore Gateway (IAM 인바운드 auth) — 기존 Lambda API와 빌트인 커넥터(Web Search)를 MCP 프로토콜의 도구로 변환합니다. IAM auth를 쓰면 별도 OAuth 설정 없이 SigV4 서명만으로 붙을 수 있습니다.
조사 티어 + 판정 티어 하이브리드 — 조사관(Luna, GPT 5.6)은 도구를 반복 호출하면서 로그 증거를 모으고, 판정관(Fable 5, Claude)은 조사 노트를 검토해 최종 판정을 냅니다.
로그 증거 게이트 — 시스템 프롬프트가 “로그를 직접 조회하지 않고 결론 내리지 말라”를 명시하고, 조사관이 실제로 로그 조회 도구를 호출했는지 메시지 트레이스에서 검증합니다. 호출이 없으면 1회 강제 재조사를 지시합니다.
4단계 조사 프로토콜 — (1) 컨텍스트 확보 → (2) 로그 심층 분석 → (3) 상관관계 분석 → (4) 근본 원인 도출(5 Whys).

Gateway와 도구 두 개를 만듭니다.

lab-src/m2/setup_gateway.py가 다음을 한 번에 수행합니다.
- aiops-security-gateway-service-role IAM 서비스 롤 생성/재사용
- aiops-security-gateway(MCP + AWS_IAM auth) 생성 및 READY 폴링
- Lambda 타겟 log-query-tools 생성 — 로그 조회 도구 3종(toolSchema.inlinePayload)
- 커넥터 타겟 web-search 생성 (connectorId: web-search)
Terminal window
```
cd lab-src/m2
python3 setup_gateway.py
```
마지막 두 줄에 GATEWAY_URL=... / GATEWAY_ID=...가 출력되면 성공입니다. 두 값은 M3와 cleanup에서 재사용하므로 저장해 두세요.
Terminal window
```
export GATEWAY_URL=$(python3 setup_gateway.py | awk -F= '/^GATEWAY_URL=/{print $2}')
```
create_gateway 응답이 돌아와도 상태가 CREATING일 수 있고, 그 사이 타겟을 만들면 ValidationException: Cannot perform operation CreateGatewayTarget when gateway is in CREATING status가 납니다. setup_gateway.py는 READY가 될 때까지 폴링하도록 되어 있으니 [gateway] status: CREATING — READY 대기 중... 로그가 몇 번 보이는 것은 정상입니다.
M1 프로젝트의 main.py를 lab-src/m2/main.py 내용으로 교체합니다.

M2 main.py의 핵심 변화는 세 가지입니다.
- 조사 티어(Luna) 추가 — OpenAIResponsesModel(model_id="openai.gpt-5.6-luna", base_url="https://bedrock-mantle.us-east-1.api.aws/openai/v1", ...) 로 Bedrock Mantle Responses 경로를 호출합니다.
- 판정 티어(Fable 5) 유지 — BedrockModel(model_id="global.anthropic.claude-fable-5", ...).
- MCP 클라이언트 연결 — mcp_proxy_for_aws.client.aws_iam_streamablehttp_client로 Gateway에 SigV4 서명 붙여 붙습니다. pyproject.toml dependencies에 mcp-proxy-for-aws를 추가해 주세요.
.env.local에 GATEWAY_URL을 반영합니다.
Terminal window
```
echo "GATEWAY_URL=$GATEWAY_URL" >> agentcore/.env.local
```

로컬에서 4단계 조사를 확인합니다.

agentcore dev --logs   # 터미널 1
agentcore dev "동일 IP에서 401 응답이 대량 발생했습니다. 원인 분석해 주세요."   # 터미널 2

응답의 조사관 노트에서 다음을 확인해 주세요.

1단계 컨텍스트 확보: WAF/ALB/app-auth 중 어떤 로그 그룹을 볼지 판단.
2단계 로그 심층: query_security_logs(log_group="waf", filter="BLOCK") 등이 호출되고 실제 결과(IP·시각·볼륨)가 인용됨.
3단계 상관관계: 여러 로그 소스 교차 검증 + 필요 시 get_incident_history("credential_stuffing") 호출.
4단계 근본 원인: “정상 세일 트래픽이 아니라 203.0.113.x 대역 봇넷에 의한 크리덴셜 스터핑”으로 지목.

판정관(Fable 5)의 최종 판정은 (1) 판정 요약과 확신도, (2) 핵심 IoC(IP·계정·경로), (3) 즉시 대응 3가지, (4) 후속 조사 항목의 4개 섹션으로 구성됩니다.

실측 출력 원문입니다 — 2026-07-16, 조사관(Luna, openai.gpt-5.6-luna) + 판정관(global.anthropic.claude-fable-5) 하이브리드 실행. Gateway aiops-security-gateway-qnftbwdkwb를 통한 실제 로그 조회 결과에 근거합니다 (합성 데모 값).

[investigator] 1단계 컨텍스트: 401 폭증 → 대상 로그 그룹 후보
               = /fashion/app-auth, /fashion/alb, /fashion/waf
[investigator] 2단계 로그 심층 (실제 도구 호출):
  - get_waf_blocked_requests(time_range={"last_minutes":100000})
    → 5건 BLOCK (rule=RateBasedRule_Login, src_ip=203.0.113.17,
      path=POST /api/login)
  - query_security_logs(log_group="app-auth", filter="203.0.113.17",
                        time_range={"last_minutes":100000})
    → 6건 (실패 5, 성공 1)
  - query_security_logs(log_group="alb", filter="203.0.113.17", ...)
    → 401/429 응답 다수
[investigator] 3단계 상관관계:
  - user0042@example.com: 실패 3건 + 성공 1건
    (suspected_compromise: true)
  - user0311@example.com: 실패 2건
[investigator] 4단계 5 Whys:
  - 왜 성공 이후 위험 행위로 이어졌는가?
    → oracle-audit `FASHION.ORDERS` 조회 7건이 동일 IP와 연관됨
...

===== 판정관 최종 판정 =====
공격 유형: 크리덴셜 스터핑 계열의 소규모·표적형 계정 탈취(ATO)
          — 이후 탈취 세션의 데이터 접근 의심
확신도: 높음
핵심 IoC:
  - IP: 203.0.113.17 (WAF BLOCK 5건 + app-auth 6건)
  - 계정: user0042@example.com (성공 1건, suspected_compromise=true)
  - 경로: POST /api/login
즉시 대응:
  1) user0042 계정 잠금 + 세션·토큰 무효화
  2) 203.0.113.0/24 대역 WAF 임시 차단
  3) 최근 24시간 성공 로그인 전수 감사
후속 조사:
  - 다른 IP 대역으로 로테이션 여부 확인
  - 동일 자격증명이 사내 다른 서비스에서 시도되었는지 크로스 조사

조사관이 실제 4단계 로그 상관관계로 “경고 5건+6건(증상) → 공격 1건(원인, 계정 침해)” 관점을 실증했다는 점, 그리고 판정관이 크리덴셜 스터핑을 정확히 지목했다는 점이 M2의 핵심 학습 포인트입니다.

M1 응답과 비교합니다.

M1에서 저장해 둔 응답과 M2 응답을 나란히 놓으세요. 차이가 명확히 보여야 합니다.
- M1: “가능성이 높습니다” 같은 사전 지식 기반 진술, 구체적인 IP·시각·볼륨 부재.
- M2: 실제 로그로 확인된 IP 대역·발생 시각·요청 볼륨을 인용한 근거 기반 결론.

Runtime에 재배포합니다.

agentcore deploy
agentcore invoke '{"prompt": "동일 IP에서 401 응답 500회 발생. 원인 분석해 주세요."}'

agentcore status로 배포 상태를 확인하세요.

로그 증거 게이트 — 왜 필요한가

조사관에게 도구를 붙여 두어도, LLM이 사전 지식만으로 결론을 내려 버리는 경우가 있습니다. lab-src/m2/main.py의 _called_log_tool() 함수는 조사관의 메시지 트레이스에서 query_security_logs / get_waf_blocked_requests 호출 여부를 확인하고, 없으면 강제 재조사를 요청합니다. 두 번째 시도에도 로그 도구 호출이 없으면 판정관에게 “증거 불충분” 신호를 명시합니다.

web-search / get_incident_history만으로는 증거로 인정하지 않습니다 — 위협 인텔리전스나 과거 이력은 “참고”이지, 이번 인시던트의 실측 증거가 아니기 때문입니다.

체크포인트

setup_gateway.py가 GATEWAY_URL / GATEWAY_ID를 출력하고, list-gateway-targets에 두 타겟(log-query-tools, web-search)이 보입니다.
조사관 노트에 실제 도구 호출 결과(IP·시각·볼륨)가 인용되어 있고, 판정관 판정에 확신도와 핵심 IoC(203.0.113.x, 198.51.100.9, /api/login, 침해 의심 계정 user0042@example.com / user0311@example.com)가 등장합니다.
다음 모듈에서 재사용할 값: GATEWAY_URL, GATEWAY_ID — M3의 Memory 회상 조사관도 같은 Gateway를 씁니다.

다음은 M3. Memory — 2차 인시던트 가속입니다.