▲

AI의 "치명적인 삼중 위협"을 막는 방법

 (economist.com)
7P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • LLM은 코드와 데이터를 분리하지 못하는 구조적 문제를 가지고 있어 프롬프트 인젝션 공격에 취약함
  • 특히 외부 데이터 접근·내부 비밀 열람·외부 통신 권한이 동시에 주어지면, 이른바 치명적 삼합(lethal trifecta) 이 발생하여 심각한 피해로 이어질 수 있음
  • AI 엔지니어들은 기계 공학자처럼 사고해야 하며, 결정론적 접근 대신 확률적 시스템의 불확실성을 받아들이고 안전 여유를 두는 방식 필요
  • 빅토리아 시대 엔지니어들이 재료의 불확실성에 대비해 과잉 설계로 여유를 뒀듯이, AI 시스템도 안전 한계, 위험 허용도, 오류율을 도입해야 함
  • 물리적 세계의 다리에 하중 제한이 있듯이, AI 시스템에도 명시적 한계와 안전 여유를 두는 규범이 필요한 시점임

LLM의 본질적 보안 문제

  • 대형 언어 모델은 코드와 데이터를 분리할 수 없는 구조적 결함 보유
  • 이로 인해 프롬프트 인젝션 공격에 취약
    • 시스템이 따르지 말아야 할 명령을 따르도록 속임
    • 경우에 따라 고객 지원 에이전트가 해적처럼 말하게 만드는 등 단순히 당황스러운 결과 초래
    • 다른 경우에는 훨씬 더 파괴적인 피해 발생

치명적 삼합(Lethal Trifecta)

  • 최악의 영향은 "치명적 3요소" 를 만들 때 발생
  • 3요소의 구성
    • 신뢰할 수 없는 데이터에 대한 접근 권한
    • 중요한 기밀 정보를 읽을 수 있는 능력
    • 외부 세계와 통신할 수 있는 능력
  • 기업이 직원들에게 강력한 AI 어시스턴트를 제공하려다 이 세 가지를 동시에 부여하면 심각한 문제 발생 불가피
  • AI 엔지니어뿐만 아니라 일반 사용자도 안전한 AI 사용법을 배워야 함
    • 잘못된 앱 조합을 설치하면 우연히 3요소가 생성될 수 있음

AI 엔지니어의 사고방식 전환 필요

기계 공학자처럼 사고하기

  • 더 나은 AI 엔지니어링이 최우선 방어선
  • AI 엔지니어들은 다리 같은 구조물을 만드는 엔지니어처럼 생각해야 함
    • 부실한 작업이 인명을 앗아간다는 것을 인식

빅토리아 시대 엔지니어링의 교훈

  • 빅토리아 시대 영국의 위대한 건축물들은 재료 특성을 확신할 수 없는 엔지니어들이 건설
    • 당시 철은 무능력이나 부정행위로 인해 종종 품질이 낮음
    • 결과적으로 엔지니어들은 신중함을 택하고 과잉 설계로 중복성을 통합
    • 그 결과 수세기를 견딘 걸작들 탄생

현재 AI 보안 업계의 문제

  • AI 보안 제공업체들은 이런 식으로 생각하지 않음
  • 기존 코딩은 결정론적 관행
    • 보안 취약점은 수정해야 할 오류로 간주
    • 수정하면 사라짐
  • AI 엔지니어들은 학창 시절부터 이런 사고방식에 익숙
    • 따라서 더 많은 훈련 데이터와 더 영리한 시스템 프롬프트만으로 문제를 해결할 수 있다고 행동

확률적 시스템에 맞는 접근 방식

훈련 데이터와 프롬프트의 한계

  • 훈련 데이터와 영리한 프롬프트는 위험을 줄이기는 함
    • 가장 똑똑한 최신 모델들은 악의적 요청을 발견하고 거부하는 데 이전 또는 소형 모델보다 우수
  • 하지만 위험을 완전히 제거할 수는 없음
    • 대부분의 소프트웨어와 달리 LLM은 확률적
    • 출력은 가능성 있는 응답 중 무작위 선택에 의해 결정됨
    • 따라서 결정론적 안전 접근 방식은 부적절

물리적 세계 엔지니어링 모방

  • 더 나은 방법은 물리적 세계의 엔지니어들을 모방하는 것
  • 예측 불가능한 시스템과 함께 작업하는 법 학습
    • 의도대로 작동한다고 보장할 수 없는 변덕스러운 시스템과 대항하기보다는 함께 작업
  • 안전 여유, 위험 허용도, 오류율을 도입하여 예측 불가능성을 더 편안하게 다루기

