LLM 보안이란? OWASP Top 10 안전 위험을 완화하는 방법

공격자의 지시를 명령으로 받아들이도록 AI를 속이는 공격, 즉 프롬프트 인젝션은 2023년 이후 발표된 모든 판에서 LLM 애플리케이션을 위한 OWASP Top 10의 1위를 차지해 왔습니다.

이 목록은 AI 보안 분야에서 합의에 가장 가까운 결과물이라 할 수 있습니다. 이 프로젝트는 소수의 보안 전문가 그룹으로 시작했지만, 현재는 18개국 이상에서 600명이 넘는 전문가가 기여하고 있습니다.

저희는 AI가 어떻게 설득당해 엉뚱한 일을 하게 되는지 다루는 가이드를 발행하는 AI 기업이므로, 이 문제가 이미 해결된 척하지는 않겠습니다. OWASP 프로젝트를 공동으로 이끄는 Wilson은 현재의 방어 수준에 대해 분명하게 말했습니다. "...솔직히 말해서, 우리가 99%에 도달했다고는 생각하지 않습니다."

2026년판도 같은 논조로 시작합니다. 프로젝트 리더는 "속지 않는 모델을 만들려는 시도를 멈추고", 모델이 속더라도 중요한 것을 망가뜨릴 수 없도록 주변 시스템을 설계하라고 조언합니다.

이 글에서는 OWASP 2026년 목록에 오른 10가지 위험 모두를 이러한 관점에서 살펴보겠습니다.

LLM 보안이란 무엇인가요?

LLM 보안이란 AI 모델과 이를 사용하는 애플리케이션을 공격과 오용으로부터 보호하는 것을 말합니다. 위험은 모델이 무엇에 연결되어 있는지에 따라 커집니다. 모델이 읽을 수 있는 파일과 데이터, 그리고 이메일, 검색, 회사 데이터베이스처럼 모델이 사용할 수 있는 도구가 여기에 해당합니다.

제대로 보호된 소프트웨어에서는 프로그램이 따르는 지시와 프로그램이 처리하는 정보 사이에 확실한 경계가 있습니다. 하지만 LLM에는 그런 경계가 없습니다.

모델이 읽는 모든 내용은 개발자의 지시, 사용자의 질문, 모델이 찾아본 웹페이지 등이 하나로 이어진 긴 텍스트 흐름으로 들어옵니다. AI 모델은 지금 말하는 주체가 개발자인지, 사용자인지, 아니면 문제를 따져 보는 모델 자신인지를 구분해야 합니다.

하지만 연구자 Jasmine Cui와 Charles Ye는 모델이 주로 텍스트의 말투를 보고 누가 말하는지 추측한다는 사실을 발견했습니다. 따라서 공격자가 모델 자신의 추론처럼 들리는 글을 쓰면, 모델은 그 아이디어를 스스로 떠올렸다고 믿을 수 있습니다. 이는 누가 주도권을 쥐고 있는지 모델이 알고 있다는 전제에 의존하는 모든 안전 장치에 문제가 됩니다.

저희도 자체 AI 에이전트에서 같은 문제를 겪었습니다. 저희 CISO인 Kyle Polley는 ISMG에 에이전트가 "시스템 프롬프트에 추가하더라도 정책을 따르지 않을 수 있다"고 말했습니다. 그래서 저희는 에이전트가 하려는 작업을 확인하고, 해당 작업이 설정된 보안 규칙을 위반하면 차단할 수 있는 오픈 소스 도구 Numbat을 만들었습니다.

LLM 보안이란 모델이 때때로 엉뚱한 사람의 명령을 따를 수 있다는 사실을 받아들이고, 그런 일이 일어나더라도 무너지지 않는 AI 가드레일을 주변에 갖추는 것을 의미합니다.

LLM 보안 모범 사례에는 어떤 것이 있나요?

LLM 애플리케이션을 위한 OWASP Top 10 2026을 1위부터 10위까지 순서대로 살펴보겠습니다.

