결론적으로 말하자면, 저는 AI에게 이 문제에 대한 최적의 해결책을 물어볼 것입니다. Gemini가 제시한 답변은 다음과 같습니다:
이 인터뷰 질문에서 승리하려면, 실행 환경이 원본 자격 증명(raw credentials)에 접근해서는 안 된다는 전제 자체에 의문을 제기해야 합니다. 면접관은 환경 변수(environment variables), 로컬 파일, 그리고 컨테이너 수준의 비밀 정보가 모두 임의 코드 실행(arbitrary code execution), 메모리 검사(memory inspection), 또는 환경 덤핑(os.environ)에 취약하다는 것을 입증했습니다.
제시할 정확한 아키텍처적 답변은 다음과 같습니다:
직접적인 제안 (The Direct Pitch)
"에이전트에게 열쇠를 주지 말고, 중개자(broker)를 주세요." 만약 생성된 코드가 컨테이너 내부에서 실행된다면, 그 컨테이너는 신뢰할 수 없는 경계(untrusted perimeter)입니다. 유일하게 누출이 없는 설계 방식은 Sidecar/Gateway 토큰 교환 패턴(Sidecar / Gateway Token-Exchange Pattern)이며, 이 패턴에서는 자격 증명이 프로세스 경계를 넘어 에이전트의 실행 샌드박스로 절대 이동하지 않아야 합니다.
핵심 아키텍처: 위임 프록시 패턴 (Delegated Proxy Pattern)
런타임 컨테이너에 API 토큰을 주입하는 대신, 의도(intent)와 인증(authentication)을 분리해야 합니다:
Egress Gateway / Sidecar Proxy:
The untrusted agent container는 네트워크 샌드박스 내에서 실행되어야 하며, 이 환경에서는 직접적인 아웃바운드 인터넷 접근이 제한되거나 로컬 프록시 사이드카(sidecar) 또는 호스트 게이트웨이를 통해 라우팅되어야 합니다. 에이전트는 오직 일시적이고 내부 범위로 한정된 ID 토큰(예: 단기 생존 SPIFFE/SPIRE JWT, 상호 TLS 인증서(mutual TLS cert), 또는 제한된 내부 세션 토큰)만을 보유해야 합니다.
정책 강제 리버스 프록시 (Policy-Enforcing Reverse Proxy):
에이전트가 GitHub나 Slack과 같은 외부 서비스와 상호 작용하려 할 때, 이는 http://api-proxy/github/...로 요청을 보내거나 고수준의 내부 도구 API를 호출해야 합니다. 이 프록시는 요청을 검사하고, 에이전트의 세션이 해당 정확한 작업을 수행하도록 허가되었는지 검증하며, 실제 상위(upstream) 인증 헤더(Authorization: Bearer <실제_slack_토큰>)를 주입한 후 요청을 중계합니다. 응답은 프록시를 거쳐 돌아오면서 접근 토큰, set-cookie 데이터 또는 비밀 메타데이터가 포함된 헤더는 샌드박스로 전달되기 전에 제거되어야 합니다.
Fine-Grained Capability Scoping (최소 권한 원칙):
게이트웨이 레벨에서도 정적이고 광범위한 개인 액세스 토큰을 사용하지 마십시오.
임시 설치 토큰을 사용하는 GitHub Apps와 특정 리포지토리, 채널 또는 라이프사이클 이벤트에 바인딩된 Slack의 세분화된 OAuth 스코프를 사용하고, 필요할 때만 발급(just-in-time)하며 몇 분 안에 만료되도록 하십시오.
심층 방어 (Defense-in-Depth) 조치
- 샌드박스 내 도구 호출 (원시 셸 대신 RPC 사용): 가능한 경우, 에이전트가 원시
curl 명령어 또는 HTTP 요청을 작성하는 것을 피해야 합니다. 컨테이너 외부에 호스팅되는 gRPC/IPC(예: Model Context Protocol / MCP 서버)를 통해 미리 정의된 SDK 인터페이스를 노출하십시오. 에이전트는 오직 post_slack_message(channel, text)만 호출하고 네트워크 구성이나 헤더에는 절대 접근해서는 안 됩니다.
- 이그레스 필터링 (Egress Filtering): 샌드박스 컨테이너에서 외부 제공업체 도메인(https://t.co/eK8CLCb400, https://t.co/V1mtgwnFu3)으로의 직접적인 DNS/IP 라우팅을 차단하고, 모든 트래픽이 인증된 프록시를 통과하도록 강제합니다.
- 응답 마스킹 (Response Redaction): 상위 API가 실수로 에러 추적에 자격 증명을 반사할 경우, 알려진 API 키 형식(예: ghp_* 또는 xoxb-*)을 감지하고 마스킹하기 위해 프록시 페이로드에 이그레스/인그레스 DLP(Data Loss Prevention) 스캐너를 배치하십시오.
요약 및 핵심 시사점 (Summary Takeaway)
에이전트 런타임을 신뢰할 수 없는 다중 테넌트 샌드박스처럼 취급해야 합니다. 자격 증명이 컨테이너 환경, 메모리 또는 디스크에 들어오는 순간, 이는 손상된 것입니다. 인증을 프로세스 외부의 브로커링 프록시(out-of-process brokered proxy)로 이동시키는 것이, 취약한 코드 레벨 방어에 의존하기보다 네트워크 계층에서 유출 문제를 해결합니다.