기업의 AI 활용이 질문에 답하는 수준을 넘어 문서를 검색하고 업무 도구를 실행하는 단계로 넓어지고 있고, 그만큼 AI가 다루는 정보도 다양해졌습니다. 사용자가 직접 입력한 질문에는 민감정보가 없더라도, 답변을 위해 참고하는 이전 대화나 사내 문서, 업무 시스템의 조회 결과에는 고객정보와 인증정보가 담겨 있을 수 있습니다. 새로운 모델이나 도구를 연결하면 이러한 정보가 전달되는 경로도 달라집니다.
공개된 보안 사례에서는 이 과정에서 무엇을 살펴야 하는지 보여줍니다. DeepSeek의 대화 로그 노출 사례는 외부 AI에 전달한 정보가 어떻게 저장되고 관리되는지 확인할 필요성을 드러냈습니다. EchoLeak 연구는 이메일에 숨겨진 악성 지시가 내부정보 유출로 이어질 수 있음을 보여줬고, 개발 자동화 환경에서는 AI 에이전트가 인증정보에 접근할 수 있는 취약점도 발견됐습니다. AI 보안에서는 입력한 질문뿐 아니라 참고 자료와 도구의 실행 권한, 그 과정에서 남는 기록까지 함께 살펴야 합니다.
이 글에서는 2025~2026년에 공개된 보안 사례를 바탕으로 AI Keeper와 통합 Gateway를 어디에, 어떻게 적용할 수 있는지 살펴봅니다. 민감정보의 전송을 줄이는 차단·마스킹부터 모델 접근 관리와 보호 이력 점검까지, 각 기능이 실제 업무에서 맡을 수 있는 역할을 살펴보겠습니다. AI Keeper핵심 기능의 활용 방안을 구체화하고, 추가로 필요한 보안 과제를 짚으며 AI Keeper가 나아갈 방향을 함께 그려보려 합니다.
AI 사용 경로에 공통 보호 지점을 두는 이유
AI 플랫폼이 모델에 요청을 보내기 전에 통합 Gateway를 거치도록 연결하면, AI Keeper가 전송할 내용을 미리 확인할 수 있습니다. 이때 살펴보는 정보는 사용자가 입력한 질문에만 한정되지 않습니다. 플랫폼이 함께 보내는 문서 내용과 이전 대화, 업무 도구의 조회 결과도 지원 범위에 따라 검사할 수 있습니다. 이러한 보호를 적용하려면 먼저 각 플랫폼의 요청이 Gateway를 통과하도록 연결해야 합니다.
관리자는 이메일 주소나 인증정보처럼 일정한 형식을 가진 정보, 회사가 정한 키워드와 기밀 문구를 보호 규칙으로 등록합니다. 전송을 금지한 정보가 발견되면 요청을 멈추고, 마스킹만 필요한 경우에는 민감한 부분을 가린 뒤 모델에 전달합니다. 필요한 검사를 모두 마친 요청만 다음 단계로 보내는 방식입니다. 다만 등록된 규칙을 바탕으로 검사하기 때문에, 규칙에 없는 기밀정보나 문맥 속 위험까지 모두 알아내는 것은 아닙니다. 실제 업무에서 사용하는 데이터와 표현을 살펴보며 규칙을 보완해 나가는 과정이 필요합니다.
이 과정에서 데이터 보호, 접근제어, 감사는 각기 다른 역할을 맡습니다. 데이터 보호가 요청에 담아도 되는 정보를 판단한다면, 접근제어는 해당 서비스가 사용할 수 있는 모델과 연결 경로를 정합니다. 감사는 이렇게 정한 기준이 실제로 어떻게 적용됐는지 기록을 통해 확인하는 일입니다. 어떤 요청이 왜 차단됐는지, 정상적인 업무가 불필요하게 막히지는 않았는지 살펴보면 보호 규칙과 운영 방식을 개선하는 데 도움이 됩니다.
사례 1. DeepSeek 노출 사례가 보여준 전송 전 데이터 보호
2025년 1월 29일, Wiz는 DeepSeek의 ClickHouse 데이터베이스가 별도의 인증 없이 외부에서 접근할 수 있는 상태였다고 공개했습니다. 노출된 100만 건 이상의 로그에는 대화 이력과 비밀 키, 내부 운영정보 등 민감한 내용이 포함돼 있었습니다. DeepSeek는 제보를 받은 뒤 해당 노출을 차단했습니다. 다만 여기서 100만 건은 로그 항목의 수를 의미합니다. 100만 명의 피해자가 발생했거나, 공격자가 노출된 데이터를 모두 탈취했다는 사실이 확인된 것은 아닙니다.
이 사례는 외부 AI에 보낸 정보가 답변 생성에 사용된 뒤에도 서비스의 처리 기록이나 로그에 남을 수 있다는 점을 보여줍니다. 기업은 AI 서비스 제공자의 보안 수준과 데이터 보관 방식을 살피는 동시에, 요청에 꼭 필요한 정보만 담아 보내는 기준을 마련할 필요가 있습니다. 예를 들어 고객 문의를 요약하는 데 연락처가 필요하지 않다면, 전송 전에 해당 정보를 가리거나 제외하는 방식입니다. AI가 업무를 수행하는 데 필요한 맥락은 유지하면서, 외부에 전달되는 민감한 원문을 줄이는 것이 핵심입니다.
1) 가려도 되는 정보와 보내지 말아야 할 정보를 구분한다
예를 들어 직원이 “담당자 demo@example.com에게 보낼 답장을 작성해 줘”라고 요청했다고 가정해 보겠습니다. 이메일 마스킹 규칙을 적용하면 실제 주소 대신 “[REDACTED_Email_1]”이라는 표기가 외부 모델에 전달됩니다. 답장 초안을 작성하는 데 이메일 주소가 꼭 필요하지 않다면, 업무는 그대로 진행하면서 외부로 보내는 개인정보를 줄일 수 있습니다.
인증정보처럼 외부로 보내면 안 되는 내용은 요청 자체를 차단하고, 사용자에게 그 이유를 안내합니다. 이때 회사에서 사용하는 비밀정보의 형식이나 기밀 문구를 규칙에 등록하고, 실제로 잘 걸러지는지 확인하는 과정이 필요합니다.
완성된 답변에 원래 값이 필요할 때는 해당 정보를 볼 권한이 있는 사용자에게만 복원해 보여줄 수 있습니다. 이 기능은 기본적으로 꺼져 있으며, 복원하더라도 외부 모델에 보낸 입력은 가려진 상태로 유지됩니다. 이전 요청에 포함된 값까지 복원하려면 플랫폼 연동과 별도의 권한 확인이 필요합니다.
이러한 보호는 정보가 외부로 나가기 전에 노출을 줄이는 데 목적이 있습니다. 외부 서비스의 데이터베이스 취약점까지 해결해 주는 것은 아닙니다. 따라서 개인정보를 가린 뒤에도 문맥에 기밀 내용이 남아 있다면, 전송을 차단하거나 승인된 내부 모델에서 처리하도록 기준을 마련해야 합니다.
사례 2. EchoLeak이 보여준 검색 문서와 대화 맥락의 위험
2025년 공개된 EchoLeak은 Microsoft 365 Copilot이 참고하는 이메일에 악성 지시를 숨겨, AI가 답변에 활용하던 내부정보를 외부로 보내도록 유도할 수 있었던 취약점입니다. 연구진은 사용자가 링크를 클릭하지 않아도 작동하는 공격 경로를 입증했습니다. 다만 공개 당시 고객 피해는 확인되지 않았으며, 실제 대규모 유출사고가 아닌 취약점 실증 사례로 구분해야 합니다.
이 사례는 사용자가 입력한 질문만 살펴보는 것으로는 충분하지 않다는 점을 보여줍니다. 평범한 질문에 답하는 과정에서도 AI는 외부 이메일이나 검색 문서를 참고하고, 그 안에 숨겨진 지시에 영향을 받을 수 있습니다. 따라서 질문뿐 아니라 AI가 참고하는 자료의 출처와 모델에 함께 전달되는 내용까지 살펴야 합니다.
1) 문서를 모델에 전달하기 전에 추출된 텍스트를 검사한다
사내 문서 검색 플랫폼을 Gateway에 연결하면, 검색한 문서 내용을 AI에 보내기 전에 AI Keeper의 보호 규칙을 적용할 수 있습니다. 플랫폼이 추출한 텍스트 중 검사 가능한 범위에서 고객정보나 기밀 문구를 찾아, 정책에 따라 전송을 차단하거나 민감한 부분을 가리는 방식입니다.
문서에서 텍스트를 추출하는 일은 플랫폼이, 추출된 내용을 검사하는 일은 AI Keeper가 맡습니다. 보호가 필수인 외부 AI 요청에서 검사할 수 없는 원본은 기본적으로 차단하고, 관리자가 명시적으로 허용한 예외만 처리하도록 설계돼 있습니다. 따라서 연동할 때는 지원하는 파일 형식뿐 아니라 텍스트 추출에 실패했을 때도 의도한 대로 작동하는지 확인해야 합니다.
이 구성은 외부 모델에 전달되는 민감정보를 줄이는 데 도움이 됩니다. 다만 패턴과 문구를 찾는 검사만으로 모든 악성 지시를 알아내거나 EchoLeak 공격 전체를 막을 수 있다고 보기는 어렵습니다. Microsoft 365 내부의 검색과 모델 호출, 외부 통신도 별도 연동 없이는 검사 대상이라고 가정할 수 없습니다. 취약점 수정과 문서별 접근권한 관리, 외부 전송 경로 통제를 함께 적용해야 하는 이유입니다.
사례 3. 개발 자동화 취약점이 보여준 도구 연결의 점검 지점
Google은 2026년 4월 24일, Gemini CLI와 run-gemini-cli의 보안 취약점과 대응 방법을 공개했습니다. 특정 자동 실행 설정에서는 도구의 세부 허용 목록이 제대로 적용되지 않아, 외부 입력에 숨겨진 악성 지시가 명령 실행으로 이어질 수 있었습니다. Google은 이를 수정한 버전과 함께 자동화 작업의 설정을 점검하는 지침을 제공했습니다.
관련 연구에서 Pillar Security는 이슈를 처리하는 AI가 인증정보에 접근하고, 다른 자동화 작업의 권한을 통해 공격 범위를 넓힐 수 있는 경로를 분석했습니다. 다만 전체 공격은 연구진 환경에서 재현됐으며, 일부 시스템 프롬프트의 제약을 완화한 조건도 포함됐습니다. 실제 배포 패키지가 악성 코드로 변조된 사고와는 구분해서 봐야 합니다.
이 사례는 AI가 외부 입력을 읽고, 도구를 호출하고, 그 결과를 다시 활용하는 전 과정을 살펴야 한다는 점을 보여줍니다. 사용자의 질문에는 비밀정보가 없더라도 도구가 가져온 결과에는 인증정보가 담겨 있을 수 있기 때문입니다. 따라서 처음 입력한 질문뿐 아니라 도구와 주고받는 내용에도 보호 기준을 적용해야 합니다.
1) Gateway를 거치는 도구 요청과 결과에 보호 규칙을 적용한다
AI Keeper와 MCP Gateway를 함께 구성하면, 등록된 업무 도구에 보내는 내용과 도구가 돌려주는 결과를 각각 검사할 수 있습니다. 예를 들어 도구의 조회 결과 중 검사 가능한 텍스트에서 등록된 인증정보 패턴이 발견되면, 다음 단계로 전달되기 전에 차단하거나 민감한 부분을 가리도록 설정하는 방식입니다.
이 보호는 도구 호출이 Gateway를 거칠 때 적용됩니다. 에이전트가 별도의 셸에서 파일을 읽거나 외부로 직접 통신하는 경로까지 자동으로 검사하는 것은 아닙니다. 업무 승인과 실제 도구 실행, 저장소 접근에 사용하는 인증정보의 권한 관리는 플랫폼과 업무 시스템에서 맡아야 합니다. 따라서 취약점을 수정하고 실행 권한을 필요한 범위로 제한하는 조치와 함께, Gateway를 통해 오가는 정보에도 보호 규칙을 적용하는 구성이 적절합니다.
내부 AI에서 외부 AI로 바뀌는 순간에도 같은 기준을 적용한다
같은 업무를 이어가더라도 사용하는 모델이 바뀌면 정보가 전달되는 곳도 달라질 수 있습니다. 내부 모델과 나눈 대화를 외부 모델로 이어갈 때는 새로 입력한 질문뿐 아니라 이전 대화와 참고 문서, 도구의 조회 결과까지 함께 전송될 수 있습니다.
AI Keeper는 이처럼 외부로 다시 보내는 내용에도 현재의 보호 규칙을 적용하도록 설계돼 있습니다. 내부 모델에서 사용했던 정보라도 외부에 보내기 전에는 다시 확인하는 것입니다. 외부 반출이 제한된 자료를 다루는 업무는 승인된 내부 모델만 사용하도록 연결 기준을 정할 수 있습니다.
관리자는 서비스별로 사용할 수 있는 모델과 접근 경로를 정하고, 회사 계정과 조직별 관리 기능을 연계해 운영할 수 있습니다. 다만 Gateway를 사내에 설치했다고 해서 모든 데이터가 내부에 머무는 것은 아닙니다. 외부 모델을 호출하면 정보가 외부로 전달될 수 있으므로, Gateway의 설치 위치와 함께 실제로 어떤 모델이 요청을 처리하는지도 확인해야 합니다.
감사는 보호 규칙을 개선하기 위한 운영 근거다
차단과 마스킹 규칙을 적용한 뒤에는 실제 업무에서 잘 작동하는지 살펴봐야 합니다. AI Keeper의 규칙 시험과 차단·마스킹 사유, 처리 건수를 확인하면 정상적인 요청이 불필요하게 막히는지, 보호할 정보를 놓치고 있는지 점검하고 규칙을 조정할 수 있습니다.
로그의 인증정보 때문에 요청이 자주 차단된다면 필요한 내용만 정리한 진단 자료를 보내도록 업무 방식을 바꿀 수 있습니다. 마스킹으로 분석에 필요한 맥락까지 사라진다면 승인된 내부 모델에서 처리하는 방법을 검토할 수 있습니다. 규칙을 완화하기 전에 어떤 정보가 왜 필요한지 먼저 확인하는 것입니다.
사고 조사에서는 AI Keeper의 보호 이력과 플랫폼·업무 시스템의 작업 및 실행 기록을 연결해 볼 수 있어야 합니다. 보호 이력만으로 모든 도구의 실행 과정을 확인할 수는 없기 때문입니다. 기록의 보관기간과 열람 권한, 민감한 원문의 저장 여부도 정해 감사 기록이 또 다른 정보 노출의 원인이 되지 않도록 관리해야 합니다.
사례별로 적용할 수 있는 보호 지점
|
사례
|
AI Keeper 보호 지점
|
함께 필요한 조치
|
|---|---|---|
|
DeepSeek 데이터 노출
|
모델 전송 전 패턴 차단 · 마스킹
허용된 내부 모델 이용
|
공급자 보안 검토
저장소 · 로그 접근 관리
|
|
EchoLeak 공격 실증
|
검색 문서에서 추출된 지원 텍스트 검사
외부 전송 문맥 보호
|
취약점 수정
문서 권한 · 외부 통신 통제
|
|
Gemini CLI 취약점
|
등록된 MCP 도구 요청 · 결과 검사
보호 정책 이력 확인
|
도구 패치·실행 권한 제한
Gateway 우회 경로 점검
|
안전한 AI 활용을 위한 첫걸음
도입을 검토할 때는 문서 질의응답이나 개발 오류 분석처럼 범위가 명확한 업무 하나부터 시작하는 것이 좋습니다. 모델에 전달되는 질문과 이전 대화, 조회 결과를 살펴보고, 보호할 정보의 형식과 문구를 정해 차단·마스킹 규칙을 시험합니다. 검사할 수 없는 입력이나 Gateway를 거치지 않는 외부 호출 경로도 함께 확인해야 합니다.
AI Keeper는 조직의 정보 보호 기준을 전송 과정에 적용하고, Gateway를 통해 여러 플랫폼이 같은 기준을 사용하도록 연결합니다. 실제 보호 효과는 어떤 경로와 입력을 검사할 수 있는지, 규칙이 업무에 얼마나 잘 맞는지에 달려 있습니다. 전송할 정보와 사용할 모델을 정하고 적용 결과를 꾸준히 살펴보는 것이 안전한 AI 활용의 기반이 됩니다.