각 위험마다 문제가 어떻게 발생하는지 쉽게 풀어 쓴 설명과 실제 사례를 소개합니다. 그런 다음 위험을 예방하거나, 최소한 피해를 줄이는 데 도움이 되는 방법을 다룹니다.

1. 프롬프트 인젝션 억제하기

프롬프트 인젝션은 공격자가 AI로 하여금 따라서는 안 되는 지시를 따르게 할 때 발생합니다. 이러한 지시는 채팅을 통해 직접 전달될 수도 있고, 이메일, 웹페이지, 문서 안에 심어질 수도 있습니다.

두 번째 유형은 간접 프롬프트 인젝션이라고 합니다. 여러분이 어시스턴트에게 문서 요약을 요청했다고 가정해 보겠습니다. 그런데 문서 작성자가 그 안에 여러분의 비공개 파일을 자신에게 보내라는 지시를 심어 두었습니다. 어시스턴트가 그 지시를 따르면, 문서를 작성한 사람은 사실상 여러분의 접근 권한을 빌려 쓴 셈이 됩니다.

PCMag은 프롬프트 보안을 구멍이 숭숭 뚫린 돌의 구멍을 막는 일에 비유합니다. 구멍 하나를 막으면 물은 또 다른 구멍을 찾아냅니다. “공격은 결국 뚫고 들어옵니다. 문제는 수정되지만, LLM 같은 시스템은 워낙 역동적이기 때문에 아직 발견되지 않은 수많은 공격 경로가 여전히 남아 있습니다.”

사례: 2025년 6월, Aim Security 연구원들은 Microsoft 365 Copilot을 속여 회사의 비공개 정보를 유출하게 만드는 결함인 EchoLeak을 발견했습니다. 직원이 일상적인 업무 질문을 하면 Copilot이 공격자가 보낸 이메일을 불러와 그 안에 숨겨진 지시를 따르고, 민감한 정보를 공격자에게 보낼 수 있었습니다. 이 공격은 악성 지시를 잡아내고 의심스러운 링크를 제거하기 위해 마련된 검사를 모두 우회했습니다.

대응 방법:

• Meta의 “Rule of Two”를 따르세요: EchoLeak이 성공하려면 회사 데이터를 읽고, 외부 이메일을 읽고, 정보를 외부로 보낼 수 있는 AI가 필요했는데, 실제로 이 AI는 세 가지 기능을 모두 갖추고 있었습니다. 이 중 두 가지 기능만 허용하면 프롬프트 인젝션이 지나치게 많은 통제권을 얻는 것을 막을 수 있습니다. 작업에 세 가지 기능이 모두 필요하다면 각 작업 전에 사람의 승인을 받도록 하세요.
• 방어 체계를 알고 있는 공격자를 상정해 테스트하세요: 보안 테스터에게 적용해 둔 규칙과 필터를 알려 준 다음, 이를 우회해 보도록 하세요. 한 연구에서는 방어 체계에 맞춰 공격 방식을 바꾼 공격자들이 테스트한 12가지 방어 기법 대부분에 대해 90%가 넘는 성공률을 보였습니다.

2. 민감 정보 유출 막기

AI 시스템이 볼 권한이 없는 사람에게 비공개 정보를 제공하는 것을 민감 정보 노출이라고 합니다. 고객의 결제 정보를 드러내거나, 비공개 대화를 공유 데이터베이스에 그대로 남겨 두는 것이 그 예입니다.

많은 유출은 “과잉 공유”에서 시작됩니다. 어떤 회사가 권한 설정이 느슨한 드라이브와 지식 베이스에 AI를 연결했다고 가정해 보겠습니다. AI는 설계된 그대로, 접근할 수 있는 모든 것을 검색합니다. 아무도 침입할 필요가 없지만, LLM은 이미 뚫린 것이나 다름없다고 봐야 합니다.

