공격자가 내 챗봇에게 무엇을 시킬 수 있는지 확인해 보세요.

공격자의 텍스트가 봇의 규칙을 덮어씁니다: “네 지시를 무시하고…”.

봇이 API 키, 내부 식별 코드, 또는 다른 고객의 데이터를 드러냅니다.

숨겨둔 지시문이 그대로 유출됩니다: 이후 모든 공격을 위한 지도입니다.

한 턴에 심어둔 규칙이 이후의 모든 답변을 조용히 바꿉니다. 대화가 다시 평범해 보이게 된 뒤로도 한참 동안.

에이전트가 되돌릴 수 없는 작업을 하도록 설득당합니다: 삭제, 환불, 메일 발송.

SQL이나 셸 명령이 도구 호출에 몰래 실립니다. 오래된 버그 유형이자 새로운 현관문입니다.

RAG에 악성 문서 하나만 있어도 무해한 질문에 대한 답변이 탈취됩니다.

도구 설명에 숨겨진 한 줄이, 평범한 질문에도 에이전트가 정보를 흘리게 만듭니다. 공격자의 메시지는 필요하지 않습니다.

공격이 실패하면 보고서는 무엇이 그것을 막았는지 지목합니다. 신원 확인, 콘텐츠 필터, 백엔드의 권한, 또는 출력만 되고 실제로는 실행되지 않은 도구 호출. 마지막 것은 기록상 침해처럼 읽히지만 아무 가치가 없습니다.

봇 하나, 모델 둘, 각각 254건의 공격, 각각 3회 시도. 작은 쪽은 그중 27건에서 무너졌고 큰 쪽은 24건에서 무너졌으며, 그중 18건은 같은 공격이고 그 가운데 17건은 매 시도마다 두 모델을 모두 무너뜨립니다. 이 봇에서 더 큰 모델은 가장자리에서 어떤 공격이 통하는지를 다시 섞었을 뿐입니다. 구멍을 막지는 않습니다.

실제 가드레일 프레임워크를 상대로 채팅창에 입력한 46건의 공격은 하나도 통하지 않았습니다. 검색된 문서 안에 실어 보낸 공격 한 건도, 두 레일이 모두 켜져 있는 동안에는 통하지 않았습니다. 출력 필터를 끄면 같은 문서가 매 시도마다 그대로 걸어 나갑니다. 입력 필터는 사용자가 입력한 것을 읽을 뿐, 지식 베이스가 모델에 건네는 것은 결코 보지 못하므로, 입력 쪽 레일은 애초에 그것을 막던 것이 아니었습니다.

같은 메시지를 그 가드레일에 다시 보냈더니 늘 자기 자신과 일치하지는 않았습니다. 동일한 입력에 대해 다섯 가지 표현이 서로 다른 판정을 받았고, 평범한 질문 하나는 열두 번 중 열 번 허용되었습니다. 그래서 우리는 몇 번의 시도가 무언가를 무너뜨렸는지를 보고하고, 한 번이라도 무너뜨렸는지는 보고하지 않습니다. 한 번의 실행은 어느 날 오후의 이야기일 뿐이며, 이는 나쁜 결과뿐 아니라 깨끗한 결과에도 똑같이 적용됩니다. 우리 것도 포함해서.

그 문서를 막았던 바로 그 가드레일은, 해당 주제에 관한 평범한 고객 질문 9건 중 6건에도 답변을 거부했습니다. 고객에게 “아니요”라고 답하는 방어는 출시 후가 아니라 출시 전에 알고 싶은 숫자입니다.

항상 무언가를 찾아내는 스캐너는 아무 가치가 없습니다. 그래서 우리는 반대편 숫자를 측정했습니다. 어디에도 공격자가 없는 1500건의 무해한 프로브를 30개 대상에 걸쳐 같은 검사에 통과시킨 것입니다. 그 절반은 정당한 이유로 보안을 이야기하는 사용자입니다. 패턴 대조를 깨뜨리는 것이 바로 그런 경우이기 때문입니다. 실패하는 쿼리를 붙여 넣는 개발자, 스택 트레이스를 전달하는 지원 담당, 비슷하게 생긴 도메인이 진짜인지 묻는 사람.

