프롬프트 인젝션을 막을 수는 없습니다. 그렇다면 무엇을 해야 할까요?
완벽한 시스템 메시지를 만들려고 애쓰는 것을 멈추십시오. 보안 문제를 해결해 줄 더 나은 모델 버전이 나오기만을 기다리지 마십시오.
프롬프트 인젝션은 반드시 발생합니다. 악의적인 지시가 명령처럼 보일 때 이를 확실히 거부할 수 있는 모델은 없습니다. 완벽한 모델을 전제로 보안을 설계한다면 실패할 것입니다.
초점을 바꾸십시오. 인젝션을 어떻게 막을지 묻지 말고, 인젝션이 성공한 후 에이전트가 무엇을 할 수 있는지 물으십시오.
피해를 최소화하려면 다음 규칙을 따르십시오:
- 권한 범위가 제한된 자격 증명을 사용하십시오. 에이전트에게 현재 작업에 필요한 권한만 부여하십시오. 읽기 전용 권한을 가진 에이전트는 관리자 키를 가진 에이전트보다 피해를 덜 입힙니다.
- 파괴적인 작업에 차단벽을 설치하십시오. 삭제, 결제, 액세스 권한 부여와 같은 작업에는 2단계 인증이나 수동 확인을 요구하십시오. 모델이 이러한 작업의 안전 여부를 직접 결정하게 두지 마십시오.
- 모든 외부 입력을 신뢰할 수 없는 것으로 취급하십시오. 여기에는 사용자 메시지, 웹 페이지, 도구 출력 및 문서가 포함됩니다. 데이터는 컨텍스트 윈도우(context window)에 들어오는 순간 종종 지시 사항으로 변질됩니다.
- 도구 출력을 주시하십시오. 많은 프레임워크가 도구 로그를 모델 컨텍스트로 직접 전달합니다. 17,022개의 에이전트 기술을 대상으로 한 연구에 따르면, 사례의 73.5%에서 디버그 로그를 통해 자격 증명이 유출되는 것이 발견되었습니다. 도구 출력이 모델에 도달하기 전에 비밀 정보를 마스킹(redact)하십시오.
- 품질뿐만 아니라 행동을 모니터링하십시오. 탈취된 에이전트는 승인되지 않은 작업을 수행하면서도 고품질의 텍스트를 생성할 수 있습니다. 정상적인 작업 시퀀스의 기준(baseline)을 설정하고, 이에서 벗어나는 경우 경고를 보내야 합니다.
다음 세 가지 수준의 행동 모니터링을 활용하십시오:
- 정적 규칙(Static rules): 에이전트가 갑자기 이메일을 보내는 것과 같은 명백한 변화를 포착합니다.
- 시퀀스 패턴(Sequence patterns): 에이전트의 일반적인 작업 흐름에 맞지 않는 작업을 식별합니다.
- 독립적 검토(Independent review): 두 번째 모델을 사용하여 기본 에이전트를 판단합니다.
에이전트가 메모리를 사용한다면 깨끗하게 유지하십시오. 단 한 번의 인젝션으로 오염된 사실이 기록되면 모든 세션에서 반복될 수 있습니다. 인스턴스별로 메모리 범위를 지정하고, 모든 정보가 어디에서 왔는지 추적하십시오.
지금 당장 에이전트가 탈취된다면, 로그에서 이를 확인할 수 있습니까? 아니면 아무것도 모른 채 방치하고 있습니까?
Source: https://dev.to/brennhill/you-cant-prevent-prompt-injection-so-what-do-you-actually-do-1d37
Optional learning community: https://t.me/GyaanSetuAi