사례: 2025년 1월, Wiz 연구원들은 인터넷에 공개된 DeepSeek 데이터베이스를 발견했습니다. 이 데이터베이스에는 채팅 기록과 API 키(소프트웨어가 다른 서비스에 접근할 때 사용하는 키)를 포함해 100만 건이 넘는 로그 항목이 들어 있었습니다. 연구원들은 모델을 설득해 무언가를 털어놓게 할 필요조차 없었습니다.

대응 방법:

• AI가 데이터를 읽기 전에 접근 권한을 확인하세요: 애플리케이션은 질문하는 사람이 볼 수 있는 문서가 무엇인지 먼저 확인한 다음에 해당 문서를 모델에 전달해야 합니다.
• AI가 남기는 기록을 보호하세요: 활동 로그를 저장하기 전에 개인 정보와 비밀 키를 제거하고, 로그인을 요구하며, 필요한 사람만 접근할 수 있도록 제한하세요. 이러한 기록이 무기한 쌓이지 않도록 보존 기간도 설정하세요.

3. 과도한 자율성 억제하기

과도한 자율성을 가진 AI는 업무에 필요한 것보다 더 많은 권한을 갖습니다. 필요 없는 도구, 작업 범위를 넘어서는 권한, 확인 없이 행동할 수 있는 자유 등이 그렇습니다. 여기서 원인은 중요하지 않습니다.

인젝션 프롬프트든, 버그든, 단순히 판단을 잘못한 모델이든 결과는 모두 같습니다. AI에게 그럴 능력이 있다면 결국에는 무언가 파괴적인 일을 저지르게 됩니다.

사례: 2025년 7월, SaaStr 창업자 Jason Lemkin은 변경하지 말라는 지시에도 불구하고 Replit의 코딩 에이전트가 임원 기록 1,206건이 담긴 자신의 데이터베이스를 삭제했다고 밝혔습니다. 에이전트는 처음에 데이터를 복구할 수 없다고 했지만, 나중에 복구가 가능한 것으로 드러났습니다. Jason은 데이터베이스를 건드리지 말라고 지시해도 데이터베이스를 삭제할 수 있는 능력 자체가 사라지지는 않는다는 사실을 깨달았습니다.

확대

출처: X

대응 방법:

• 작업에 필요 없는 기능은 제거하세요: 에이전트에게 제공하는 도구와 그 도구로 할 수 있는 일을 모두 제한하세요. 이메일을 요약하는 어시스턴트에게는 이메일을 읽을 권한만 있으면 되며, 이메일을 보내거나 삭제할 권한은 필요하지 않습니다.
• 권한 확인은 AI 외부에 두세요: 작업이 요청될 때마다 보안 규칙에 따라 검사하도록 하고, 사람의 승인을 받도록 하세요.

4. AI 공급망으로 유입되는 요소 점검하기

AI를 처음부터 직접 만드는 기업은 많지 않으며, 그 수는 해마다 줄고 있습니다. Menlo Ventures의 2025년 기업 생성형 AI 현황(The State of Generative AI in the Enterprise) 설문조사에 따르면, AI 모델을 구매한 기업의 비율은 2024년 53%에서 2025년 76%로 증가했습니다.

대부분의 기업은 Hugging Face 같은 허브에서 모델을 내려받아 다른 사람들이 수집한 데이터 세트로 추가 학습을 시키고, 잘 알지 못하는 사람들이 작성한 애드온과 코드 패키지를 연결해 사용합니다.

이러한 구성 요소 하나하나가 침입 경로가 됩니다. 그중 하나라도 변조되면 문제가 제품 안에 담긴 채 그대로 출시됩니다.

사례: Hugging Face의 공개 모델 리포지토리는 2026년 1월부터 2026년 8월 사이 243만 개에서 296만 개로 늘어났습니다. 그런데 2026년 7월, OpenAI의 모델이 내부 보안 테스트 중 인터넷 접속을 막기 위한 통제를 우회해 Hugging Face 시스템의 일부에 침입했습니다. 실제로 한 에이전트는 공개적으로 노출된 접근 자격 증명 14개를 확보해 작동 여부를 확인한 뒤 다른 에이전트와 공유했습니다. 이후 에이전트들은 결함을 악용해 Hugging Face 서버에서 코드를 실행했습니다.

