원격 Vault P1b 인증 시험 배포안
2026-09-05 범위 변경: 아래는 과거 시험·구현 기록이다. 현재 실행은 원격 Vault 재설계와 선행 검증의 로컬 stdio/SSH 계획을 따른다. 웹·Android와 Auth0 후속 시험은 재개하지 않는다. AWS 시험 리소스는 사용자 요청으로 보존한다. Auth0 정리 상태는 HANDOFF에서 확인한다.
원격 Vault P1a Auth0 후보와 실험 범위의 metadata 검사 뒤 준비한 배포안과 후속 실제 실행 기록이다. AWS의 현재 한도·정책과 기존 코드를 대조하고 로컬 권한 초안을 만들었다. 후속 연속 진행 요청으로 로컬 구현·AWS 배포와 차단/재개, ChatGPT discovery·Auth0 API 생성을 수행했다. 현재 상태와 자동 승인 검토의 차단은 마지막 기록을 따른다. 아래 제안 시점의 미실행 문구는 당시 이력이다.
목적과 대상은 MCP의 목적은 여러 모델이 같은 Vault를 이용하게 하는 것이다와 원격 Vault P0 환경 확인과 P1 최소 시험을 따른다. 여섯 환경의 인증 시험이며 Vault 데이터·GitHub 커밋·문서 발견 시험은 별도다.
실제 확인과 기존 코드의 차이
2026-09-05 호스트 AWS CLI로 서울 리전의 account concurrency 10, unreserved 10, 함수 수 0과 빈 함수 목록을 재확인했다. 기존 예약 동시성 1 실패를 해소한 결과는 아니다. 시험 사용자 신원은 계정 886682668993의 vault-preflight다.
실제 연결된 vault-preflight-operator 정책은 vault-preflight-mcp 함수와 같은 이름의 로그 그룹을 관리하고 URL 변경·삭제·권한 제거를 허용한다. PassRole은 기존 vault-preflight-runtime에만 있다. 로컬 deployment 폴더의 정책 초안과 실제 연결된 정책은 다르므로 로컬 파일을 현재 권한으로 오인하지 않는다. SignInLocalDevelopmentAccess도 붙어 있지만 이번 배포 권한 판단의 근거로 사용하지 않았다.
기존 protected/lambda.mjs는 Cognito 인증과 SSM의 GitHub 토큰, GitHub 저장 모듈을 연결한다. deployment/deploy.ps1·enable.ps1은 Cognito pool·두 client·subject 형식·기존 read/marker를 전제로 한다. 해당 번들과 스크립트를 Auth0 probe로 그대로 배포하지 않는다. 메타데이터/HTTP 처리의 검사항목·소유권 영수증 패턴은 재사용하고 인증·도구·배포 입력은 최소 probe용으로 작성한다.
대상과 설정 제안
| 항목 | 제안 |
|---|---|
| 계정·리전·실행자 | 886682668993, ap-northeast-2, 호스트 vault-preflight 프로필 |
| 함수 | 현재 없는 vault-preflight-mcp 1개. 생성 직전 이름 충돌 시 중지 |
| 실행 역할 | 새 vault-auth-probe-runtime 1개, Lambda 신뢰·지정 로그 스트림 쓰기만 |
| 실행 크기 | Node.js 22, arm64, 256 MB, timeout 10초, 기본 임시 저장소. VPC/NAT·provisioned concurrency 없음 |
| 공개 경로 | Function URL, BUFFERED, /mcp. 실제 생성 URL을 resource/API identifier로 사용 |
| 동시성 | 시험에 한해 AccountShared 제안. 현 한도 10을 사용하며 함수별 1 제한이 아님 |
| 실행 창 | 공개 직전에 UTC 종료 시각을 기록, 최대 120분. 작업 종료가 먼저면 즉시 닫음. 매 다음 실행 창은 명시적으로 재개 |
| 로그 | /aws/lambda/vault-preflight-mcp, retention 1일. 제한된 합성 증거만 남김 |
| 외부 의존 | Auth0 공개 discovery/JWKS, 후속 실제 OAuth. 런타임 Management API·SSM·GitHub·DynamoDB 권한 없음 |
공용 한도 사용은 아직 외부 실행 승인으로 확정하지 않았다. 현재 함수가 없다는 사실도 향후 다른 워크로드와의 격리를 보장하지 않는다. 이 조건을 받아들일 수 없으면 할당량 조정과 함수별 한도를 먼저 검토한다. API Gateway/CloudFront/추가 DB를 비용 통제 명목으로 자동 추가하지 않는다.
최소 권한 묶음
HTML 작업 폴더의 auth0-p1b/에 다음 실제 JSON 초안을 보존했다. 모두 미적용이다.
runtime-trust.json: Lambda 서비스만 역할 수임.runtime-policy.json: 지정 로그 그룹의 스트림 생성·이벤트 기록만. 로그 그룹 생성·보존 설정은 운영자 담당.operator-passrole-delta.json: 시험 사용자에 추가할 새 역할의 PassRole(Lambda로 제한)·GetRole. 기존 관리형 정책 전체를 덮어쓰지 않는 별도 inline policyvault-auth-probe-passrole제안.public-url-policy.json: 해당 함수의 InvokeFunctionUrl(NONE 조건)과 InvokeFunction(Function URL 경유 조건) 두 문장. 직접 Invoke API 전체 공개가 아님.deployment-plan.json,observed-aws.json,cost-scenarios.json: 대상·현재 증거·비용 가정.
기존 관리자 경로는 새 실행 역할과 위 inline policy를 준비하는 데만 사용한다. 함수 배포·정지·로그 검사는 전용 사용자로 실행한다. 현재 운영자에게 남아 있는 과거 DynamoDB 권한을 이번 probe에서 사용하지 않으며 기존 권한의 일괄 정리도 수행하지 않는다. 정책 JSON 파싱은 IAM의 실제 허용·전파 확인을 대신하지 않는다.
Function URL 권한 문서에 따라 두 Invoke 권한을 적용한다. 공개 URL은 Lambda 계층에서 무인증 요청도 함수까지 전달한다. MCP 인증과 권한 검사는 함수에서 수행하므로 거절 요청에도 실행비가 생길 수 있다.
probe와 공개 전 순서
- 새 로컬 구현에서 stateless Streamable HTTP의 initialize·notifications·tools/list·tools/call을 처리하고
auth_probe하나만 노출한다. 장기 SSE 연결·영속 세션을 이번 범위에 추가하지 않는다. 실제 여섯 클라이언트 호환성은 배포 후 판정한다. - discovery 모드에서는 공개 메타데이터와 인증 안내만 제공하고 도구 실행은 전부 거부한다. 클라이언트/사용자 허용 목록이 비어 있으면 active 모드로 전환할 수 없다. issuer는
https://vault-preflight-20260905.jp.auth0.com/, resource는 실제 URL+/mcp로 정확히 고정한다. - active 모드에서는 Auth0 JWKS 서명·허용 알고리즘·issuer·audience·exp/nbf·허용 subject/client 및 scope를 검증한다. 필요한 client 식별 claim의 실제 형태는 최초 발급 토큰에서 확인한다. 검증 실패를 허용으로 바꾸지 않는다. JWKS 조회 timeout/캐시·갱신 실패 처리도 로컬 시험한다.
- read는
probe:read, check_write_scope는probe:read와probe:write를 모두 요구한다. 반환은 실행 ID·서버 UTC 시각·합성 결과뿐이며 저장하지 않는다. 로그는 실행 ID·판정·지연을 제한 길이로 기록하고 요청 본문·Authorization·code/state·토큰·개인 식별값은 기록하지 않는다. - 공개 전 역할/코드 hash·태그·URL·종료 시각을 소유권 영수증에 기록한다. 처음 URL은 AWS_IAM으로 만들어 비서명 요청 차단을 확인한다. 짧게 discovery 공개 → AWS_IAM 차단 → discovery 재개를 시험 사용자 권한으로 검증한 뒤 등록 작업에 사용한다. 실패하면 URL 삭제와 독립 거부 확인 후 중지한다.
- 실제 endpoint로 ChatGPT 등록 화면의 callback·인증 방식을 확인한다. 이후 Auth0 API 1개, 실제 callback에 맞는 client, 최소 시험 사용자 설정을 준비/적용한다. six surfaces와 client 개수를 동일시하지 않는다. Auth0 관리자 계정과 probe 최종 사용자 신원도 구분한다.
- 로컬 코드·거부 시험 통과와 실환경 설정 확인 뒤 active로 전환한다. P1c의 여섯 환경 호출, P1d 거부, P1e 회수는 각각 기록한다.
Auth0의 시험 access token 수명은 5분을 우선 제안하고, 갱신 시험에 offline_access를 사용한다. 실제 UI 허용 범위·refresh 회전/수명·로그인 연결 제한은 API/client 설정 단계에서 값을 확정한다. 이를 사용자 운영 허용 지연으로 채택하지 않는다. 새 deny DB나 Cognito GetUser를 붙이지 않고 기존 access token 만료까지의 수용 지연을 관찰한다.
정지·재개·정리 계약
일반 정지: 영수증의 계정·리전·함수 ARN·역할·태그·코드 hash를 대조하고 URL을 AWS_IAM으로 변경한다. 설정 재조회와 서명 없는 실제 HTTP 거부를 확인한다. 주소를 유지하므로 후속 시험에 재사용할 수 있다. 이 동작은 특정 사용자의 토큰 회수가 아니라 외부 MCP endpoint 전체의 새 요청 차단이다.
실제 명령의 핵심은 다음과 같다. 이번에는 실행하지 않았다. 구현할 스크립트에는 위 소유권 확인과 각 명령의 exit code 검사를 붙인다.
aws lambda update-function-url-config --function-name vault-preflight-mcp --auth-type AWS_IAM --profile vault-preflight --region ap-northeast-2
aws lambda get-function-url-config --function-name vault-preflight-mcp --profile vault-preflight --region ap-northeast-2정지 실패 시: 같은 영수증 대상의 DeleteFunctionUrlConfig → 부재 조회 → 기존 URL의 실제 거부를 확인한다. URL 삭제가 필요하면 재생성 주소가 같다고 가정하지 않고 resource/audience와 client 연결을 다시 대조한다. 두 동작 모두 실패하면 관리자 경로로 동일 대상의 URL/함수를 닫으며 정상 정지로 보고하지 않는다.
보조 수단: AWS는 reserved concurrency 0을 정지 방법으로 안내하지만 이 계정에서 실행해 검증하지 않았으므로 주 정지 수단으로 의존하지 않는다. 애플리케이션 만료·PROBE_ENABLED=false는 함수 실행 전 과금 차단이 아니다. 이미 처리 중인 요청은 종료를 약속하지 않고 timeout 범위에서 관찰한다. IAM 서명 권한이 있는 관리자의 직접 호출까지 차단했다고 보지 않는다.
시간 관리: 공개 상태로 작업을 끝내지 않는다. 종료 시각 전에 운영자가 URL을 닫고 확인한다. 로컬 세션 종료·PC 절전 등으로 이 조작을 못하면 애플리케이션 만료만 남고 호출 비용은 계속 생길 수 있다. 따라서 무인 운영을 보장하지 않는다. 독립 자동 정지가 필요하면 별도 일회성 Scheduler 권한·비용을 검토하며 이번에 예약 작업을 만들지 않는다.
재개: 소유권과 종료 시각을 다시 확인하고 discovery 상태에서 NONE으로 전환·메타데이터 응답을 검증한다. 회수 시험 중에는 토큰/로그인을 임의 초기화하지 않는다.
최종 정리: 먼저 URL 차단, 해당 시험 연결 해제/refresh·grant 회수, 영수증 소유 URL·공개 permission·함수·로그 그룹·새 역할·새 inline policy만 제거한다. 실제 부재와 기존 URL 거부를 확인한다. Auth0 tenant 삭제는 별도 승인 범위이며 기존 운영자 관리형 정책·기존 역할·계정 전체는 삭제하지 않는다.
근거: URL 관리, 동시성·0 정지. 2026-09-05 공식 문서 확인. 문서 지원과 이 계정의 정지 성공을 분리한다.
비용과 실행 판단
2026-09-05 20:27 +09:00 AWS 서울 리전 공개 가격표를 직접 조회했다(publication 2026-08-31). 요청 0.0000002/회, ARM 첫 구간 0.0000133334/GB초. 무료 할당·크레딧은 가정하지 않는다.
| 시나리오 | Lambda 연산·요청비 계산 |
|---|---|
| 1,000회 × 256 MB × 1초 | 약 $0.00353 |
| 2시간 내내 동시 실행 10 × 256 MB | 연산비 약 $0.24000, 요청비는 별도 |
| 요청 100만 회 추가 | 요청비 $0.20, 연산비 별도 |
로그·전송·세금 및 가정한 시간 밖 초기화 비용은 위 값에서 제외했다. 최대 2시간은 운영 창이며 청구액 상한이 아니다. 정상 시험 1,000회 이하·짧은 합성 응답을 목표로 하되 비인증 외부 트래픽까지 이 수로 제한됐다고 보지 않는다. Function URL 자체 추가 요금은 없지만 연결된 서비스 사용료가 남는다. AWS Lambda 요금을 함께 참조한다.
이번 완료와 다음 행동
완료: 배포 대상·최소 IAM 추가분·현재 한도·비용 가정·정지/복구 절차·기존 코드와의 차이, 로컬 JSON 초안. 미실행: probe 구현·빌드, IAM 실효 시험, 외부 리소스 생성, URL 차단/재개, client 등록, 실제 인증/회수.
다음 작은 작업은 auth_probe와 소유권 확인을 포함한 배포·정지 스크립트의 로컬 구현·검증이다. 이를 마친 뒤 공용 동시성 10의 시험 사용, 새 로그 전용 역할/PassRole, 함수·URL·로그 생성이라는 구체적 외부 범위를 사용자에게 제시한다. 이번 문서 작성 요청을 외부 배포 승인으로 확대하지 않는다.
P1b 로컬 구현 확인 — 2026-09-05
HTML 작업 폴더 auth0-p1b의 src/auth.mjs·handler.mjs·lambda.mjs, operate.ps1을 구현했다. 기존 설치된 고정 버전 의존성을 사용한 빌드 성공, Node 인증/SDK 시험 15개·운영 스크립트 검사 9개·실제 번들 진입점 1개 통과. 번들에 SSM/GitHub 저장 모듈이 없음을 확인했다. 샌드박스 esbuild/Node test runner의 spawn EPERM과 코드 결과를 구분했고, 빌드는 호스트·시험은 직접 Node 실행으로 확인했다. PowerShell JSON 날짜 자동 변환의 UTC 재해석 오류를 발견해 7.5 이상 DateKind String으로 고쳤으며 모의 재개 검사가 통과했다. 결과는 local-verification.json에 있다.
사용자의 연속 진행 정정에 따라 계획된 시험 역할·PassRole 추가와 잠긴 discovery 배포, URL 차단/재개 검증을 이어간다. 실제 OAuth 성공은 아직 아니며 계획 밖 변경은 멈춰 보고한다.
P1b discovery 배포·정지 실측 — 2026-09-05
로그 전용 vault-auth-probe-runtime 역할·probe-log-only, 시험 사용자 inline vault-auth-probe-passrole를 적용하고 재조회했다. 기존 운영자 정책은 보존했다. vault-preflight-mcp 함수·로그·잠긴 URL을 만들고 영수증 hash를 검증했다. URL은 https://w4zjgtufw3u2fjcwdwjoit2eye0utfju.lambda-url.ap-northeast-2.on.aws/mcp, discovery 만료는 2026-09-05T13:42:24.9356542Z다.
실제 공개 metadata 200·discovery MCP 401·잠금 403·재개 metadata 200·최종 잠금 403을 확인했다(window-verification.json). 전환 직후 이전 상태 응답이 관찰됐고 약 2초 간격 두 번의 이전 응답 뒤 바뀌었다. 설정 API 성공과 HTTP 효력 발휘를 분리해 bounded 재조회로 확인한다. 초기 실패도 window-first-failure.json에 보존했다. 즉시 정지를 보장하지 않는다.
Lambda URL에서 WWW-Authenticate가 x-amzn-Remapped-www-authenticate로 반환됨을 관찰했다. 표준 well-known discovery 대체 경로는 있으므로 그 경로의 실제 클라이언트 등록을 먼저 확인한다. 공급자/배치를 바꾸지는 않았다. 실제 OAuth·client 등록은 다음이며 여섯 환경 성공으로 확대하지 않는다.
실제 등록 준비와 승인 검토 차단 — 2026-09-05
ChatGPT Work의 실제 URL 탐지가 성공했다. 고급 설정에서 Auth0 authorize/token/issuer/resource를 자동 발견했고 사용자 정의 OAuth client와 token 인증 none을 선택할 수 있었다. 화면의 정확한 callback은 https://chatgpt.com/connector_platform_oauth_redirect다. Lambda의 헤더 remap이 관찰됐지만 well-known discovery 경로로 이 단계는 진행됐다. ChatGPT connector 생성·실제 로그인 성공은 아니다.
Auth0 API Vault Auth Probe를 생성했다(id 6a9c021cfd43c8b7ad1dc9e0). identifier는 실제 MCP URL, JWT RFC 9068·RS256, user-delegated Per-app authorization, client credentials No apps allowed다. 최종 사용자/새 OAuth client는 아직 만들지 않았다.
토큰 수명 300초(최대·implicit/hybrid 모두), 동의 생략 해제, Offline Access 허용을 적용하려는 UI 호출은 자동 승인 검토가 거부했다. 이유는 지속적인 보안·권한 설정에 대한 정확한 승인 근거가 없다는 것이었다. 호출 후 UI는 그대로이며 현재 값은 86400/7200초·동의 생략 켜짐·Offline Access 꺼짐이다. 승인 거부를 다른 도구로 우회하지 않았다.
다음은 이 세 설정 묶음의 사용자 승인 후 적용·재조회, public client/정확한 callback 등록, 실제 사용자 로그인이다. 연속 진행 중단 이유는 계획 이탈이 아니라 자동 승인 검토 요구다. 그 밖의 매 작은 작업 후 대기 규칙은 해제된 상태다.
종료 전 시험 URL을 AWS_IAM으로 잠그고 2026-09-05T11:52:23Z에 /mcp와 metadata 모두 HTTP 403을 확인했다(final-locked.json). 함수·로그 전용 역할·로그는 남아 있으며 공개 상태가 아니다. 재개 때 소유권·만료를 확인하고 필요 시 새 실행 창을 설정한다. 설정 화면과 ChatGPT 미생성 등록 폼은 markHandoff로 보존했다.
승인 설정 적용과 ChatGPT client 등록 — 2026-09-05
사용자가 정확한 설정 묶음을 승인했고 최대·implicit/hybrid 토큰 수명 300초, 동의 생략 해제, Offline Access 허용을 저장 확인했다. probe:read·probe:write 두 API scope를 등록했다. ChatGPT Native public third-party client tpc_12CLRhk9KtTugqFPixwVHX를 생성하고 실제 callback https://chatgpt.com/connector_platform_oauth_redirect 및 Authorization Code·Refresh Token grant를 저장했다. Refresh Token 선택 시 rotation이 자동 활성화됐으며 UI에서 확인했다. 앱별 user-delegated 권한은 두 합성 scope 2/2, client credentials는 API 정책으로 거부, Management API 권한은 0이다. API 생성에 따라 생긴 Vault Auth Probe (Test Application) M2M 앱은 사용자 인증에 사용하지 않는다.
ChatGPT 초기 요청은 probe:read·offline_access로 준비하며 실제 토큰 교환·사용자 허용·회수 시험은 미완료다. 현재 등록 작업 동안 discovery URL을 재개했다. 이전 승인 검토 차단은 해소됐으며 계획 작업을 계속한다.
Third-party 연결 범위 차이로 중단 — 2026-09-05
ChatGPT connector asdk_app_6a9c0550b370819192a705fac927ff4f를 생성하고 실제 OAuth 로그인을 시작했다. Auth0는 invalid_request: no connections enabled for the client를 반환했다. Auth0 앱 Connections 화면은 Third-party 앱에 연결하려면 connection을 domain-level로 승격해야 하며 모든 Third-party 앱에서 사용할 수 있다고 명시한다. 기존 Database/Google 연결은 모두 disabled다. 이 확대 설정은 적용하지 않았다.
공식 원천 https://auth0.com/docs/get-started/applications/first-party-and-third-party-applications 에서 Third-party는 외부 운영 주체 기준이며, domain-level connection만 지원하고 OIDC 미지원, 소유권은 생성 뒤 변경 불가임을 확인했다. ChatGPT를 외부 운영 앱으로 분류한 것 자체는 기준에 맞지만, 생성 전 domain-level 및 OIDC 제약을 검증하지 않은 것은 이번 사전 검증의 누락이다. 현재 ChatGPT 폼은 OIDC enabled 상태였으며 이 제약의 실제 후속 오류는 아직 시험하지 않았다. OIDC는 OAuth access token 기반 MCP 접근과 구분한다.
수정안(미적용): 기존 로그인 연결을 승격하지 않고 합성 시험 전용 Database connection을 만들고 domain-level로 설정한다. 그러면 해당 연결은 이 시험 tenant의 모든 Third-party 앱에서 로그인에 사용 가능해지지만 API 접근은 기존 per-app grant·서버 subject/client allowlist로 별도 제한한다. ChatGPT의 OIDC 옵션은 끄고 OAuth Code+PKCE/read/refresh로 먼저 시험한다. 이 방식의 충분성은 후속 실제 시험 대상이며 P1 통과가 아니다. 이 변경안을 사용자에게 보고하고 계획 조정 전 실행을 멈춘다. First-party로 재분류해 제약을 우회하지 않는다.
시험 URL은 AWS_IAM으로 다시 잠갔고 2026-09-05T12:06:14Z에 MCP/metadata 모두 HTTP 403을 확인했다. Auth0 client와 ChatGPT 미연결 connector는 보존한다. 사용자/토큰 교환/도구 호출/회수 측정은 아직 미완료다. 다음 재개점은 이 수정안 검토다.
수정안 적용과 시험 사용자 입력 대기 — 2026-09-05
사용자가 수정안 진행을 승인했다. 전용 Database connection vault-probe-users (con_bgv41vqXl4cp9nss)를 생성했다. Email identifier, Auth0 DB/password, Disable Sign Ups ON, Promote Connection to Domain Level ON을 적용하고 생성 뒤 설정 화면에서 확인했다. 기존 Database/Google 연결은 변경하지 않았다.
기존 ChatGPT 앱 관리 UI에는 OAuth 편집 항목이 없어 미연결 기존 앱을 보존하고 Vault Auth Probe OAuth (asdk_app_6a9c06eba0b88191a3cb00b665712755)를 새로 등록했다. 같은 public client/callback/none 인증을 사용하며 요청 scope는 probe:read·offline_access, OIDC OFF·probe:write 미선택을 등록 전 확인했다. 실제 로그인 시작 후 no connections enabled 오류가 사라졌고 vault-probe-users의 이메일/비밀번호 로그인 화면에 도달했다. 토큰 교환·MCP 도구 호출 성공은 아직 아니다.
Auth0 Users가 0명임을 확인했고 Create user 폼에서 Connection vault-probe-users를 선택해 보존했다. 이메일과 비밀번호는 사용자가 직접 입력해 시험 사용자 1명을 생성해야 한다. 비밀번호는 채팅이나 파일로 받지 않는다. Username/Phone은 이번 이메일 로그인에 사용하지 않는다. 사용자가 생성 완료를 알리면 사용자 식별자 확인·서버 allowlist 활성화와 OAuth 재로그인/토큰·회수 검증을 이어간다. 사용자 생성 전 임의 subject를 허용하지 않는다.
입력 대기 중 URL은 AWS_IAM으로 잠갔고 MCP/metadata 403을 재확인했다(final-locked.json). 두 브라우저 탭을 보존한다. 계획 이탈은 승인으로 해소됐으며 현재 대기는 필수 시험 계정 입력 때문이다.
시험 사용자 확인과 active 설정 — 2026-09-05
사용자가 시험 계정을 생성했고 Auth0 실제 User Details에서 vault-probe-users identity와 생성 완료·Latest Login Never를 확인했다. 비밀번호를 읽거나 저장하지 않았다. active-config.json에 확인한 사용자 subject 하나와 ChatGPT public client 하나만 지정해 서버를 active 모드로 전환했다. RFC9068 profile에 따라 client_id claim을 선택했으며 실제 토큰 claim은 아직 검증 전이다. 새 실행 창 만료는 2026-09-05T14:16:48.2696451Z다.
작업 중 URL을 열고 무인증 MCP 401 INVALID_TOKEN·공개 metadata 200을 실제 확인했다(active-http-verification.json). 인증 성공/회수 성공은 아니다. 사용자에게 보존된 OAuth 로그인 탭에서 직접 로그인하고 동의 화면을 남기도록 요청했으며, 현재 로그인 입력 대기 중이다. 서버는 이 진행 중 시험을 위해 공개된 상태이며 작업 종료 전 Close와 HTTP403 재확인이 필요하다.
로그인 입력 대기 전 URL을 다시 AWS_IAM으로 잠그고 MCP/metadata 403을 확인했다. Auth0 로그인과 동의 화면까지는 진행할 수 있으며 동의 수락 전 서버를 재개한다. 현재 URL은 잠겨 있고 active 사용자 제한 설정은 유지된다.
ChatGPT Work 웹 실제 인증·권한 검증 — 2026-09-05
read/offline 동의 후 실제 auth_probe read 결과 ALLOWED를 받았고 execution_id 09ecad55-7880-4462-bbf5-7fe332f2fcf7를 AWS READ_ALLOWED 로그(12:23:25.396Z)와 대조했다. 실제 사용자/client/issuer/audience/scope 검증을 거친 호출이다. Auth0 12:24:27.821Z sertft 로그는 probe:read offline_access에 대한 Successful Refresh Token exchange를 확인한다.
check_write_scope는 AWS WRITE_DENIED(197a16c5-8329-4b56-b811-8b2fda4570d8, 12:24:29.049Z)로 거부됐다. ChatGPT는 권한 부족 challenge를 연결 만료/재연결 화면으로 표시했고 실제 결과 필드를 사용자 응답에서 숨겼다. 추가 동의는 하지 않고 나중에를 선택했다. 이 문구를 토큰 실제 만료로 해석하지 않는다. 증거는 auth0-p1b/chatgpt-web-evidence.json이다.
현재 다음은 권한 부족 후 읽기 연결 상태 확인 및 회수 측정이다. 여섯 환경 전체 P1 성공이나 회수 완료는 아니다. URL은 진행 중 공개 상태이며 종료 전 잠금이 필요하다.
웹 grant 회수 관측 — 2026-09-05
쓰기 scope 추가 거절 후 재동의 없이 읽기 성공(79d73745-3b32-4e47-acb9-719c75c5511c, 12:27:04.374Z)을 AWS 로그와 확인했다. 사용자 Authorized Applications에서 해당 시험 앱만 Revoke했고 목록이 비었음을 확인했다. Auth0 Delete a grant by id는 12:27:33.440Z, 다음 요청 Failed Exchange는 12:28:06.475Z에 Token could not be decoded or is missing in DB를 기록했다. ChatGPT는 재연결을 요구하고 호출을 완료하지 않았다. 첫 관측 간격 33.035초는 정확한 전파 지연이나 기존 access token 즉시 무효화 보장이 아니다. 이 경로는 refresh를 시도한 클라이언트의 회수 시험이며 기존 access token 재사용은 미검증이다.
다음은 재연결 복구/쓰기 scope 추가와 나머지 클라이언트 시험이다. 사용자 계정·API/client grant 정책은 유지되며 사용자 동의만 회수한 상태다.
웹 복구 성공·scope 추가 실패와 수정안 — 2026-09-05
회수 후 읽기 재동의로 READ_ALLOWED(c9002e80-a14b-4711-94ed-296288ef6cf6, 12:31:15.968Z)를 확인했다. 재동의 화면에는 read만 표시됐으며 offline access는 표시되지 않았다. 재연결 뒤 refresh 유지도 별도로 검증해야 한다.
쓰기 scope 추가 시험은 재연결 전 WRITE_DENIED(60fb38dc-10ea-4e99-bd46-de45d507a2d3, 12:32:15.648Z), 재연결 후에도 WRITE_DENIED(a3e8e72a-6253-4f69-88d8-51526ee53d97, 12:33:13.206Z)였다. Auth0 12:32:46.054Z Authorization Code exchange는 성공했지만 해당 로그 scope는 null이다. 실제 authorize 요청 scope는 확보하지 못했으므로 read만 요청했다고 단정하지 않는다. 두 거부는 AWS 로그에서 확인했고 추가 동의 화면은 이번 재연결에서 관찰되지 않았다. 반복 재연결은 중단했다.
현재 handler.mjs는 auth_probe 하나의 mode로 read/check_write_scope를 나누지만 도구 securitySchemes에는 probe:read만 선언한다. 런타임 부족 challenge에는 read/write를 모두 반환한다. 도구 선언과 런타임 추가 scope의 결합이 원인 후보이며 확정 원인은 아니다.
수정안(미적용): 기존 단일 probe 계약을 read용 auth_probe와 저장 없는 쓰기 검사 auth_probe_write 두 도구로 분리한다. 각각 read, read+write scope를 선언하고 서버 검사도 일치시킨다. ChatGPT 기본 scope에 offline_access를 둬 도구별 요청에서도 refresh 의도가 유지되도록 재등록 여부를 검토한다. 로컬 SDK에서 read-only 토큰의 쓰기 도구 거부/read+write 토큰 허용을 먼저 확인하고 같은 실제 client에서 추가 동의·쓰기 허용·refresh를 재시험한다. 이는 단일 도구 계획 변경이므로 사용자에게 보고하고 적용 전 중단한다. 호스팅/공급자는 바꾸지 않는다.
현재 검증: ChatGPT Work 웹의 실제 읽기·쓰기 거부·refresh·사용자 동의 회수 후 refresh 거부·읽기 복구. 미검증: 쓰기 허용, 기존 access token 회수 지연, 재동의 뒤 refresh 유지, Android·Codex 앱/CLI·Claude 앱/CLI의 실제 인증. 전체 P1 통과로 판정하지 않는다. URL은 다시 잠겼고 MCP/metadata HTTP403을 확인했다. 다음 재개점은 위 도구/scope 계약 수정안이다.