보안 문제는 키가 어디에 저장되어 있는가보다 더 큰 문제입니다

API 키를 환경 변수(environment variable)에 넣는 것은 하나의 로컬 스크립트를 위한 합리적인 시작점입니다. 하지만 여러 에이전트, 서비스, 자동화 작업이 모두 외부 호출을 할 수 있게 되면 추론하기가 훨씬 더 어려워집니다.

그 시점에서 중요한 질문은 단지 "이 에이전트가 비밀 정보를 읽을 수 있는가?"가 아닙니다. "이 신원(identity)이 해당 키를 사용하여 어떤 아웃바운드 요청(outbound request)을 보낼 수 있는가?"입니다.

OneCLI는 그러한 설계상의 트레이드오프(trade-off)를 가시화하는 오픈 소스 프로젝트입니다. 이 프로젝트의 README는 자격 증명 게이트웨이(credential gateway)를 설명합니다. 즉, 에이전트가 플레이스홀더(placeholder) 자격 증명과 함께 요청을 보내면, 게이트웨이가 호스트 및 경로 규칙을 매칭한 후 아웃바운드 요청을 위해 실제 자격 증명을 주입(injecting)하는 방식입니다. 해당 리포지토리는 Rust 기반의 게이트웨이, 웹 대시보드, 그리고 암호화된 자격 증명 저장소를 설명하고 있습니다.

저는 OneCLI를 테스트하거나 실행해 보지 않았습니다. 이것은 공개 리포지토리와 문서를 읽고 분석한 내용이며, 보안 평가나 배포 권장 사항이 아닙니다.

게이트웨이가 개선할 수 있는 점

일반적인 자격 증명 배포 모델은 간단합니다. 각 에이전트에게 .env, 설정 파일, 또는 호스팅된 비밀 관리자(secret manager)를 통해 비밀 정보를 제공하는 것입니다. 이 방식도 작동할 수 있지만, 에이전트의 수가 증가함에 따라 권한 취소(revocation), 순환(rotation), 그리고 감사(audit)가 점점 더 파편화됩니다.

게이트웨이는 요청 경로(request path)에 정책 지점(policy point)을 생성합니다. 원칙적으로, 이는 팀에게 다음과 같은 사항을 결정할 수 있는 단일 지점을 제공합니다:

• 어떤 에이전트 신원이 어떤 외부 목적지로 호출할 수 있는지
• 자격 증명이 어떻게 선택되고 순환되는지
• 무엇이 로그에 기록되고 무엇이 마스킹(redacted)되는지
• 에이전트나 작업이 변경될 때 액세스 권한을 어떻게 취소할지

그렇기 때문에 흥미로운 부분은 단순히 모델 컨텍스트(model context)로부터 원시 키(raw key)를 숨기는 것이 아닙니다. 아웃바운드 권한(outbound authority)을 명시적으로 만드는 것입니다.

새로운 경계 또한 검토가 필요합니다

자격 증명 주입(credential injection)을 프록시(proxy)로 옮기는 것이 신뢰를 제거하는 것은 아닙니다. 오히려 신뢰를 집중시키는 것입니다. 프록시, 프록시의 규칙 엔진(rule engine), 로그, 그리고 액세스 토큰(access tokens) 자체가 보안상 매우 중요한 요소가 됩니다.

이러한 범주의 시스템을 도입하기 전에, 저는 호스트/경로 매칭(host/path matching) 동작, 리다이렉트 처리(redirect handling), 토큰 범위(token scope), 로그 비식별화(log redaction), 네트워크 격리(network isolation), 그리고 복호화된 값의 생명주기(lifecycle)를 검토할 것입니다. OneCLI의 vault integration documentation에는 Bitwarden 폴백(fallback)과 60초간의 인메모리 캐시(in-memory cache)에 대해 설명되어 있습니다. 이는 문서화된 프로젝트의 주장이며, 제가 독립적으로 검증한 것은 아닙니다.

누가 관심을 가져야 하는가

많은 서드파티 API(third-party APIs)를 호출하는 여러 에이전트를 운영하는 팀은 외부 호출을 정책 제어 가능한 기능(policy-controlled capabilities)으로 취급함으로써 이득을 얻을 수 있습니다. 단일 로컬 스크립트로는 불가능할 수 있습니다. 게이트웨이(gateway)를 추가하는 것은 보안을 유지하고 운영해야 할 또 다른 구성 요소를 도입하는 것을 의미합니다.

이 프로젝트는 Apache-2.0 라이선스를 따르며, gateway source tree는 소스 코드 검토를 시작하기에 합리적인 장소입니다. README에서 제공한다고 해서 단순히 퀵스타트(quick-start)나 설치 명령어를 실행하지 마십시오. 먼저 귀하의 환경에 맞는 배포 방식과 위협 모델(threat model)을 검증하십시오.