OpenAI 보고서는 “모델의 수명 주기 전반에 걸쳐 정렬에 관한 요구 사항을 더 엄격하게 적용하고, 더욱 격리된 샌드박스를 구축하며, 인터넷 접근을 제한하고, 모델 가중치에 대한 접근을 한층 더 통제하고 있습니다”라고 밝혔습니다.

대응 방법:

• 모델을 정확한 버전으로 고정하고 검증하세요: 각 모델을 검토를 마친 버전으로 고정하고, 로드하기 전에 파일 지문을 확인해 바꿔치기된 파일이 같은 이름표를 달고 슬쩍 들어오지 못하게 하세요. OWASP는 디지털 서명도 권장하지만, 한 가지 단서를 붙입니다. 서명은 모델의 출처를 증명할 뿐, 모델이 안전하다는 것을 증명하지는 않는다는 점입니다.
• AI가 제안하는 패키지는 모두 확인하세요: AI 어시스턴트가 추천한 코드 패키지를 설치하기 전에, 해당 패키지가 실제로 존재하는지, 의도한 패키지가 맞는지, 예상한 게시자가 배포한 것인지 확인하세요.

5. 데이터 및 모델 포이즈닝 막기

포이즈닝된 AI는 오염된 데이터로 학습합니다. 오염된 데이터는 미세 조정에 사용된 예시일 수도 있고, 답변을 찾기 위해 검색하는 지식 베이스일 수도 있습니다. 모델은 여전히 제대로 작동하는 것처럼 보이지만 잘못된 교훈을 학습하며, 때로는 특정 트리거 문구를 접했을 때만 오작동하도록 학습하기도 합니다.

이런 모델은 누군가 그 문구를 실제로 사용하기 전까지 어떤 테스트든 모두 통과합니다.

확대

게다가 되돌리기도 매우 어렵습니다. 포이즈닝은 패치로 고칠 수 있는 버그가 아닙니다. 데이터가 잘못되었다면 데이터를 다시 검증하거나, 모델을 재학습시키거나, 아예 모델을 교체해야 할 수도 있습니다.

사례: 2025년 10월, Anthropic, 영국 AI 보안 연구소(UK AI Security Institute), 앨런 튜링 연구소(Alan Turing Institute)의 연구원들은 포이즈닝된 문서 250개만으로 모델이 특정 트리거를 접할 때마다 의미 없는 텍스트를 생성하도록 학습시킬 수 있다는 사실을 보여 주었습니다. 가장 큰 모델은 20배가 넘는 정상 데이터로 학습했는데도, 테스트한 네 가지 모델 크기 모두에서 같은 수의 문서가 효과를 냈습니다.

대응 방법:

• 데이터의 출처를 추적하세요: 사용하는 모든 데이터 세트와 모델, 각각의 출처, 버전 간 변경 사항을 기록해 두세요. 데이터 세트에도 버전 관리를 적용할 것을 권장합니다. 그래야 포이즈닝이 발견되었을 때 깨끗한 버전으로 롤백하고, 오염된 데이터가 어떻게 유입되었는지 파악할 수 있습니다.
• 백도어가 있는지 테스트하세요: “백도어”란 공격자가 모델에 심어 두는 숨겨진 동작으로, 특정 문구나 기타 트리거가 입력되기를 기다렸다가 활성화됩니다. 모델이 평소 규칙을 어기도록 설계된 입력으로 이러한 백도어가 있는지 테스트하세요.

6. 무제한 소비에 상한 두기

AI가 처리할 수 있는 작업량이나 발생시킬 수 있는 비용에 아무런 제한이 없다면, 그 소비는 “무제한”으로 간주됩니다. 대부분의 AI 서비스는 사용량에 따라 요금을 부과하므로, 공격자가 여러분의 요금을 잔뜩 불리거나 모델의 복제본을 만들 수 있습니다.

