ydhom26-hetip

프롬프트 인젝션 점검은 챗지피티나 제미나이를 사내 시스템에 연결하기 전 가장 먼저 해야 할 일입니다.

프롬프트 인젝션 점검이 필요해진 이유

같은 날 보도된 두 소식

메일함, 문서함, 일정표까지 에이전트를 연결하면 분명 편해집니다. 대개는 일단 붙여 보고, 잘 돌아가면 그대로 쓰게 됩니다. 그런데 연결한다는 건 에이전트에게 권한을 준다는 뜻이기도 합니다. 그 순간부터 에이전트가 할 수 있는 일은 준 권한만큼 넓어집니다. 편리함과 위험이 같은 문으로 들어오는 셈입니다.

어제 이 문제와 맞닿은 소식이 두 건 보도됐습니다. 하나는 마이크로소프트 쪽 경고이고, 다른 하나는 구글 쪽에서 실제로 벌어진 사고입니다. 둘 다 에이전트를 업무에 연결하는 실무자에게 직접 닿는 이야기입니다.

마이크로소프트의 인공지능 총괄 무스타파 술레이만은 오픈AI의 셀프 프롬프트 인젝션 위험을 심각한 상황이라고 지적했습니다. 프롬프트 인젝션은 에이전트가 원래 지시가 아닌 엉뚱한 지시를 따르게 되는 문제를 말합니다. 에이전트가 읽은 문서에 엉뚱한 지시가 섞여 있으면, 그 지시를 진짜 지시로 알고 따라버리는 상황입니다. 셀프라는 말이 붙은 구체적인 방식은 이번 보도만으로는 알기 어렵습니다. 다만 다른 회사의 인공지능 총괄이 드러내 놓고 짚었다는 점은 가볍지 않습니다.

구글 쪽에서는 실제 사고가 있었습니다. 구글의 제미나이 기반 보안 테스트 환경에서 오류가 있었고, 그 결과 인공지능이 실제 기업 세 곳의 시스템에 침투하는 사고가 발생했습니다. 보안을 점검하려고 만든 환경에서 오히려 실제 시스템이 뚫린 셈입니다. 어떤 오류였는지, 피해가 어느 정도였는지는 확인된 자료로는 알 수 없었지만, 테스트용 에이전트에게도 실제 시스템에 닿는 길이 열려 있었다는 점은 분명합니다.

두 사건을 나란히 놓으면 공통점이 보입니다. 하나는 에이전트가 무엇을 따르느냐의 문제이고, 다른 하나는 에이전트의 손이 어디까지 닿느냐의 문제입니다.

업무에 연결하기 전 네 단계 점검

목록부터 실행 기록까지

업무에 연결하기 전에는 네 단계를 거치는 것이 좋습니다. 연결된 시스템 적기, 권한 줄이기, 사람 확인 넣기, 실행 기록 남기기입니다.

먼저 연결된 시스템 적기입니다. 에이전트가 지금 무엇에 접근하는지 목록부터 만드는 겁니다. 메일, 드라이브, 사내 메신저, 고객 명단처럼 하나씩 적으면 됩니다. 목록은 거창할 필요 없이 메모장 한 페이지면 충분합니다. 처음 연동할 때 눌러 둔 허용 버튼이 그대로 남아 있을 수 있어서, 적다 보면 생각보다 목록이 길어질 수 있습니다.

그다음은 권한 줄이기입니다. 목록의 항목마다 읽기만 필요한지, 쓰기까지 필요한지 따져 봅니다. 요약만 시키는 일이라면 읽기 권한이면 충분합니다. 회의록 요약용 에이전트라면 메일 발송 권한까지는 필요 없습니다. 삭제나 발송 권한은 꼭 필요한 곳에만 남기는 것이 좋습니다. 처음에 전체 허용으로 연결했다면, 연결을 끊고 필요한 항목만 골라 다시 연결해 보는 것도 방법입니다. 권한이 좁을수록 잘못 움직였을 때 번지는 범위도 좁아집니다.

세 번째는 사람 확인 넣기입니다. 메일 발송, 결제, 파일 삭제처럼 되돌리기 어려운 동작 앞에는 반드시 확인 단계를 둡니다. 에이전트는 초안까지만 만들고, 실행 버튼은 사람이 누르는 구조입니다. 속도는 조금 느려지지만, 이 한 단계가 가장 값싼 보험이라고 볼 수 있습니다.

마지막은 실행 기록 남기기입니다. 에이전트가 언제, 어떤 입력을 보고, 무엇을 했는지 남겨 두면, 잘못된 지시가 어디서 들어왔는지 좇을 수 있습니다. 기록이 없으면 잘못된 일이 있었는지조차 늦게 알게 됩니다.

이 중 하나만 먼저 한다면 목록 만들기부터 권합니다. 목록이 있어야 나머지 세 단계도 무엇을 줄이고 막을지 정할 수 있기 때문입니다.

실무자 입장에서 달라질 두 가지

앞으로는 에이전트를 고를 때 얼마나 잘 해내느냐보다 어디까지 맡길지를 먼저 정하는 쪽으로 무게가 옮겨갈 것으로 보입니다. 성능 비교표보다 권한 설계표가 먼저 필요한 시점이라는 뜻입니다. 특히 사내 메신저와 그룹웨어를 한 계정으로 묶어 쓰는 회사라면 더욱 그렇습니다. 한 번 연결하면 여러 시스템이 한꺼번에 열릴 수 있기 때문입니다.

실무자 입장에서 달라질 일은 두 가지입니다. 첫째, 검토 보고서에 권한 목록을 넣는 것입니다. 어떤 시스템에, 어떤 권한으로 연결했는지 적어 두면 보안 담당자와 이야기할 때도 말이 빨라집니다. 보안 담당자가 따로 없는 작은 팀이라면, 이 목록 관리가 곧 보안 업무가 됩니다. 반대로 목록이 없으면, 문제가 생겼을 때 어디를 끊어야 할지부터 헤매게 됩니다.

둘째, 새 기능이 붙을 때마다 권한을 다시 보는 습관입니다. 기능이 늘어나면 요구하는 권한도 따라 늘어날 수 있습니다. 한 달에 한 번이든 분기에 한 번이든, 날짜를 정해 목록을 다시 보는 것이 좋습니다.

마이크로소프트 인공지능 총괄의 경고와 구글의 침투 사고가 같은 날 보도됐습니다. 도구를 만드는 회사가 방어를 강화하더라도, 내 계정에 준 권한은 내가 가장 잘 압니다. 회사들의 대응을 기다리기보다 내 쪽 연결부터 줄이는 것이 지금 가장 현실적인 대응입니다.

출처

• 마이크로소프트 AI 총괄의 오픈AI 프롬프트 인젝션 경고 — AI타임스 — 술레이먼 "오픈AI의
• 구글 제미나이 보안 테스트 침투 사고 — AI타임스 — 구글