LLM 애플리케이션을 배송하는 것은 실패 모드가 예외나 스택 추적이 아니라 출력인 시스템을 배송하는 것을 의미합니다 — 시스템 프롬프트를 누출하는 챗봇, 하지 말아야 할 도구를 호출하도록 주장받을 수 있는 에이전트, 환불 정책을 자신 있게 발명하는 지원 어시스턴트. 이들 중 어느 것도 오류를 던지지 않습니다. 함수가 예상 값을 반환하는 것을 주장하는 전통적인 테스팅은 대부분을 표현할 수 없습니다. 그 격차를 채우도록 등장한 규율은 LLM 레드팀입니다: 의도적으로 자신의 모델과 애플리케이션을 공격하여 누군가 다른 사람이 먼저 찾기 전에 허용 불가능한 동작을 생성하는 입력을 찾습니다.
2026년까지 이것은 임의의 프롬프트 실험에서 서로 다른 계층을 가진 도구 환경으로 성숙했습니다. 이 가이드는 그 환경을 매핑합니다 — 모델 계층의 garak과 PyRIT, 애플리케이션 계층의 DeepTeam과 promptfoo, 블랙박스 엔드포인트 퍼징을 위한 Agentic Security, 그리고 스캔 및 엄격한 평가를 위한 Giskard와 Inspect. 관통하는 선은 이 도구들이 경쟁자가 아니라는 것입니다: 그들은 다른 클래스의 실패를 포착하고, 하나만 실행하면 예측 가능한 격차를 남깁니다.
실제로 테스트하는 것
도구 전에, 실패 클래스를 명명하는 것이 도움이 되므로 다른 테스트를 요구합니다. 탈옥과 프롬프트 주입은 헤드라인입니다: 모델을 직접 조작으로 그것의 명령을 무시하도록 얻기 ("이전 명령 무시") 또는 간접적으로 그것이 검색하는 콘텐츠를 통해 — 모델이 따르는 명령을 전달하는 오염된 문서. 간접 주입은 RAG 및 에이전트 시스템에서 더 심각한 변형인데, 공격자는 프롬프트 박스를 절대 건드리지 않기 때문입니다.
데이터 누출은 시스템 프롬프트 추출, 모델이 컨텍스트에서 본 PII, 또는 훈련 데이터를 다룹니다. 과도한 에이전시는 에이전트가 도구를 얻을수록 가장 위험해지는 실패 클래스입니다: 모델이 거부했어야 할 조치를 취하거나, 의도된 권한을 초과하는 방식으로 도구를 연쇄. 해로운 콘텐츠는 애플리케이션이 거부해야 할 요청을 순진하게 준수합니다. 그리고 환각 — 자신 있는 제조 — 은 종종 가장 높은 빈도 비즈니스 위험이지만 가장 극적이지는 않습니다.
각각은 다른 계층에 살고 있습니다. 탈옥 취약성은 주로 모델의 성질입니다. 과도한 에이전시와 프롬프트 누출은 애플리케이션의 성질입니다 — 그것의 시스템 프롬프트, 그것의 도구, 그것의 가드레일. 환각은 파이프라인의 성질인데, 특히 검색 품질입니다. 이 계층화는 정확히 도구들이 분할되는 방식입니다.
모델 계층 스캐너: garak과 PyRIT
garak (NVIDIA)는 LLM을 위한 nmap과 가장 가깝습니다. 이것은 모델에 대해 조사의 큰 라이브러리를 실행합니다 — 탈옥 가족, 프롬프트 주입, 독성, 데이터 누출, 인코딩 공격 — 그리고 어떤 것이 성공했는지 보고합니다. 모델을 지정합니다 (HuggingFace 모델, OpenAI 엔드포인트, 로컬 서버) 그리고 그것은 카탈로그를 통해 작동합니다. 그것의 가치는 너비와 낮은 노력입니다: 당신은 당신의 모델이 어떤 알려진 공격 가족에 취약한지 빠르게 배웁니다, 아무것도 자신이 설계하지 않고.
PyRIT (Microsoft)는 더 어려운 문제를 대상으로 합니다: 다중 턴 및 다중 모달 공격. 많은 실제 탈옥은 단일 메시지에서 작동하지 않습니다; 그들은 몇 턴에 걸쳐 문맥을 설정하고 점진적으로 에스컬레이션함으로써 작동합니다. PyRIT는 그것을 위한 오케스트레이션을 제공합니다 — 크레센도 (느린 에스컬레이션)과 TAP (공격의 트리 가지치기 포함)와 같은 공격 전략이 모델의 응답에 기반하여 적응합니다. 스캐너보다는 SDK입니다: 오케스트레이터, 대상, 변환기, 스코어러를 구성합니다. 이것은 시작하는 데 더 많은 일을 만들고 단일 샷 프로브가 찾을 수 없는 공격에 대한 연구에 더 강력합니다.
공유 제한은 둘 다 주로 모델, 당신의 애플리케이션을 테스트한다는 것입니다. garak의 프로브에 저항하는 모델이 당신의 앱 내에서 여전히 쉽게 손상될 수 있습니다, 당신의 시스템 프롬프트, 당신의 검색, 당신의 도구가 모델 계층 스캔이 절대 본 공격 표면을 생성하기 때문입니다.
애플리케이션 계층 스위트: DeepTeam과 promptfoo
이것이 DeepTeam과 promptfoo가 맞는 곳입니다. 둘 다 배포된 대로 당신의 애플리케이션을 테스트하고, 당신의 앱이 실제로 무엇인지를 래핑합니다 — 프롬프트, 검색, 도구, 가드레일 — 그리고 전체 조립을 공격합니다.
DeepTeam은 DeepEval 팀에서 python으로 레드팀을 표현합니다: 당신은 model_callback을 제공하는데 당신의 앱을 호출하고, 조사할 취약점 (PII 누출, 과도한 에이전시, 편향, 프롬프트 누출)과 사용할 공격을 선언하고, 그것은 적대적 케이스를 생성하고 실행합니다. 그것의 공격 향상이 흥미로운 부분입니다 — base64, 다른 언어로, 역할극으로, 또는 턴 전체에 에스컬레이션으로 다시 작성된 동일한 기본 공격, 실제 공격자가 순진한 필터를 회피하는 방법입니다. 코드이기 때문에, 테스트 스위트에 떨어지고 CI에서 실행됩니다.
promptfoo는 평가에서 이를 처리합니다: LLM 출력을 테스트하기 위한 구성 기반 CLI로, 실질적인 레드팀 기능으로 성장했는데, 수십 개의 공격 플러그인에 걸쳐 자동으로 적대적 프롬프트를 생성하고 발견을 준수 프레임워크로 매핑합니다. 그것의 강점은 CI 통합이고 동일한 도구가 품질 평가와 보안 테스트를 모두 다루므로, 하나의 하네스가 두 목적을 모두 제공합니다.
대부분의 LLM 제품을 배송하는 팀의 경우, 이 계층이 모델 계층보다 더 중요합니다, 당신이 실제로 배포한 것을 테스트하기 때문입니다. 그 캐치는 그것이 당신이 당신의 애플리케이션을 위해 "허용 불가능"이 무엇인지를 정의하는 것을 필요로 한다는 것입니다 — 도구는 공격을 생성합니다, 하지만 당신은 어떤 출력이 실패인지에 대한 판단을 제공합니다.
블랙박스 및 스캔 접근 방식
두 가지 다른 모양을 알 가치가 있습니다. Agentic Security는 당신의 엔드포인트를 블랙박스로 취급하고 그것을 에이전틱하게 퍼징합니다 — 조사를 생성하고, 응답을 관찰하고, 적응합니다 — API 스트레스 테스팅의 유용한 추가 기능과 함께. 마지막 부분은 과소평가됩니다: 의미 있는 LLM 배포 공유가 콘텐츠 안전보다 먼저 속도 제한, 토큰 소진, 리소스 남용에서 실패합니다, 그리고 대부분의 레드팀 도구는 그것을 완전히 무시합니다.
Giskard는 일반적인 워크플로를 반전합니다. 테스트할 것을 지정하도록 요구하는 대신, 그것은 모델을 스캔합니다 — 앱이 하는 것에 대한 당신의 설명을 사용하여 도메인 관련 조사를 생성합니다 — 그리고 감지된 취약점의 보고서를 생성합니다, 그것을 재사용 가능한 테스트 스위트로 변환할 수 있습니다. 그 스캔-증명 패턴은 특히 정확히 레드팀의 가장 어려운 부분이 무엇을 찾을지를 아는 것이기 때문에 가치가 있습니다. Giskard는 당신이 테스트하기를 생각하지 못한 문제를 찾습니다, 그 다음 회귀 테스트로 잠금합니다.
마지막으로, 영국 AI 안전 연구소의 Inspect는 약간 떨어져 앉습니다: 공격 도구보다 엄격한 평가 프레임워크이지만, 그것의 구조 (데이터세트, 솔버, 채점기)와 우수한 대사록 뷰어가 그것을 당신이 에이전틱 동작을 포함한 취약점 목록이 아니라 취약점 목록이 아니라 취약점 목록이 필요할 때의 옳은 선택으로 만듭니다.
계층화된 관행 구축
실질적인 결론은 이 도구들이 합성된다는 것입니다. 합리적인 2026 관행은 이렇게 보입니다.
기본 모델을 선택하거나 업그레이드할 때, 모델 계층 스캐너를 실행합니다 — 너비를 위한 garak, 다중 턴 강건성이 당신의 위험 프로필에 중요한 경우 PyRIT. 이것은 모델 선택을 알리고 기초가 자신의 것에 저항하는 것을 말해줍니다.
개발 중, Giskard 같은 스캔 스타일 도구를 당신의 실제 애플리케이션에 대해 실행하여 당신이 예상하지 못한 실패 클래스를 발견하고, 그것의 발견을 테스트로 변환합니다.
CI에서, 모든 프롬프트, 모델 또는 도구 변경 시, 애플리케이션 계층 스위트를 실행합니다 — DeepTeam 또는 promptfoo — 게이트로 합니다. 이것이 최고값 자동화입니다, 프롬프트와 도구 정의가 LLM 앱의 제어 표면이고 그들이 지속적으로 변경하기 때문입니다. 무해해 보이는 프롬프트 편집이 탈옥을 방지하던 문장을 제거할 수 있습니다.
릴리스 전, 배포된 엔드포인트에 대한 블랙박스 퍼징을 추가하여, 스트레스 테스팅을 포함하여, 코드 레벨 테스트가 놓치는 배포 레벨 문제를 포착합니다.
그리고 인간을 계속 관여시키세요. 모든 자동화된 도구는 알려진 공격 가족을 테스트합니다. 새로운 공격 — 당신의 도메인, 당신의 데이터, 당신의 도구에 고유한 것들 — 비즈니스 논리를 대적으로 생각하는 사람에게서 옵니다. 자동화는 바닥을 올리고; 그것은 천장을 대체하지 않습니다.
간접 주입: 모델을 깨뜨리는 공격
한 공격 클래스는 별도의 취급을 받을 자격이 있는데 대부분의 팀이 시작하는 직관을 물리치기 때문입니다. 직접 프롬프트 주입 — 사용자가 입력하는 "명령 무시" — 은 모두 먼저 테스트하고, 더 쉬운 절반입니다. 간접 프롬프트 주입은 악의적인 명령이 시스템이 검색하는 콘텐츠를 통해 도착할 때입니다: 지식 기반의 문서, 에이전트가 검색하는 웹 페이지, 요약하는 이메일, 읽는 코드 주석. 공격자는 프롬프트 박스와 상호작용하지 않습니다.
RAG 시스템 및 에이전트를 위해 이것이 엄청나게 중요합니다, 그들의 전체 가치 제안이 외부 콘텐츠를 소비하기 때문입니다. 문서에 포함된 지침을 충실히 따르는 지원 어시스턴트는 공개 wiki, 고객 제출 티켓, 또는 스크랩된 페이지를 통해 누군가 문서를 코퍼스에 얻을 수 있으면 지침을 따릅니다. GitHub 이슈를 읽는 에이전트는 그 이슈에 의해 명령받을 수 있습니다. 사람들이 상상하는 신뢰 경계 ("사용자는 신뢰할 수 없음, 우리 데이터는 신뢰할 수 있음")는 코퍼스의 어느 부분이 영향을 받을 수 있으면 유지되지 않습니다.
이것을 테스트하는 것은 직접 주입을 테스트하는 것보다 더 어렵습니다, 그것이 오염된 프롬프트 아닌 오염된 콘텐츠를 시뮬레이트하는 것을 필요로 합니다 — 검색이 그것을 찾을 곳에 적대적 텍스트를 배치하고 모델이 그것에 대해 작용하지 않는지 검증합니다. 애플리케이션 계층 도구는 이것을 모델 계층 스캐너보다 더 잘 처리합니다, 검색 파이프라인이 그들이 행사하는 것의 일부이기 때문에, 하지만 종종 시나리오를 의도적으로 구성할 것을 필요로 합니다.
완화는 프롬프트 기반이 아니라 구조 기반입니다. 검색된 모든 콘텐츠를 신뢰할 수 없는 입력으로 취급하세요, 사용자 입력을 취급하는 것과 같은 방식으로. 검색된 텍스트가 당신이 구조적으로 피할 수 있으면 명령으로 해석되는 위치에 도달하지 않도록 하세요. 신뢰할 수 없는 콘텐츠를 처리하는 동안 에이전트가 호출할 수 있는 도구를 제약하고, 결과적인 조치에 대한 확인을 요구합니다. 그리고 출처를 유지합니다: 어느 문서가 나쁜 답변을 생성했는지 아는 것이 인시던트를 수정으로 바꿉니다.
레드팀이 수정하지 않는 것
명백히 명시할 가치가 있는 주의: 취약점을 찾는 것이 수정하는 것과 같지 않고, LLM 취약점은 종종 완전히 수정 불가능합니다. 버퍼 오버플로우처럼 모델을 패치할 수 없습니다. 현실적인 응답은 완화 오히려 제거: 더 타이트한 시스템 프롬프트, LLM Guard 같은 입력 및 출력 가드레일, 제약된 도구 권한, 결과적인 조치에 대한 인간 승인, 그리고 이상 행동에 대한 모니터링.
이것은 레드팀 보고서가 의미하는 것을 변경합니다. 전통 보안에서, 발견은 수정을 암시합니다. LLM 보안에서, 발견은 종종 위험 결정을 암시합니다: 이 공격은 어떤 속도로 성공합니다, 여기에 완화가 있고, 여기에 잔여 위험이 있습니다, 이것이 이 사용 케이스에 허용됩니까? 레드팀 보고서가 깨끗한 청구 건강을 생성하기를 예상하는 팀은 영구적으로 실망할 것입니다. 위험을 정량화하고 의식적으로 받아들이는 팀은 실제 가치를 얻습니다.
결론은 건축이 프롬프트 엔지니어링을 이기는 것입니다 대부분의 실패를 위해. 돈을 이체하도록 속을 수 없는 에이전트는 구조적으로 해당 권한을 부족하기 때문에 그렇게 하도록 유도를 거부할 수 있는 것보다 더 안전합니다. 과도한 에이전시는 적게 하는 에이전시를 주는 것이 최고입니다. 레드팀의 가장 유용한 출력은 자주 기능이 첫 자리에 노출되어야 했던 것이 아니었다는 실현입니다.
결론
LLM 레드팀은 LLM 실패가 오류보다 출력이고, 평범한 테스팅이 그들을 표현할 수 없기 때문에 실제 규율이 되었습니다. 2026 도구는 계층별로 분할되고, 그 분할이 잘 사용하기 위한 핵심입니다: garak과 PyRIT는 모델을 조사합니다, DeepTeam과 promptfoo는 당신이 실제로 배포한 애플리케이션을 공격합니다, Agentic Security는 리소스 제한을 포함한 엔드포인트를 퍼징하고, Giskard는 당신이 찾을 줄을 모르는 문제를 발견합니다. 하나 이상을 실행하세요, 프롬프트가 가장 많이 변경되는 애플리케이션 계층에서 CI를 게이팅하세요, 루프에 인간 대적 생각을 유지하세요, 수정 대기 버그 보다는 위험 결정으로 발견을 취급하세요 — 그 다음 프롬프트가 아니라 구조에서 수정할 수 있는 것을 수정하세요.
참고 및 리소스
도구
배경 및 분석
- Best LLM Vulnerability Scanners 2026: Garak, PyRIT, Promptfoo
- LLM Red Teaming Guide 2026: Tools, Attacks & Methodology — AppSec Santa
- LLM Red Teaming Tools Compared — QAwerk
- awesome-ai-security-tools
관련 1337skills 치트시트