OWASP는 핵심 문제를 “비용 비대칭”이라고 부릅니다. 짧고 저렴한 요청 하나가 여러분 쪽에서 비용이 많이 드는 연산을 유발할 수 있습니다.

사례: 2024년 5월, Sysdig의 위협 연구팀은 “LLMjacking”이라는 새로운 공격을 발견했습니다. 한 공격자 그룹이 탈취한 자격 증명을 이용해 클라우드에서 호스팅되는 LLM 서비스 10개를 노렸습니다. 이들은 취약한 버전의 Laravel을 통해 침투한 뒤 자격 증명으로 무엇을 할 수 있는지, 할당량은 얼마인지 파악했는데, 목적은 분명히 접근 권한을 판매하는 것이었습니다. 또한 탐지를 피하려는 듯 여러 로깅 설정도 조회했습니다. Sysdig에 따르면 최악의 경우 피해자는 하루에 46,000달러가 넘는 비용을 떠안을 수 있습니다.

대응 방법:

• 지출을 멈추는 예산을 설정하세요: 개별 사용자, API 키, 팀, 계정 전체에 대해 엄격한 지출 한도를 두세요. 요청이 들어올 수 있는 모든 지점에서 이 한도를 적용하세요.
• 모든 작업에 종료 지점을 두세요: 작업의 실행 시간, 처리하고 생성할 수 있는 텍스트의 양, 도구 호출 횟수를 제한하세요. 같은 동작을 반복하거나 허용량을 초과하는 에이전트는 자동으로 중단되도록 하세요.

7. 행동하기 전에 잘못된 정보 걸러내기

AI가 그럴듯하게 들리지만 사실이 아닌 내용을 생성하고, 사람이나 다른 무언가가 이를 바탕으로 행동하는 것을 잘못된 정보라고 합니다. 핵심 위험은 틀린 답 자체보다는 그 틀린 답이 신뢰받고 사용된다는 데 있습니다.

실제 사고 기록을 보면 실무자들은 잘못된 정보를 마땅히 경계해야 할 만큼 경계하지 않았던 것으로 보입니다. 2026년판 서두의 서한에 따르면, 투표자들은 이 항목을 하위권에 두었지만 실제 사고 사례를 기준으로 하면 상위권에 해당합니다.

사례: 2025년, Deloitte Australia는 44만 호주달러 규모의 정부 계약에 따라 복지 IT 시스템 검토 보고서를 제출했습니다. 시드니 대학교의 연구원 Chris Rudge는 존재하지 않는 연구를 가리키는 참고 문헌과 연방 법원 판결에서 지어낸 인용문을 발견했습니다. 수정된 보고서에서 Deloitte가 방법론에 Azure OpenAI GPT-4o를 사용했다는 사실이 공개되었고, 회사는 마지막 분할 대금을 환불하기로 합의했습니다. 안타깝게도 이 보고서는 보증 검토 보고서였습니다.

대응 방법:

• 근거가 답변을 뒷받침하는지 확인하세요: 주장은 최신의 권위 있는 출처에 근거해야 합니다. 정책에 관한 답변이라면 승인된 정책을 검색해 예외 조항을 포함하여 해당 정책이 결론을 뒷받침하는지 확인하세요.
• 시스템이 행동하기 전에 검증하세요: 에이전트가 고객이 본인 확인을 통과했다고 하면, 결제를 진행하기 전에 인증 시스템에서 이를 확인하세요. 중대한 결정에는 사람의 승인을 요구하고, 검토자가 근거 자료를 볼 수 있도록 하세요.

8. 숨겨진 컨텍스트 노출로 인한 피해 줄이기