AI 시대의 과잉 설계 전략

  • 필요한 것보다 더 강력한 모델 사용
    • 부적절한 행동을 하도록 속임당할 위험 감소
  • 외부 소스로부터 LLM이 받을 수 있는 쿼리 수 제한 부과
    • 악의적 쿼리로 인한 피해 위험에 맞춰 조정
  • 안전한 실패 강조
    • AI 시스템이 기밀에 접근해야 한다면 왕국의 열쇠를 건네는 것은 피해야 함

안전 한계 설정의 필요성

  • 물리적 세계에서 다리에는 하중 제한이 있음
    • 운전자에게 항상 명확히 표시되지는 않더라도 존재
    • 중요한 점: 이러한 제한은 계산상 다리가 견딜 수 있다고 제시하는 실제 허용 범위 내에 충분히 여유를 둠
  • 이제 AI 시스템의 가상 세계도 유사하게 갖춰질 시점
  • 명확한 안전 한계와 여유를 가진 시스템 설계가 필수
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 아카이브 기사 링크
  • 이번 주에 lethal trifecta를 언급한 Economist 기사 중 두 번째임. 첫 번째는 AI 시스템은 결코 완전히 안전하지 않다 — 대응해야 할 ‘치명적 삼중 위협’로, 미디어에서 prompt injection이 무엇이고 왜 위험한지 가장 명확히 설명함을 봤음. 내가 인용된 부분도 있으니 약간은 편파적일 수 있지만, 경영진에게 꼭 추천하는 기사임. 이번 새 기사는 별로 선호하지 않음. LLM이 비결정적이라서 보안 취약점을 수정하기 어렵다고 언급하는데, 그래서 마치 다리처럼 ‘오버엔지니어링’하고 허용오차에 대비해야 한다고 하는 비유를 씀. 다리라면 맞을 수 있지만, 보안 취약점에는 근본적인 해결책이 아니라고 봄. 만약 시스템이 100번 중 1번만 prompt injection에 당해도 공격자는 끝까지 변종 공격을 시도할 것임. lethal trifecta(비공개 데이터 접근, 불신 명령 노출, 외부 유출 경로) 중 어느 하나라도 차단하면 공격이 성립하지 않음
    • 다리 건설자는 대부분 적대적 공격에 대비해서 설계하지 않음. 혹시 대비하더라도, 견고하게 만드는 것보다 옮기기 쉽고 빨리 재배치할 수 있는 쪽에 집중함. 폭격에도 남는 튼튼한 다리보다, 일시적인 다리 하나 더 놓는 게 더 빠르고 저렴함. 구체 사례 참고
    • LLM은 인간과 마찬가지로 비결정적임. 그래서 보안 관리도 인간처럼 접근하면 됨. 필요한 역할 기반 접근 통제로 최소한의 권한만 주고, 위험하거나 비용이 큰 작업은 승인 프로세스를 거치도록 해야 함. 기술, 인프라, 방위, 금융 등 주요 조직이라면 러시아, 중국, 이스라엘, 북한 등 외국 정부의 요원이 팀에 섞여 있다는 전제로 위협 모델을 잡는 게 기본임
    • 사실 두 기사 모두 같은 기사임. Economist에서는 매주 발간호 앞부분에 “Leaders”라는 기사 시리즈를 실어서, 같은 호에 실린 심층 기사들을 축약/일반화함. 즉, 신문 전체에 역피라미드식 구성(역피라미드 설명)을 적용하는 셈임. 이번에도 링크된 기사가 그 문제 기사 전체의 요약판 같은 역할을 함
    • LLM의 보안 문제를 ‘만약 내 코드가 사회공학 공격에 뚫릴 수 있다면?’으로 생각함. LLM은 인간과 비슷하게, 아무리 훈련해도 속을 수밖에 없음. 컴퓨터에 루트 권한을 준 뒤 전 세계 누구나 LLM과 대화하도록 허용한다면, 결국 취약해질 수밖에 없음. 인간에게 무제한 권한을 위임하지 않듯이, LLM에도 요청자와 연관 없는 데이터 접근, 사용자 데이터 변경 등은 허용하지 않는 게 맞음
    • lethal trifecta 중 한쪽만 잘라도 된다는 게 문제임. 사실 이 세 요소는 서로 얽혀 있음. 예를 들어 이메일처럼 외부 콘텐츠도 개인 정보에 해당할 수 있고, 이메일을 보내면 내 인박스의 내용이 공격자에게 넘어갈 수도 있음. 그리고 이메일, GitHub 등은 송수신이 모두 가능할 때 제일 유용한데, 각 기능마다 전용 서버를 따로 두는 건 비효율적임
  • 기계공학 배경으로 볼 때, 이 기사는 불충분하다고 느낌. ‘강도를 더하면 된다’는 말이 흔하지만, 실제론 다양한 실패 모드를 세세히 이해해야 적용함. lethal trifecta도 하나의 실패 모드일 뿐, 그걸 막기 위해 ‘강도’를 넣음. ‘이 다리는 너무 진동한다 → 진동하는 다리를 안전하게 건너는 법을 고민하자’가 아니라, 다리를 아예 과도하게 진동하지 않도록 변경함이 맞음
    • 세상이 미쳐 돌아간다고 느낌. 저 다리 비유대로라면, 예전부터 다리 건설 기술이 있지만 아주 가끔 바닥이 갑자기 사라져 사람들이 강물로 떨어지는 현상이 생기고, 그래도 ‘다른 방법을 고민하자’는 논의 대신 ‘밑에 그물 치고, 다 떨어지면 잡자’는 식임. 우리는 본질적으로 예측 불가한 기술 위에 수십억을 쏟아 붓고 있다가, 단순히 가드레일만 더 추가하는 식임. 정말 말이 안 됨
    • 기사에 ‘coders need to’란 문구 나오면 바로 흥미를 잃음. 비유 자체가 잘못된 느낌이고, 실제 분야 경험자에게도 어색한 것처럼 들림. 기자가 예시로 든 ‘회사에서 LLM이 불신 데이터, 중요한 정보, 외부와의 통신 모두 동시에 가능하게 하면’이라는 조건 자체가 문제임. 회사가 보안보다 기능을 우선시해서 이런 위험을 만들어내는 경우가 많음. ‘LLM은 비확률적이라 결정론적 접근이 부적절’하다는 주장은 논리 비약임. 비결정적이라도 샌드박스 논리가 여전히 유효하고, 바꿔 말하면 비유를 너무 끌고 가다 보면 오히려 해당 분야에 도움이 안 됨. 관련 용어와 도메인 지식을 쓰는 게 낫겠지만, 그럼 기사로써 매력이 없을 테니 어렵겠음
  • 설마 기사에선 단순히 속도 제한과 더 나은 모델 사용만이 해결책이라 했던 건가? 소프트웨어 엔지니어들은 이미 수십 년 전 이런 걸 연구함. 이 업계는 보안에 대해 답을 알고 있는데, AI 제품을 급히 내놓는 현재 태도와 어울리지 않아서 문제임
    • AI도 이제 같은 IT 분야인데, 그렇다면 결론적으로 ‘우리는 보안을 이해한 게 아니다’임. AI에 careless하단 건 사실과 다름. 데이터와 명령 토큰을 완벽히 분리할 방법이 없다는 건 근본적 한계지 부주의 탓이 아님. ‘수십 년 전에 다 알아냈다’는 건 오만임
    • ‘수십 년 전 보안을 다 해결했다’는 식의 발언은, 신규 산업이 기존의 나쁜 표준을 다시 만들어서 ‘AI 제품’을 내놓는 데 급급할 때 발생하는 현상임. MCP 표준 같은 것들이 처음부터 뚫렸던 사례만 봐도, ‘프롬프트 잘 쓰기’ 같은 접근은 우스울 지경임. 가장 큰 문제는 AI 산업 내 거의 모든 사람이 MCP 서버가 DB에 직접 접근하는 걸 별 의심 없이 설계했다는 점임. 가능하다고 해서 반드시 해야 하는 게 아님을 보여주는 사례로, 이렇게 허술한 보안 탓에 수많은 AI 제품이 실제로 침해되고 있음
    • ‘우리는 이미 보안을 알고 있다’란 주장은 실제론 사실이 아님. 인간 문제로 넘어오면 더욱 그렇고, 수십억을 들여 반복 교육해도 점점 효과가 떨어지는 구조임. 최근 들어서도 뛰어난 보안 전문가조차 유튜브에서 간단한 피싱에 속았던 사례가 나옴
  • 원본 @simonw 글: The lethal trifecta for AI agents, 관련 추가 글 도 참고 가능. HN 내 관련 토론 링크도 함께 남김
  • lethal trifecta란 LLM이 불신 데이터 접근, 중요한 정보 열람, 외부 통신 세 가지를 동시에 할 때 발생하는 문제임. 해결책은 경계(권한) 관리로 위험을 낮추라는 것인데, 아주 기본적인 보안 101 수준임
    • 맞지만 실제론 보안과 기능 사이에 큰 긴장관계가 생김. 개인 데이터로 유용한 일을 하려면 prompt injection 취약점이 열려버림. 또, 이렇게 연관된 맥락을 최대한 합치는 게 에이전트 효율에는 효과적이지만, 그렇다고 불신 입력 읽는 에이전트를 완전히 분리/격리하면 오히려 효용성 저하됨. 관련 블로그 참고
    • 이것도 엄밀히 말하면 기본적인 접근 제어(Access Control)일 뿐임. 인터넷에 연결되는 순간 위험은 급증함. 뛰어난 보안 연구자가 있다면 단 하나의 prompt injection만으로도 시스템 전체를 장악할 수 있어 조건 중 최소 한 가지는 바로 충족하게 만듦
  • LLM은 prompt와 데이터를 구분하지 않음. NX bit(실행 금지 비트)와 같은 개념도 없고, 이와 비슷한 걸 구현한 사례도 없음. 물론 NX bit가 도입되어도 원격 코드 실행을 완전히 막지 못했던 것처럼, 이것만으론 완벽한 대응이 안 됨. 현재 가장 현실적인 방법은 기존 보안 메커니즘으로 LLM 에이전트 프로세스를 관리하는 것임. 예를 들어 별도 사용자 계정으로 실행해 파일 접근을 제한하고, 네트워크, 하드웨어, cgroups를 통한 제한도 더함. 그래도 불신 데이터에 명령이 섞이면, LLM이 비밀 데이터까지 내보내는 위험은 여전함. 그리고 사용자가 LLM 출력물을 인지하지 못하고 외부에 복사하면 탈취 경로가 다시 열림
    • ‘이와 비슷한 걸 만들어낸 사람이 없다고 하는데, 진짜 시도조차 한 사람이 있는지, 관련 훈련 데이터라도 있는지 궁금함. 사회적 동물은 자연스럽게 compartmentalization(구획화)을 함. 개도 사람의 눈치를 보며 식량의 존재를 감추기도 함. 나도 아이를 키우면서, 사회생활, 기밀 지식, 아이의 개인정보, 아이가 아직 받아들이기 힘든 정보, 내 속마음, 신뢰할 수 없는 출처에서 배운 내용 등에 따라 정보를 모두 구분해서 관리함. 지능도 중요하지만 지혜(wisdom)야말로 아직 LLM 영역에선 1급 고려사항이 아님. 강아지와 유아조차 구획화 능력이 앞서고 있는 상황임
  • 관련 심층 기사에서 인상적인 인용구를 봤음: 구글이 제안한 CaMeL 시스템은 두 개의 LLM을 활용해 lethal trifecta의 일부 위험을 회피함. 하나는 불신 데이터에만 접근, 또 다른 하나는 다른 모든 데이터를 처리함. 신뢰성 높은 모델이 사용자의 언어 명령을 제한된 범위의 코드로 바꾸고, 불신 모델은 해당 코드의 빈칸을 채움. 이 구조로 보안 보장은 주지만, 그만큼 LLM이 할 수 있는 업무 범위에 큰 제약이 생김. 처음 들어봤는데 실제로 효과가 궁금함. 진짜 ‘절대적’인 보안이 보장되는지, 어떤 제약조건이 발생하는지, 실질적 대안이 될 수 있을지 궁금함. 기사 출처
    • CaMeL 논문에 대해 내가 오래 고민한 적이 있음. 꽤 괜찮은 접근 방식이지만, 실제 구현이 상당히 어렵고 시스템이 상당히 제한된 기능만 할 수 있음. 내 분석 글에 정리해둠
  • “AI 엔지니어들도 다리 건설 등 인명 피해로 이어질 수 있는 분야의 진짜 엔지니어처럼 사고해야 한다”는 비유가 나옴. “AI 엔지니어는 학교 때부터 이런 사고방식이 길들여져, 단순히 더 많은 훈련 데이터와 똑똑한 prompt만 있으면 문제 해결이 된다고 믿는다”라는 식임
    • 여기서 ‘AI 엔지니어는 실제 엔지니어처럼 생각해야 한다’는 건, 그냥 소프트웨어 엔지니어가 아니라 진짜 엔지니어처럼, 지금은 소프트웨어가 다리나 자동차에도 들어가 있으니 적어도 실물 엔지니어의 사고법을 갖춰야 한다는 의미임
    • 마치 소프트웨어 엔지니어링 자격증, 윤리 인증까지 받아야 한다는 제안을 암시함. 하지만 비윤리적이지만 합법적인 소프트웨어가 아주 높은 수익을 만들어내는 만큼, 이런 아이디어는 실제 적용되기 어렵다고 느낌
    • ‘더 나은 훈련 데이터만 있으면 해결된다’는 생각의 결론은, 결국 이런 비극적 피해 자체가 훈련 데이터가 된다는 것임
    • 소프트웨어 ‘엔지니어’뿐 아니라 ‘아키텍트’의 역할도 잊지 말아야 함
  • LLM 계정을 자동 모니터링하고 입력을 필터링/파이프라인 처리해 주는 소프트웨어 상품을 소정 요금의 구독 서비스로 운영하면 비즈니스 기회가 있지 않을까 하는 생각임
답변달기