Braintrust 침해 사고, AI 평가 스택의 키 관리 경고

평가 플랫폼도 공격 표면이 됐다

TechCrunch는 5월 6일 Braintrust가 고객에게 민감 키 교체를 요청했다고 보도했다. 보도에 따르면 Braintrust는 한 AWS 클라우드 계정에서 “unauthorized access”가 있었고, 그 계정에는 고객이 클라우드 기반 AI 모델에 접근하기 위해 저장한 API 키가 포함돼 있었다고 고객 이메일에서 설명했다. 회사는 한 고객에게 영향을 확인했으며 더 넓은 노출 증거는 찾지 못했다고 밝혔다.

Braintrust는 AI 소프트웨어를 만드는 엔지니어를 위한 운영체제를 표방하는 평가·관측 플랫폼이다. 이런 도구는 프롬프트, 평가 데이터셋, 실행 로그, 모델 API 키를 함께 다룬다. 따라서 보안 관점에서는 단순 SaaS 부가 도구가 아니라 LLMOps의 권한 허브다. Ramp Sheets 프롬프트 인젝션처럼 업무 데이터가 AI 도구에 연결될수록 보안 경계는 애플리케이션 바깥으로 넓어진다.

“키를 돌려라”는 말의 실제 비용

API 키 회전은 문서상 간단해 보이지만 실제 운영에서는 비용이 크다. 키가 여러 CI/CD 파이프라인, 실험 노트북, 평가 작업, 서버리스 함수, 로컬 개발 환경에 복제되어 있으면 누락이 생긴다. 한 번의 침해가 고객 전체에 “모든 키를 교체하라”는 요청으로 번지는 이유다. AWS IAM 보안 모범 사례는 장기 자격 증명 최소화와 권한 분리를 강조한다.

Braintrust는 침해 계정을 잠그고 관련 시스템 접근을 감사·제한했으며 내부 비밀도 회전했다고 밝혔다. 그러나 고객 입장에서는 “내 키가 실제로 쓰였는가”보다 “그 키로 무엇을 할 수 있었는가”가 더 중요하다. OpenAI, Anthropic, Google, Azure 같은 모델 키는 비용 청구, 데이터 접근, 로그 조회와 연결될 수 있다. OWASP LLM Top 10의 공급망·과도한 권한 리스크가 그대로 적용된다.

LLMOps 구매 기준이 바뀐다

지금까지 AI 평가 도구의 구매 기준은 정확도, 대시보드, 실험 관리, 비용 추적이었다. 이제는 SOC 2, 침해 알림 SLA, 키 암호화 방식, 고객 관리형 키, 리전 선택, 감사 로그 내보내기, 세분화된 권한이 같은 수준으로 중요해진다. Claude 에이전트 악성코드 거부 회귀에서 보듯 AI 안전은 모델 행동만이 아니라 운영 체계 문제다.

한국 기업은 특히 외부 LLMOps 도구에 원본 고객 데이터와 프로덕션 키를 동시에 넣지 않는 원칙을 세워야 한다. 평가용 키는 별도 프로젝트로 만들고, 월간 지출 한도를 낮추며, 데이터셋은 최소 샘플과 마스킹된 형태로 운영하는 것이 안전하다. NIST Cybersecurity Framework는 식별, 보호, 탐지, 대응, 복구의 관점에서 이런 프로세스를 점검하는 기준으로 쓸 수 있다.

FAQ

Q1. Braintrust 사고에서 확인된 사실은 무엇인가?
TechCrunch 보도 기준으로 Braintrust는 한 AWS 계정의 무단 접근을 확인했고, 고객에게 저장된 API 키를 교체하라고 요청했다.

Q2. 모든 고객 키가 유출됐다는 뜻인가?
회사는 한 고객 영향과 더 넓은 노출 증거가 없다고 밝혔다. 다만 예방 차원에서 모든 고객에게 키 회전을 요청했다.

Q3. AI 평가 도구에 키를 저장해도 되나?
필요할 수 있지만 프로덕션 키와 분리해야 한다. 평가 전용 키, 최소 권한, 지출 한도, 정기 회전이 기본이다.

Q4. 국내 팀의 즉시 조치는?
모델 API 키 위치를 inventory로 만들고, 외부 SaaS에 저장된 키를 프로젝트별로 분리하며, 사고 알림과 회전 절차를 문서화해야 한다.