암호 기술은 전송 중 누가 메시지를 읽을 수 있는지 결정하고, 접근 통제와 에이전트 설계는 수신자가 읽은 뒤 무엇을 할 수 있는지 결정합니다.
메신저에서 프롬프트 인젝션 공격은 메시지 내용이 AI 도우미를 유도해 원래의 규칙을 무시하고 허가되지 않은 요구를 실행하게 하려는 경우에 발생합니다. 종단 간 암호화는 전송 중인 메시지를 보호합니다. 하지만 사용자가 봇에 채팅 읽기 권한을 주었거나 기기가 악성코드에 감염되었다면, 암호화로 그 권한 있는 수신자의 행동까지 통제할 수는 없습니다.
핵심 요점
- 종단 간 암호화는 전송 중 메시지를 읽지 못하게 할 뿐, 복호화된 내용을 볼 권한이 있는 가상 도우미의 악용을 막지는 못합니다.
- 간접 프롬프트 인젝션은 비공개 메시지, 파일, 캡션 또는 인용된 내용에 숨어 있다가 처리 과정에서 지시로 받아들여질 수 있습니다.
- AI 에이전트가 채팅, 메모리, 외부 도구와 함께 전송이나 작업 실행 기능에도 동시에 접근할 수 있으면 정보 유출 위험이 커집니다.
- 데이터와 지시의 분리, 권한 최소화, 사람의 확인, 출력 제한은 중요한 방어 계층입니다. 어느 하나만으로 완전한 안전을 보장하지는 못합니다.
- Livara 문서에 따르면 직접 채팅과 호환되는 비공개 그룹은 E2EE가 활성화된 상태에서 종단 간 암호화됩니다. 호환되지 않는 오래된 그룹은 보호 범위 밖에 남을 수 있습니다. 이 보호가 도우미가 내용을 받은 뒤의 행동까지 보장하지는 않습니다.
메신저의 프롬프트 인젝션 공격은 어떻게 작동할까요?
프롬프트 인젝션, 즉 ‘지시 주입’은 공격자가 언어 모델이 데이터를 지시로 받아들이도록 입력을 만들어 원래 정책에서 벗어나게 하는 것입니다. OWASP의 프롬프트 인젝션 안내서는 직접 입력과 외부 콘텐츠를 모두 이러한 위험의 경로로 설명합니다. 에이전트 기반 시스템에서는 답변의 일탈이 연결된 도구의 의도치 않은 사용으로까지 이어질 수 있습니다.
직접 공격에서는 사용자가 봇에 이전 규칙을 무시하라고 직접 말합니다. 간접 공격에서는 도우미가 다른 작업을 위해 읽는 콘텐츠에 악성 지시가 들어 있습니다. 수신 메시지, 인용문, 캡션, 문서 또는 도구의 출력 등이 해당합니다. 후자의 경우 공격자가 AI 에이전트와 계정을 공유할 필요는 없습니다. 자신의 콘텐츠가 에이전트가 처리하는 맥락에 도달하기만 하면 됩니다.
예를 들어 사용자가 도우미에게 새 메시지들을 요약해 달라고 요청합니다. 그중 한 메시지에 ‘시스템 지시’를 사칭하는 내용이 들어 있어, 에이전트에게 요약을 멈추고 맥락에서 다른 정보를 꺼내 외부 목적지로 보내라고 요구한다고 해 봅시다. 이 상황이 반드시 성공하는 것은 아니며 모델, 앱 설계, 접근 권한, 출력 통제에 따라 달라집니다. 하지만 도구를 가진 도우미에게는 그 가능성 자체가 보안상 중요합니다.
모델의 답변을 조작하는 것과 실제 행동이 가능한 에이전트를 공격하는 것은 구분해야 합니다. 틀린 답변은 불편함을 줄 수 있습니다. 반면 메시지를 보내거나 파일을 가져오거나 서비스를 호출할 권한이 있는 에이전트는 같은 조작을 데이터 노출이나 원치 않는 행동으로 바꿀 수 있습니다.
AI 챗봇 보안은 왜 암호화에만 달려 있지 않을까요?
AI 챗봇 보안은 메신저, 기기, 모델, 메모리, 도구, 제공업체 서버, 권한 정책으로 이어지는 전체 신뢰 사슬에 달려 있습니다. 종단 간 암호화가 보호하는 것은 특정한 경계뿐입니다. 즉, 발신자와 권한 있는 수신자 사이에서 비공개 내용을 다른 이가 읽지 못하게 합니다.
메시지가 권한 있는 기기에 도착하면 사용자에게 표시하기 위해 복호화됩니다. 도우미가 같은 기기에서 또는 허가된 연결을 통해 내용에 접근한다면 복호화 후의 데이터를 보게 됩니다. 프로토콜 관점에서 권한을 받은 봇이나 앱은 정당한 수신자일 수 있습니다. 하지만 사용자 관점에서 같은 수신자가 지나치게 많은 권한을 가진 경우도 있습니다.
이 차이는 이렇게 정리할 수 있습니다. 암호 기술은 전송 중 누가 메시지를 읽을 수 있는지 결정하고, 접근 통제와 에이전트 설계는 수신자가 읽은 뒤 무엇을 할 수 있는지 결정합니다. 첫 번째 경계를 이해하는 데 도움이 되는 종단 간 암호화와 보호하지 못하는 대상 안내서는 E2EE가 악성코드, 신뢰를 저버린 수신자, 침해된 디스플레이의 해결책은 아니라고 설명합니다.
‘암호화 메신저와 AI’라는 조합도 자동으로 안전하거나 위험하다고 해석해서는 안 됩니다. 영구 메모리와 출력 도구가 없는 로컬 에이전트는 대화 기록, 파일, 외부 계정에 접근할 수 있는 클라우드 봇과 위험 수준이 같지 않습니다. 결과를 결정하는 것은 아키텍처와 권한 범위입니다.
AI 도우미의 비공개 채팅 접근은 어떤 위험을 만들까요?
AI 도우미가 비공개 채팅에 접근하면 이전에는 대화 참여자인 사람만 보던 내용이 새로운 신뢰 경계 안으로 들어갑니다. 핵심 위험은 도우미가 내용을 읽는 데 그치지 않고 보관하거나 다른 데이터와 결합하거나 다른 경로로 외부에 보낼 수 있다는 점입니다.
이런 기능을 켜기 전에 다음 다섯 가지 질문에 명확히 답할 수 있어야 합니다.
- 도우미는 정확히 어떤 대화와 첨부파일을 어느 기간에 걸쳐 읽나요?
- 처리는 기기에서 이루어지나요, 아니면 내용이 다른 서버로 전달되나요?
- 제공업체는 어떤 데이터를 보관하며, 이를 학습에 사용하나요?
- 에이전트에는 메시지 전송, 파일 업로드, 검색 또는 작업 실행을 위한 어떤 도구가 있나요?
- 민감한 행동마다 사용자의 명시적 확인이 필요한가요?
선택한 메시지 하나만 요약하면 되는 기능에 ‘모든 채팅 읽기’ 권한을 주는 것은 최소 권한 원칙을 위반합니다. 이 원칙은 각 구성요소가 현재 작업에 필요한 최소한의 접근 권한만 받아야 한다는 뜻입니다. 권한을 메시지 하나, 대화 하나, 한 번의 상호작용으로 제한하면 피해 범위가 줄어듭니다. 다만 그 제한된 범위의 콘텐츠에도 공격이 들어 있을 수 있습니다.
메타데이터는 내용과 별개입니다. Livara 문서에 따르면 발신자, 목적지, 전달 시각 등의 운영 메타데이터는 라우팅과 동기화를 위해 저장됩니다. 메신저 메타데이터와 그것이 드러내는 정보 안내서는 이 경계를 설명합니다. 도우미는 내용뿐 아니라 연락 패턴과 소통 시각을 바탕으로도 추론할 수 있으므로, 접근 정책은 두 가지를 모두 고려해야 합니다.
AI 에이전트의 정보 유출은 어떤 경로로 일어날까요?
AI 에이전트의 정보 유출은 보통 에이전트가 자신의 맥락에서 기밀 내용을 볼 수 있고, 이를 다른 목적지로 전달할 수단이 있을 때 일어납니다. 지시 주입만으로 데이터가 이동하지는 않습니다. 유출은 악성 입력, 데이터 접근 권한, 출력 경로가 결합되어야 가능합니다.
출력 메시지 또는 파일
에이전트는 답변, 새 메시지, 초안, 파일 또는 외부 서비스로 보내는 요청에 정보를 포함할 수 있습니다. 시스템이 제한이나 사용자 확인 없이 출력을 전송한다면, 공격자는 기밀 데이터를 겉보기에 평범한 형태로 바꾸려 시도할 수 있습니다.
장기 메모리
일부 에이전트는 대화 요약, 선호 사항 또는 이전 결과를 나중에 쓰기 위해 보관합니다. 악성 지시는 데이터를 메모리에 넣거나 다른 세션에서 꺼내려 시도할 수 있습니다. 짧은 메모리 보존 기간, 사용자 간 격리, 메모리를 보고 삭제할 수 있는 기능은 위험을 줄이지만 모델의 오류를 없애지는 못합니다.
도구 호출
도구를 가진 에이전트는 검색하거나 파일을 읽거나 그 밖의 허가된 작업을 수행할 수 있습니다. 파일 읽기, 메시지 전송, 네트워크 요청에는 각각 별도 권한이 있어야 합니다. 출력에서 링크를 자동으로 표시하거나 외부 리소스를 불러오는 것만으로도 데이터가 빠져나갈 경로가 생길 수 있습니다. ‘보내기’ 버튼이 없다는 것만으로는 충분하지 않습니다.
감염된 기기
충분한 접근 권한을 가진 악성코드는 화면의 내용, 알림, 앱 메모리 또는 사용자 입력을 볼 수 있습니다. 이 경우 공격자는 반드시 암호화를 깨야 하는 것은 아닙니다. 단말을 이용해 방어를 우회합니다. 운영체제 보호, 업데이트, 접근 통제, 설치된 앱 점검은 방어의 일부이지 메신저 프로토콜의 기능은 아닙니다.
이 위협에 대해 Livara의 암호화는 어떤 경계를 가질까요?
Livara 보안 문서는 직접 채팅용 LVR1과 호환되는 비공개 그룹용 LGS1을 설명합니다. 호환되지 않는 오래된 그룹은 E2EE 보호 범위에서 명백히 제외될 수 있으므로 해당 대화의 상태를 확인해야 합니다. 공개 채널도 비공개 E2EE 채팅의 범위에 포함되지 않습니다.
E2EE 대화에서도 사용자가 복호화된 내용을 도우미에게 제공하면 메시지 암호화는 이후 처리의 목적을 통제하지 못합니다. 안전 번호 확인도 상대방의 키를 검증하는 것이지 그 사람의 글에서 악성 지시를 탐지하는 것이 아닙니다. 이 글은 일반적인 위험 유형을 다루며, Livara에 특정 AI 연결 기능이 존재하는지 또는 그 기능이 안전한지를 확인해 주는 글이 아닙니다.
이 그림은 개념도이지 검증된 Livara 아키텍처가 아닙니다. 그림 속 자물쇠는 도우미가 선택된 내용에 접근할 수 없다는 증거가 아닙니다.
어떤 아키텍처가 메신저의 프롬프트 인젝션을 제한할까요?
안전한 아키텍처는 수신 메시지를 신뢰할 수 없는 데이터로 취급해야 합니다. 아는 사람이 암호화된 채팅으로 보냈더라도 마찬가지입니다. 암호화는 경로의 진정성을 강화하지만 발신자의 내용이 자동 실행해도 무해하다는 사실까지 입증하지는 않습니다.
데이터와 지시를 분리하세요
앱은 개발자의 고정 지시, 사용자의 명시적 요청, 채팅에서 읽은 내용을 서로 다른 계층에 두어야 합니다. 지시 주입에 관한 NCSC의 경고는 이 문제를 SQL 인젝션처럼 유사한 확정적 해결책이 있는 문제로 보아서는 안 된다고 강조합니다. 콘텐츠에 ‘신뢰할 수 없는 데이터’라는 표시를 붙이는 것은 유용하지만, 언어 모델이 이 의미적 경계를 언제나 오류 없이 지키지는 못합니다. 따라서 분리와 함께 모델 외부의 통제가 필요합니다.
에이전트의 권한을 줄이세요
요약 에이전트에게는 메시지 자동 전송이나 모든 파일 읽기 기능이 필요하지 않습니다. 도구에는 허용 목록, 좁은 범위, 별도 자격 증명, 짧은 유효기간이 있어야 합니다. 선택한 콘텐츠에 한 번만 권한을 주는 방식은 상시 접근보다 낫습니다. 의도치 않은 접근 가능성과 유출 범위를 모두 줄이기 때문입니다.
결정론적 검사 관문에서 출력을 확인하세요
민감한 데이터를 보낼지에 대한 최종 결정을 모델 자체에 맡겨서는 안 됩니다. 비생성형 계층은 결정론적 규칙으로 목적지, 데이터 유형, 출력량, 요청된 작업을 검사할 수 있습니다. 구조적 규칙과 허용 목적지 목록은 모델 밖에서 적용해야 합니다. 모든 기밀 정보를 의미로 식별하는 일에는 여전히 오류가 있을 수 있습니다. 최소한의 이벤트 기록, 경고, 중지 기능도 필요합니다.
민감한 행동에는 사람의 확인을 요구하세요
초안을 읽는 것과 보내는 것은 다릅니다. 메시지 전송, 파일 공유, 구성원 추가, 계정 설정 변경 또는 외부 서비스로의 데이터 전달에는 명확한 미리보기와 내용을 이해한 상태의 확인이 필요합니다. 모호하거나 지나치게 잦은 확인은 습관적인 클릭을 부릅니다. 인터페이스는 데이터, 목적지, 결과를 정확히 보여 주어야 합니다.
제한된 환경에서 에이전트를 실행하세요
프로세스 격리, 기본 네트워크 접근 차단, 임시 저장소, 범위가 좁은 자격 증명은 실패의 영향을 제한합니다. 이 통제들은 프롬프트 인젝션을 없애지 않습니다. 일탈한 답변이 곧바로 광범위한 접근으로 이어지는 것을 막는 것입니다.
AI 챗봇 보안을 위해 사용자와 관리자는 무엇을 해야 할까요?
사용자는 모든 AI 연결을 비공개 데이터의 새로운 수신자로 보아야 합니다. 관리자도 배포 전에 데이터 흐름과 에이전트의 동작을 검토하고 실행 중에 모니터링해야 합니다.
개인 사용자라면:
- 필요한 메시지나 파일만 선택하고 전체 기록에 대한 접근 권한은 주지 마세요.
- 처리 위치, 보관 기간, 학습 용도, 데이터 삭제 방법을 확인하세요.
- 분명한 필요가 없다면 메시지나 파일 자동 전송은 꺼 두세요.
- 기기, 브라우저, 앱을 최신 상태로 유지하고 민감한 권한을 재검토하세요.
조직이라면:
- 악성 발신자, 신뢰를 저버린 그룹 구성원, 모델 서비스, 외부 도구, 감염된 기기를 각각 다루는 위협 모델을 작성하세요.
- 도구 호출, 권한 변경, 출력 목적지, 사용자 확인을 기록하되 민감한 데이터는 필요한 최소한만 남기세요.
- 메시지, 문서, 인용문, 글자가 있는 이미지, 검색·조회로 가져온 콘텐츠에 포함된 적대적 입력을 시험하세요.
- 각 에이전트에 작업 한도, 요청 빈도, 허용 목적지, 비상 중지 스위치를 정하세요.
- 안전하게 중단하는 것을 기본으로 삼으세요. 정책이 모호하면 에이전트는 추측하지 말고 멈춰야 합니다.
어떤 점검 목록도 완전한 안전을 만들지는 못합니다. 결과는 구현, 모델, 설정, 사용자 행동, 공격 기법의 변화에 달려 있습니다. 좋은 방어의 목표는 권한을 줄이고, 일탈을 드러내며, 피해를 제한하는 것입니다.
암호화 메신저와 AI는 안전하게 함께할 수 있을까요?
네. 도우미에게 최소한의 접근 권한만 주고 확인 없이 민감한 행동을 하지 않게 한다면, 암호화 메신저와 AI는 위험을 관리하면서 함께 작동할 수 있습니다. 다만 어떤 모델이든 비공개 콘텐츠에 연결하면 새로운 신뢰 경계가 생기며, 이를 E2EE라는 이름 뒤에 감춰서는 안 됩니다.
위험이 더 낮은 설계는 가능한 한 기기에서 처리하고, 사용자가 명시적으로 선택한 내용으로 맥락을 제한하며, 메모리 보존 기간을 짧게 하고, 출력 도구를 분리합니다. 로컬 처리도 절대적인 보장은 아닙니다. 감염된 기기, 안전하지 않은 모델, 광범위한 권한은 여전히 위험을 만듭니다.
사용자는 어떤 데이터가 모델로 가는지, 모델이 어디서 실행되는지, 무엇을 얼마나 오래 보관하는지, 어떤 행동이 가능한지 알 수 있어야 합니다. 제품이 이 질문들에 분명히 답하지 않는다면 ‘프라이빗 AI’ 같은 표현만으로 안전하다고 단정해서는 안 됩니다.
프로토콜 문서나 앱의 해시값 일치가 연결된 도우미의 보안 시험을 뜻하지는 않습니다. 연결을 켜기 전에 해당 기능의 권한과 데이터 경로를 따로 확인하세요. 시험 한 번이 성공했다는 결과만으로 앞으로의 모든 입력까지 포괄할 수도 없습니다.
자주 묻는 질문
종단 간 암호화가 프롬프트 인젝션을 막아 주나요?
아니요. 종단 간 암호화는 발신자와 권한 있는 수신자 사이에서 중간자가 메시지를 보지 못하게 합니다. 권한 있는 봇, 기기의 앱 또는 악성코드가 복호화된 내용에 접근할 수 있다면 이를 처리할 수 있습니다. 프롬프트 인젝션을 억제하려면 에이전트의 권한, 도구, 메모리, 출력을 제한해야 합니다.
AI로 비공개 채팅을 요약하는 것은 위험한가요?
위험은 아키텍처에 따라 달라집니다. 선택한 메시지 하나를 메모리나 출력 도구 없이 로컬에서 요약하면 모든 채팅에 상시 접근하는 클라우드 봇보다 위험 범위가 좁습니다. 사용 전에 처리 위치, 데이터 보관, 권한 범위, 자동 전송 가능 여부를 확인하세요.
아는 사람이 보낸 메시지에도 프롬프트 인젝션이 있을 수 있나요?
네. 발신자의 신원을 신뢰하는 것과 그 사람이 보낸 모든 내용을 신뢰하는 것은 다릅니다. 계정이 탈취되었거나 본인이 모르고 악성 내용을 전달했을 수도 있습니다. 에이전트가 읽는 모든 콘텐츠는 인증되고 암호화된 대화 안에 있더라도 신뢰할 수 없는 데이터로 취급해야 합니다.
LVR1과 LGS1은 AI 도우미에게서 정보를 숨겨 주나요?
실제로 LVR1 또는 LGS1로 보호되고 E2EE가 활성화된 대화에서, 이 프로토콜의 목적은 키가 없는 중간자에게 내용을 숨기는 것입니다. 사용자나 앱이 도우미에게 복호화된 메시지 읽기를 허용하면 이 프로토콜은 그 허가된 접근을 막지 않습니다. 따라서 도우미 보안은 메시지 전송 보안과 별도로 평가해야 합니다.
AI 에이전트의 정보 유출을 줄이는 첫 단계는 무엇인가요?
먼저 에이전트의 접근 범위를 줄이세요. 선택한 메시지만, 해당 상호작용에서만 접근하게 하고 자동 전송은 허용하지 마세요. 그다음 민감한 작업에 미리보기와 사람의 확인을 추가하고, 출력 목적지를 제한하며, 도구 호출을 기록하세요. 이 계층들은 위험을 줄이지만 절대적인 보장을 제공하지는 않습니다.