여기서 작성한 봇은 쉬운 경우입니다. 그래서 여기 누구도 설계하지 않은 에이전트 프레임워크를 겨냥했습니다. 깨끗한 프롬프트 48건을 돌린 한 번의 실행에서 여덟 건의 오탐이 나왔고, 그것도 우리 자신의 봇들에 대한 480건의 프로브에서 단 한 번도 나온 적 없던 네 가지 범주에서였습니다. 네 가지 모두 고쳤고, 그 아래의 두 규칙은 이제 당신의 보고서가 아니라 우리의 빌드를 실패시킵니다. 어떤 검사도 질문을 읽어서는 안 되며, 어떤 검사도 에이전트 자신의 말을 시스템에 대한 증거로 다뤄서는 안 됩니다.

garak, promptfoo와 같은 제3자 대상을 상대로 실행하고, 세 도구의 모든 응답을 각 도구 자체의 판정이 아니라 하나의 부분 문자열 규칙으로 채점했습니다. 가드레일이 없는 RAG 애플리케이션에서는 무해한 프로브의 46%가 이미 심어둔 문자열을 되돌려줍니다. 따라서 발견 사항의 건수를 세는 것은 공격자가 아니라 애플리케이션을 재는 일이 됩니다. 세 도구 중 하나는 자신의 보고서에 그 점을 적어 둡니다. 보호된 대상에서는 공통 규칙으로 셋 다 0점이었고, 무언가를 찾아낸 것은 우리뿐이었습니다. 324건 중 1건의 돌파입니다. 한편 같은 배포는 평범한 고객 질문 48건 중 38건에 답변을 거부합니다. 해당 페이지는 다른 두 도구가 더 나은 지점도, 검토자가 p 값을 요구한 뒤 우리가 철회한 주장도 공개합니다. 비교 읽기.

프로브 열두 건으로 이루어진 조사이며 모두 무해합니다. 다섯 대의 봇이 평범한 요청에 자신의 지시문을 그대로 내주었습니다. 한 대는 그 키를 공유하면 안 된다고 말한 바로 그 문장 안에서 기밀 세션 키를 출력했습니다. 두 대는 무언가를 재시작할 수 있는 도구가 없는데도 데이터베이스 재시작을 보고했습니다.

모든 실행이 보관되므로 각 발견 사항에는 처음 나타난 날짜가 붙습니다. “심각”은 의견입니다. “심각하며 3일부터 미해결”은 팀이 그런 발견 사항에 어떻게 대응하는지에 관한 사실이고, 수정이 일정에 오르게 만드는 것은 바로 그 한 줄입니다.

닫은 뒤에 다시 나타난 발견 사항은 재발로 표시되며, 새로운 것들 옆에 조용히 함께 집계되지는 않습니다. 버티지 못한 수정은 두 대화 중 더 껄끄러운 쪽이고, 둘을 합치면 그것이 가려집니다.

실행이 어떤 공격을 보내지 않았다면, 그 공격은 보고서에 미검사로 기록되며 결코 수정됨으로 기록되지 않습니다. 보내지 않았다는 사실은 깨끗한 결과가 아니며, 이 둘을 뭉개는 보고서는 아무도 들여다보지 않았는데도 취약점이 사라졌다고 말하게 됩니다.

어떤 호출은 우리가 읽을 수 있는 어떤 텍스트에도 나타나지 않는 값을 도구에 넘깁니다. 그런 것들은 따로 나열하고 어떤 로그를 보면 열리는지 알려드립니다. “확인했고 깨끗했다”와 “볼 수 없었다”의 차이는 측정과 약속의 차이이기 때문입니다.