메뉴

Star on GitHub · 3.2k

AI red teaming

코파일럿, 챗봇, 에이전트는 이제 비즈니스 안에서 일하는 계층이며, 많은 팀이 여전히 그것들을 평범한 앱처럼 보호합니다. 평범하지 않습니다. AI red teaming은 모델만이 아니라 AI 시스템 전체를 적대적으로 테스트해, 그것이 실제로 무엇을 하도록 몰릴 수 있는지 찾아냅니다. 그 뜻과 테스트 방법을 살펴봅니다.

무엇인가

AI red teaming은 AI 기반 시스템을 적대적으로 테스트하는 것입니다. 공격자처럼 의도적으로 조작해 무엇을 하도록 밀어붙일 수 있는지 봅니다. 중요한 단어는 시스템입니다. 표적은 언어 모델만이 아니라 그 주변 전부——검색 계층, 프롬프트 사슬, 호출할 수 있는 도구, 보유한 메모리, 그리고 행동에 쓰는 권한입니다.

무엇을 하도록 몰릴 수 있는지 본다: AI 시스템을 위한 적대적 테스트

이것은 모델이 안전하지 않은 텍스트를 내는지 묻는 모델 안전성 평가와는 다른 작업입니다. AI red teaming은 더 날카로운 질문을 던집니다. 이 실제 환경에서, 이 통합과 이 권한으로, 시스템은 조작을 통해 실제로 무엇을 하도록 만들 수 있는가?

전통적 AppSec이 모자란 이유

전통적 애플리케이션 보안은 비교적 예측 가능한 경계를 전제합니다. 입력이 들어오고, 코드가 처리하고, 출력이 나갑니다. 복잡한 소프트웨어조차 코드 리뷰, 스캔, 수동 테스트, 정책 집행 같은 익숙한 통제로 추론할 만큼은 유계였습니다.

AI 기반 앱은 그 모델을 깹니다. 이제 동작이 도구, 검색, 메모리, 위임 권한에 달려 있기 때문입니다.

  • 챗봇은 지식 베이스에서 정보를 끌어올 수 있습니다.
  • 코파일럿은 여러 내부 시스템의 데이터를 종합할 수 있습니다.
  • LLM 앱은 지시를 해석하고, API를 호출하고, 하류 워크플로를 촉발할 수 있습니다.
  • 에이전트는 메모리를 유지하고 위임된 접근으로 행동하면서 위 모든 것을 할 수 있습니다.

LLM·에이전트 앱을 위한 OWASP 목록 같은 프레임워크가 애초에 존재하는 이유가 이것입니다. 이 시스템들은 도구 오용, 신원·권한 남용, 메모리 오염 같은, 더 오래된 AppSec 사고가 온전히 담지 못하는 위험을 안습니다.

모델만이 아니다

모델이 아니라 시스템: AI red teaming은 모델을 둘러싼 스택 전체를 겨눈다

보안 리더가 가장 체화해야 할 생각. 공격자는 대개 모델을 이길 필요가 없습니다. 눈에 띄게 오작동시킬 필요조차 없을 때가 많습니다. 주변 시스템을 악용하면 됩니다——검색 계층, 프롬프트 사슬, 실행 경로, 권한 모델, 메모리, 또는 출력을 행동으로 바꾸는 애플리케이션 로직.

AI 시스템이 공격면의 일부가 되는 것은 바로 데이터·신뢰·자동화·행동의 교차점에 앉아 있기 때문입니다. 스캐너는 코드 버그를 찾을 수 있습니다. 모델 레드팀은 안전하지 않은 출력을 잡을 수 있습니다. 둘 다 공격자가 돌아가는 환경에서 처음부터 끝까지 무엇을 할 수 있는지는 말해주지 않습니다——그 틈에 진짜 노출이 삽니다.

나쁜 출력에서 나쁜 결과로

AI 위험을 “프롬프트 인젝션”으로 줄이면 일부만 잡습니다. 기업에서는 조작된 맥락이 조작된 행동으로 이어지고, 그것이 데이터 노출, 깨진 인가, 안전하지 않은 도구 사용, 워크플로 남용으로 이어집니다. 문제는 더 이상 나쁜 출력이 아니라 나쁜 결과가 됩니다.

이것들은 운영 중인 AI 시스템 전반에서 알아볼 수 있는, 되풀이되는 실패 패턴입니다.

  • 코파일럿을 겨냥한 직접 프롬프트 인젝션.
  • 시스템이 읽는 임베디드·서드파티 콘텐츠를 통한 간접 인젝션.
  • 시스템 프롬프트나 민감한 지시의 유출.
  • 공유 AI 앱의 고객 간 테넌트 교차 데이터 노출.
  • 도구 실행 사슬을 통한 권한 상승.
  • AI가 생성한 비즈니스 로직의 깨진 인가, 그리고 AI 보조 개발 중 노출된 내부 API.

이 중 어느 것도 모델이 만화적 의미로 “탈옥”될 필요가 없습니다. 새로운 표면을 걸친 평범한 보안 실패입니다.

테스트가 실제로 요구하는 것

의미 있는 AI red teaming은 지속적이며 실행 경로 전체——입력 처리, 검색, 메모리, 도구, 권한, 비즈니스 로직, 하류 워크플로——를 덮습니다. 약점이 그저 흥미로운지, 실제로 악용 가능한지를 말할 수 있는 길은 그것뿐이기 때문입니다.

즉 사슬 전체를 추적하는 것입니다. 프롬프트 조작이 행동을 바꿀 수 있는가; 바뀐 행동이 도구를 촉발할 수 있는가; 그 도구 사용이 경계를 넘는가; 그리고 결과가 진짜 비즈니스 위험을 만드는가. 이는 악용 가능성 테스트이지, 정적 분석이나 모델 평가 점수가 아닙니다. 그리고 프롬프트·모델·통합·워크플로가 매일 바뀌므로, 일회성 평가는 거의 즉시 낡습니다——테스트가 속도를 맞춰야 합니다.

던질 가치가 있는 질문

따라서 보안 리더에게 유용한 질문은 AI 시스템이 추상적으로 “안전”한가가 아닙니다. 그것은 운영적이며, 공격자가 가장 먼저 시험할 바로 그 묶음입니다.

  • 챗봇이 제한된 정보를 드러내도록 조작될 수 있는가?
  • 코파일럿이 테넌트 경계를 넘을 수 있는가?
  • 에이전트가 조직이 결코 의도하지 않은 행동으로 밀릴 수 있는가?

정직한 틀은 겸손합니다. AI는 살아 있는 운영 계층이며, 일부는 소프트웨어, 일부는 의사결정 엔진, 일부는 운영자입니다. 가장 강한 위치에 설 팀은 채택을 늦추는 팀도, “그저 또 하나의 기능”으로 취급하는 팀도 아닙니다. 그 계층을 충분히 꿰뚫어 보아 무엇을 하도록 만들 수 있는지 알고, 바뀌는 대로 지속적으로 점검하는 팀입니다.

CyberStrike는 AI로 보강된 침투 테스트 플랫폼으로, 현재 얼리 액세스 중입니다. 플랫폼의 AI red teaming 보기 또는 대기자 명단 등록.

그 뒤의 테스트 모델도?