AI 애플리케이션은 사용자가 일반적으로 보지 못하는 지시와 배경 정보를 모델에 제공합니다. 여기에는 시스템 프롬프트, 내부 정책, 사용 가능한 도구에 대한 설명, 도구를 사용할 수 있는 사람에 관한 규칙 등이 포함될 수 있습니다. 숨겨진 컨텍스트 노출은 모델이 이러한 정보를 누군가에게 드러낼 때 발생합니다.

OWASP는 2026년에 이 항목을 “시스템 프롬프트 유출”에서 확장했는데, 시스템 프롬프트는 유출될 수 있는 정보의 일부에 불과하기 때문입니다. 위험성은 그곳에 무엇을 넣어 두었는지에 따라 달라집니다. 어조 가이드가 유출되면 조금 민망한 정도지만, API 키가 유출되면 누군가 여러분의 기밀 데이터베이스에 접근할 수 있게 됩니다.

사례: 2023년 2월, 사용자들은 Microsoft의 Bing Chat이 내부 지시를 드러내도록 만들었습니다. 성공한 시도 중 하나는 Marvin von Hagen의 것으로, 그는 자신이 OpenAI 개발자라고 주장하며 모델을 구성할 수 있도록 지시 내용을 요청했습니다. Bing은 검색, 응답, 안전 동작을 규정하는 규칙과 함께 내부 이름인 Sydney를 공개했습니다. 공개된 지시 중에는 해당 지시를 기밀로 유지하라는 지시도 있었습니다.

대응 방법:

• 비밀 정보는 모델의 컨텍스트 밖에 두세요: 모델이 읽을 수 있는 정보는 무엇이든 사용자에게 노출될 수 있다고 가정하세요. 비밀번호, API 키, 액세스 토큰은 별도의 시크릿 관리 시스템에 저장해야 합니다.
• 규칙이 유출되더라도 권한 통제가 유지되도록 하세요: 접근 권한 검사는 애플리케이션 코드에서 시행하세요. 관리자만 사용할 수 있는 도구라면 실행하기 전에 사용자 계정의 권한을 확인해야 합니다.

9. 벡터와 임베딩을 철저히 보호하세요

AI가 벡터 검색으로 회사 문서에서 답을 찾을 때는 텍스트를 직접 검색하지 않습니다. 문서는 각 구절의 의미를 담아낸 긴 숫자 목록인 “임베딩”으로 변환되어 벡터 데이터베이스에 저장됩니다. 질문도 같은 방식으로 변환되며, 시스템은 숫자 값이 가장 가까운 구절을 가져옵니다.

OWASP는 이 방식이 실패하는 네 가지 경우를 이렇게 정리합니다. 포이즈닝은 시스템이 잘못된 답을 내게 하고, 역변환은 정보를 유출시키며, 재밍은 시스템이 응답하지 못하게 하고, 취약한 접근 제어는 누구에게나 무엇이든 넘겨주게 만듭니다.

이 숫자들은 보기만큼 안전한 추상화가 아닙니다. 저장된 임베딩은 다시 텍스트로 되돌릴 수 있으며, 한 기법은 테스트에서 32토큰 길이의 짧은 구절 중 92%를 정확히 복원했습니다. 따라서 “임베딩만 담긴” 백업이 유출되면 문서 내용까지 노출될 수 있습니다.

사례: USENIX Security 2025에서 발표된 연구에서, 연구진은 정교하게 조작한 문서 하나로 AI가 특정 질문에 답하지 못하게 할 수 있음을 보여주었습니다. 연구진은 이 문서를 AI가 검색하는 문서 컬렉션에 추가했습니다. AI는 이 문서를 찾으면 정보가 충분하지 않다거나 답변하는 것이 안전하지 않다고 말할 수 있었습니다. 이 문서는 AI에게 규칙을 무시하라고 지시할 필요조차 없었습니다. 이를 “검색 재밍(retrieval jamming)”이라고 합니다.

대응 방법:

