AI 평가·관측 도구에 맡긴 모델 API 키가 유출된다면, 우리 팀은 그 키로 무엇이 호출되고, 얼마가 과금되고, 어떤 프롬프트와 로그가 노출될 수 있는지 즉시 말할 수 있을까요?
Braintrust 사례는 이 질문을 현실로 끌어냈습니다. Braintrust는 자사 AWS 계정 중 하나에서 무단 접근이 확인됐고, 고객이 저장한 클라우드 AI 모델용 API 키가 포함돼 있었다며 고객들에게 Braintrust에 저장한 API 키를 교체하라고 안내했습니다.1 회사는 사고가 통제됐고 관련 접근 제한과 내부 비밀값 교체를 진행했다고 밝혔지만, 원인은 아직 조사 중입니다.2
AI 평가 도구의 키는 단순한 SaaS 토큰이 아니다
일반적인 SaaS 연동 키는 특정 서비스 안의 데이터에 접근합니다. 하지만 AI 평가, 프롬프트 테스트, 관측성 도구에 들어가는 키는 성격이 다릅니다.
이 키는 OpenAI, Anthropic, Azure OpenAI, AWS Bedrock 같은 모델 제공자와 연결될 수 있고, 경우에 따라 평가 데이터셋, 프롬프트, 체인 실행 로그, 프로덕션 트레이스까지 함께 엮입니다. 즉 "도구 하나의 키"가 아니라 모델 사용권, 비용 계정, 제품 동작 기록으로 이어지는 공급망 비밀값일 수 있습니다.
Braintrust는 AI 모델과 제품을 모니터링하는 플랫폼으로 설명돼 왔고, 고객이 저장한 AI 모델 접근용 API 키가 문제의 AWS 환경에 있었다는 점이 핵심입니다.1 여기서 중요한 것은 Braintrust만의 문제가 아니라, AI 인프라 도구들이 점점 "개발 워크플로의 허브"가 되고 있다는 구조입니다.
실무적으로는 키를 이름이 아니라 폭발 반경으로 분류해야 합니다. "eval-prod-openai-key"가 실제 프로덕션 모델 호출, 민감한 고객 입력, 높은 월 예산과 연결돼 있다면, 그것은 슬랙 봇 토큰보다 훨씬 높은 등급의 비밀값입니다.
30분 안에 해야 할 노출 범위 점검
이런 사고가 발생하면 "모든 키를 즉시 교체"가 정답처럼 보입니다. 하지만 순서 없이 교체하면 운영 장애가 생기고, 정작 중요한 증거 확인을 놓칠 수 있습니다.
먼저 Braintrust 같은 외부 도구에 어떤 키를 저장했는지 목록화해야 합니다. 모델 제공자별 키, AWS·Azure 권한, 내부 프록시 토큰, 데이터셋 접근 토큰을 분리해 봐야 합니다.
그다음 확인할 것은 세 가지입니다.
해당 키가 호출만 가능한지, 모델·파일·로그 조회나 관리자 기능까지 가능한지
사고 추정 시점 전후로 사용량, 과금, 호출 지역, 모델 종류에 이상이 있는지
평가 로그나 프롬프트 안에 고객 데이터, 내부 코드, 시스템 프롬프트, 인증 정보가 섞여 있는지
Braintrust는 고객 한 곳과 소통했으며 현재까지 더 넓은 노출 증거는 발견하지 못했다고 설명했지만, 동시에 모든 고객에게 저장된 키 교체를 권고했습니다.1 이 조합은 보안 사고에서 흔히 보이는 신호입니다. "확인된 피해 범위"와 "안전하게 가정해야 할 위험 범위"는 다릅니다.
교체 순서는 프로덕션 고권한 키, 높은 예산 한도의 키, 민감 데이터가 포함된 로그와 연결된 키부터가 합리적입니다. 개발·테스트 키라도 동일 조직 계정의 관리자 권한을 공유한다면 우선순위를 올려야 합니다.
다음 사고를 지루하게 만드는 설계
가장 좋은 사고 대응은 빠른 회전이 아니라, 회전해야 할 키의 피해 범위를 작게 만들어두는 것입니다.
AI 스택에서는 최소한 다음 원칙이 필요합니다. 벤더별로 키를 분리하고, 개발·평가·프로덕션 키를 나누며, 각 키에 예산 한도와 모델 allowlist를 설정합니다. 가능하다면 외부 도구가 원본 모델 키를 직접 보관하지 않고, 고객이 통제하는 프록시나 게이트웨이를 거치게 해야 합니다.
이 방식에는 트레이드오프가 있습니다. 프록시를 두면 지연시간과 운영 복잡도가 늘고, 벤더 기능 일부가 제한될 수 있습니다. 하지만 대가로 얻는 것은 큽니다. 특정 AI 도구가 침해돼도 공격자는 모든 모델, 모든 데이터, 모든 예산에 접근하지 못합니다.
CircleCI도 2023년 클라우드 침해 이후 고객에게 저장된 "모든 비밀값" 교체를 요청한 바 있습니다.1 개발 도구와 AI 도구의 공통점은 분명합니다. 이들은 편의성을 위해 많은 비밀값을 모으고, 그래서 공격자에게 매력적인 지점이 됩니다.
이제 물어야 할 질문은 "키를 저장하나요?"가 아니다
벤더 보안 검토에서 "API 키를 저장하나요?"만 묻는 시대는 지났습니다. 더 날카로운 질문이 필요합니다.
키는 어떤 방식으로 암호화되는가. 복호화된 키에 접근할 수 있는 사람과 시스템은 무엇인가. 고객 관리형 키, 전용 테넌트, 감사 로그를 지원하는가. 사고 발생 시 고객에게 몇 시간 안에 알리는가. 프롬프트와 평가 로그는 키와 분리돼 저장되는가. 고객이 통제하는 프록시를 통해 제품을 쓸 수 있는가.
Braintrust 사건에서 아직 단정할 수 없는 부분은 많습니다. 실제로 얼마나 많은 고객 키가 노출됐는지, 공격자가 키를 사용했는지, 어떤 경로로 AWS 계정 접근이 가능했는지는 공개 정보만으로 확정할 수 없습니다. 하지만 실무적 결론은 이미 충분히 분명합니다.
AI 평가·관측·프롬프트 관리 도구를 쓰는 팀이라면 지금 키 인벤토리부터 확인해야 합니다. 특히 프로덕션 모델 키를 외부 도구에 그대로 넣고 있다면, 그것은 통합 편의성이 아니라 공급망 리스크입니다. 앞으로 AI 벤더를 고를 때의 기준은 기능 데모가 아니라 "이 도구 하나가 뚫려도 우리 시스템 전체가 열리지 않는가"여야 합니다.
참고
1AI evaluation startup Braintrust confirms breach, tells every customer to rotate sensitive keys
2Braintrust warns customers to rotate API keys after AWS breach
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.