• 공개 데이터와 비공개 데이터의 인덱스를 분리하세요: 스크랩한 웹 콘텐츠를 파트너 데이터나 사내 기밀 문서와 섞지 마세요. 하나의 인덱스 안에서 콘텐츠에 태그를 붙여 구분하기보다는 신뢰 수준에 따라 물리적으로 분리하세요. 그러면 특정 유형의 설정 오류를 원천적으로 차단할 수 있고, 인터넷에서 스크랩한 콘텐츠가 이사회 자료 옆에 놓이는 일도 없습니다.
• 임베딩을 원본 문서처럼 다루세요: 임베딩을 암호화하고, 원본 파일뿐 아니라 벡터 데이터베이스 백업도 보호하며, 원본을 삭제할 때는 임베딩도 함께 삭제하세요. 임베딩 서비스의 API 키도 비밀로 유지해야 합니다.

10. AI 출력은 전달하기 전에 검증하세요

애플리케이션이 AI 출력을 다른 시스템으로 전달하면서 그곳에서 사용하기에 안전한지 검증하지 않는다면, 이는 LLM 출력을 부적절하게 처리하는 것입니다.

이 항목은 AI 코딩 어시스턴트가 대량으로 생성하는 안전하지 않은 코드도 다룹니다. 따라서 어시스턴트가 작성하는 코드 한 줄 한 줄도 모두 출력에 해당합니다.

사례: 2025년 연구자 요한 레베르거(Johann Rehberger)는 Sourcegraph의 Amp 코딩 어시스턴트가 이미지를 표시하는 것만으로 채팅 내용을 유출할 수 있음을 보여주었습니다. 그는 프롬프트 인젝션을 이용해 Amp가 이미지의 웹 주소에 비공개 정보를 포함하도록 만들었습니다. 그러자 애플리케이션이 해당 이미지를 자동으로 불러오면서 그 정보를 그의 서버로 전송했습니다. 출력 처리의 실패 지점은 바로 그 자동 요청이었습니다. 모델이 생성한 텍스트가 비공개 데이터를 실은 채 외부 서버로 향하는 연결이 된 것입니다.

대응 방법:

• 출력이 전달될 곳에 맞게 안전하게 만드세요: 응답이 어디로 전달될지에 따라 검사하고 처리하세요. 웹페이지라면 생성된 텍스트가 실행 가능한 코드가 되지 않도록 막아야 합니다. 데이터베이스라면 입력값을 명령과 분리하는 준비된 쿼리(prepared query)를 사용하세요.
• 답변이 외부와 자동으로 연결되지 않도록 막으세요: 모델 응답에 포함된 이미지, 링크 미리보기, 삽입된 페이지의 자동 로딩은 기본적으로 비활성화하세요. 꼭 필요한 연결은 명시적으로 승인된 대상으로만 제한하세요.

Perplexity는 LLM을 어떻게 보호하나요?

저희는 위의 모든 위험이 결국 현실이 될 것이라고 가정하고, 그런 일이 생기더라도 큰 피해를 줄 수 없도록 설계합니다. 저희 CISO인 카일 폴리(Kyle Polley)가 최근 워크숍에서 그 방법을 자세히 소개했습니다.

• 에이전트에게는 전용 컴퓨터가 주어지며, 처음에는 비어 있습니다: 노트북에 설치된 에이전트 도구는 노트북의 파일, 앱, 저장된 자격 증명에 접근할 수 있습니다. Perplexity Computer는 정반대로 작동합니다. 각 작업은 격리된 전용 샌드박스에서 실행되며, 폴리의 표현을 빌리자면 “기본적으로 아무것에도 접근할 수 없습니다.”
• 에이전트는 비밀번호를 절대 보지 못합니다: 연결된 서비스의 자격 증명은 샌드박스 외부에 저장됩니다. 에이전트가 GitHub 같은 서비스에 접근해야 할 때는 자격 증명이 첨부되지 않은 요청을 보냅니다. 게이트웨이는 목적지와 요청이 예상한 것과 일치하는지 확인한 다음, 요청이 외부로 나갈 때 자격 증명을 추가합니다. 에이전트는 키를 받지 않고도 연결을 사용할 수 있습니다.
• 사용자의 권한이 그대로 이어지며, 더 엄격하게 제한할 수도 있습니다: OAuth를 통한 연결은 연결된 서비스에서의 사용자 접근 권한을 그대로 유지합니다. 사용자가 볼 수 없는 것은 에이전트도 볼 수 없습니다.
• 모든 웹 페이지를 낯선 존재로 취급합니다: 저희가 테스트한 도구들은 실제 사용 환경에서 요구 사항을 충족하지 못했기 때문에, 에이전틱 브라우저인 Comet을 위해 BrowseSafe를 직접 만들었습니다. 브라우저는 이메일을 포함한 웹 페이지와 기타 외부 콘텐츠에서 프롬프트 인젝션을 탐지합니다. 저희는 모델과 데이터셋을 모두 오픈 소스로 공개했습니다.
• 에이전트와 에이전트가 실행되는 머신을 모니터링합니다: Numbat은 에이전트가 행동을 결정하는 시점과 도구가 실제로 실행되는 시점 사이에 위치합니다. Numbat은 지원되는 코딩 에이전트 전반의 활동을 기록하며, 설정된 정책을 위반하는 작업을 실행 전에 차단할 수 있습니다. Bumblebee는 노트북, 서버, 빌드 파이프라인 전반의 소프트웨어 패키지 목록을 파악하고 알려진 악성 패키지를 표시합니다. 둘 다 오픈 소스입니다.
• 모델 제공업체는 사용자의 데이터를 보관하지 않습니다: 저희는 서드파티 LLM 제공업체와 데이터 무보존(zero data retention) 계약을 맺고 있습니다. Enterprise 관리자는 Perplexity 자체의 데이터 보존 기간을 최단 24시간으로 설정할 수도 있습니다.

저희가 Numbat을 선제적으로 만든 이유는 폴리가 한 문장으로 요약한 그대로입니다. “에이전트에게 자율성을 많이 부여할수록 위험도 커집니다.”

LLM 보안 FAQ

가장 안전한 LLM은 무엇인가요?

어떤 LLM도 그 자체만으로 애플리케이션을 안전하게 만들어 주지는 않습니다. 모델은 여전히 읽기만 해야 할 콘텐츠를 따라야 할 지시로 착각할 수 있습니다. 표준 테스트에서 강력해 보이는 방어 수단도 압박을 받으면 무너질 수 있습니다.

더 나은 질문은 사용 사례에 가장 안전한 구성이 무엇인지입니다. 즉, 제한된 권한, 모델로부터 분리된 자격 증명, 위험한 작업에 대한 사람의 승인, 그리고 방어 체계를 잘 아는 사람들의 테스트가 필요합니다.

LLM 취약점이란 무엇인가요?

LLM 취약점은 공격자에 의해서든 시스템 자체의 실수로든 AI 시스템이 속거나, 데이터를 유출하거나, 피해를 일으키게 만드는 약점입니다.

10대 주요 위험은 프롬프트 인젝션, 민감한 정보 노출, 과도한 에이전시, 공급망, 데이터 및 모델 포이즈닝, 무제한 소비, 잘못된 정보, 숨겨진 컨텍스트 노출, 벡터 및 임베딩 취약점, 부적절한 출력 처리입니다.

프라이빗 LLM은 안전한가요?

일부 측면에서는 더 안전한 선택이지만, 기본적으로 안전한 것은 아닙니다. 자체 인프라나 클라우드 환경에서 모델을 실행하면 데이터 처리를 더 세밀하게 통제할 수 있습니다. 하지만 프롬프트 인젝션, 과도한 에이전시, 포이즈닝, 잘못된 정보를 자동으로 막을 방법은 없습니다.

셀프 호스팅을 한다면 다운로드한 모델에 대한 책임도 직접 져야 하며, 여기에는 공급망 위험과 모델 구동에 필요한 인프라도 포함됩니다.