LLM이 일부라도 X라는 주체가 컨트롤할 수 있는 필드를 읽게 된다면, 그 LLM을 호출하는 에이전트도 기본적으로 X의 제어하에 있다고 간주해야 함을 강조함, 반증할 수 없는 한 이렇게 판단해야 하고, 에이전트의 권한도 X의 권한과 호출자의 현재 권한이 겹치는 부분으로 제한되어야 한다고 말함
만약 익명 사용자의 지원 티켓을 읽는다면, 익명 사용자에게 허용하지 않는 행동을 LLM에 허용해서는 안 됨
여러 사용자의 이메일을 읽는 경우 모두에게 허락되는 행동만 허용해야 함
더 유연하게 접근하고 싶다면 에이전트를 분리하고 위임하며 필터링하는 방식의 구조 설계를 제안함
하위 에이전트가 데이터를 읽고 정보 요청 또는 요청된 행동의 구조화된 리스트를 생성하게 하고, 이 하위 에이전트는 데이터를 제출한 사용자의 대리자로 간주해야 한다고 설명함
AI를 사용하지 않는 필터를 통해 해당 요청이 권한이 없는 요청은 모두 거부하도록 하며, 여기서 지시가 될 수 있는 어떤 데이터도 필터를 거치지 않고는 절대로 전달되어선 안 됨을 강조함
이 필터를 통해 들어오는 데이터는 엄격하게 구조화되고, 예를 들어 요청자가 정보 리스트를 요청하면 필터가 접근 제어 규칙을 반드시 검증해야 함
최종적으로, 메인 에이전트는 오직 이 필터링된 요청에 한해서만 동작해야 하며, 외부와의 상호작용은 오로지 필터를 거친 데이터만을 기준으로 해야 함
결국, 에이전트가 복수의 주체 사이에서 대리자 역할로 협상하는 본래 에이전트 개념으로 돌아가는 셈임
여기서 중요한 것은, 이 협상이 임의의 자연어 교환이 포함되어서는 안 된다는 사실을 받아들여야 함
위의 관점을 정확하게 설명했다고 생각함, 핵심을 잘 짚었다고 이야기함
모든 부분에 동의한다고 밝힘
단, 사측 비밀이 LLM의 사전 학습 데이터에서 외부 입력 없이 드물게라도 누출될 위험이 있는 지점에 대해서는 어떻게 생각해야 할지 질문함
이런 공격 벡터에 대해 LLM을 자체 학습시키더라도 훈련 데이터가 안전하다고 증명하기는 어렵다고 느끼며, 그렇다면 민감한 데이터 처리는 외부와 완전히 격리한 환경에서만 해야 하지 않냐고 제안함
결국 공개 데이터를 다루는 LLM, 민감한 데이터를 다루는 LLM을 각각 컨테이너 내에 격리해 운영해야 하고, 두 환경을 연결하려면 인간이 직접 통제해야 할지, 아니면 수학적으로 안전하게 연결할 방법이 있는지도 궁금함
taintllm이라는 개념이 필요하다고 간단하게 제안함 (참고: taint tracking이란 비신뢰 데이터의 흐름을 추적하는 보안 기법임)
하위 에이전트가 데이터를 읽고 요청을 구조화하는 건 결국 공격자가 탈출 방법만 익히면 되는 것임을 이야기함
이 방식은 마치 VM이나 jail에서 탈출하는 것과 비슷하며, 애초에 하위 에이전트는 신뢰하지 못하는 데이터를 다루므로 그 출력 역시 신뢰할 수 없음
결국 신뢰 못하는 데이터를 상위 AI에 전달하게 되어 버린다고 비판함
Neal Asher의 디스토피아 SF 소설을 읽는 것이 이런 세상에 대비하는 데 도움이 될 것 같다고 재치 있게 덧붙임
이것이 바로 "confused deputy 문제"임을 알림
capability 기반 보안 모델이 예전부터 대안으로 제시되어 왔지만 현실에서는 거의 쓰이지 않는 현실을 언급함
신뢰할 수 없는 사용자 입력을 없앨 수 없으므로, 시스템에서 "개인 데이터"와 "공용 커뮤니케이션" 양쪽 기능을 동시에 가져서는 안 된다고 강조함
의도 필터링 같은 "합리적 요청만 통과"하는 스마트 필터를 적용하면 안전할 거라 기대하는 생각은 아예 포기해야 하며, 실제로 그렇다 하더라도 정치적·시장적 이유로 이런 식 필터링을 만들겠다고 주장하는 사람들이 계속 있을 수밖에 없는 구조임
confused deputy 문제와 capability-based security 설명 링크 제공함 Confused Deputy Problem, Capability-based Security
핵심 원칙으로 문제를 접근한 방식이 훌륭하다고 평가함
주입 공격의 대부분의 설명은 오히려 불완전한 임시방편에 집착하도록 만들 뿐임을 지적함
여기서 제시한 것처럼 "치명적 삼위일체 원칙"이 깨지는 상황은 근본적으로 고칠 수 없다 생각하고, 깨뜨릴 경우에는 위험 분석과 완화 후 남은 최소한의 위험도 결국 받아들여야 한다고 봄
신입 개발자들과 vibe coder들이 만든 API에서의 SQL 및 데이터베이스 커맨드 인젝션 문제를 여전히 고치고 있는 중이라고 밝힘
ITT/TTI, TTS/STT(아마도 입력→텍스트, 텍스트→음성 관련 변환) 보호가 특히 번거로웠으며, 이런 벡터들에 대한 완전한 보안 체계를 갖추기까지 아직 멀었다고 느낌
각 소스 코드 모델별로 SQL 인젝션을 탐지하는 프롬프트를 작성하는 방법이나, 또는 다른 보안 이슈를 발견하는 프롬프트를 만들라고 제안함
최근 생각해본 아이디어로, instruction following과 관련된 벡터를 제어하고 신뢰할 수 없는 데이터를 주입할 때 해당 벡터를 억제한다면 LLM이 정보를 인지하되 직접 행동에 옮기지 않을 수 있다고 설명함
이 억제의 스위칭 여부는 전처리기가 따옴표 등 구분자를 분석해서 판단할 수도 있고, 더 확실한 방법은 placeholde가 포함된 prepared statement 같은 구조를 쓰는 것이라고 제안함
이 방식이 잘 작동한다면 AI가 여전히 신뢰할 수 없는 데이터에 노출되더라도, 위험한 형태로 이 데이터를 실행하는 일은 방지할 수 있다고 생각함
Perplexity Comet과 Dia 같은 서비스들은 왜 이런 데이터 유출 문제에서 자유로운지 궁금하다며, 요즘 브라우저 히스토리, 웹데이터, LLM을 한데 섞는 등 lethal trifecta 원칙을 완전히 위배하는 것처럼 보인다고 지적함
아무도 이들을 아직 뚜렷하게 공격해보지 않았을 수도 있다고 답함
실제로 이미 공격이 시도됐을 수도 있지만, 그걸 사용자가 알 방도가 없고, 예를 들어 1x1 픽셀 이미지 요청이나 의심스런 네트워크 트래픽 같은 것을 감시하지 않는다면 확인하기 어려울 것임
Dia는 최근 기준 이와 같은 데이터 유출 방식에 취약하지 않은 구조를 갖췄다고 밝혔으며, 자세한 내용은 NDA로 보호될 수 있음을 명시함
본인의 개인 의견임을 덧붙임
발표 내용 정리 작성이 상당한 수고가 드는 일 같지만, 이런 기록이 영상 링크보다 더 오래가는 가치가 있어서 매우 고맙게 느낀다고 이야기함
인기 있는 MCP server/agent 툴셋에서 치명적 삼위일체(trifecta) 문제를 생각보다 훨씬 자주 접한다고 밝힘
위협 모델링 연습에 관심 있는 사람에게, mcp-scan이라는 툴이 관련 시나리오 분석 기능을 지원한다며 독성 흐름 분석(toxic flow analysis) 및 mcp-scan 링크를 공유함
이번 이슈가 계기가 돼서 capability 기반 보안을 채택하는 OS 도입이 늘어날 거란 기대를 보임
런타임에서 프로그램별로 화이트리스트 제공을 요구하면 현재 수준에서는 거의 완벽한 보안책이 될 수 있다고 생각함
믿을 수 있는 출처에서 부트 미디어로 capability 기반 OS를 설치하고, 대부분의 앱이 별문제 없이 잘 실행되며, GUI 경험도 바로 가능하냐고 실제 사용성 측면에서 질문함
audit2allow(SELinux 용 자동 권한 관리 툴)처럼 편의성 도구만 쓰고 실제로는 최소 권한 지정을 소홀히 해 공격면을 넓힐 가능성에 대한 우려를 이야기함 audit2allow 설명
이러한 형태의 보안도 좋긴 하지만, 필요한 권능(권한)이 실제 악의적·사기성 행위와 겹칠 경우 모든 위험을 예방할 수는 없음
직접 녹음해본 적 있거나 실제로 capability 기반 시스템을 써본 이가 있냐고 질문함
사람의 입장에서는 이런 시스템이 악몽에 가깝다고 생각하며, 이미 현대 OS에서도 "관리자 암호를 입력하세요" 등 빈번한 권한 승격 요청 때문에 다들 무감각해졌음
$프로그램이 $권한을 요구하는 식의 팝업에 반복적으로 시달리고, 막상 거부하면 앱이 실행되지 않는 불편함을 토로함
웹사이트 위치 추적·쿠키 허용 등도 모두 이런 문제의 연장선이라고 보고, 실제로 하늘 보기 웹사이트가 자신의 위치를 IP로 파악한 경험을 예로 듦
Mac IDE의 설치에도 관리자 권한이 필요한지 의문을 제기하며, capability 기반 시스템이 이론상 좋아 보여도 실제 사용성은 걱정된다고 생각함
Hacker News 의견
LLM이 일부라도 X라는 주체가 컨트롤할 수 있는 필드를 읽게 된다면, 그 LLM을 호출하는 에이전트도 기본적으로 X의 제어하에 있다고 간주해야 함을 강조함, 반증할 수 없는 한 이렇게 판단해야 하고, 에이전트의 권한도 X의 권한과 호출자의 현재 권한이 겹치는 부분으로 제한되어야 한다고 말함
만약 익명 사용자의 지원 티켓을 읽는다면, 익명 사용자에게 허용하지 않는 행동을 LLM에 허용해서는 안 됨
여러 사용자의 이메일을 읽는 경우 모두에게 허락되는 행동만 허용해야 함
더 유연하게 접근하고 싶다면 에이전트를 분리하고 위임하며 필터링하는 방식의 구조 설계를 제안함
하위 에이전트가 데이터를 읽고 정보 요청 또는 요청된 행동의 구조화된 리스트를 생성하게 하고, 이 하위 에이전트는 데이터를 제출한 사용자의 대리자로 간주해야 한다고 설명함
AI를 사용하지 않는 필터를 통해 해당 요청이 권한이 없는 요청은 모두 거부하도록 하며, 여기서 지시가 될 수 있는 어떤 데이터도 필터를 거치지 않고는 절대로 전달되어선 안 됨을 강조함
이 필터를 통해 들어오는 데이터는 엄격하게 구조화되고, 예를 들어 요청자가 정보 리스트를 요청하면 필터가 접근 제어 규칙을 반드시 검증해야 함
최종적으로, 메인 에이전트는 오직 이 필터링된 요청에 한해서만 동작해야 하며, 외부와의 상호작용은 오로지 필터를 거친 데이터만을 기준으로 해야 함
결국, 에이전트가 복수의 주체 사이에서 대리자 역할로 협상하는 본래 에이전트 개념으로 돌아가는 셈임
여기서 중요한 것은, 이 협상이 임의의 자연어 교환이 포함되어서는 안 된다는 사실을 받아들여야 함
위의 관점을 정확하게 설명했다고 생각함, 핵심을 잘 짚었다고 이야기함
모든 부분에 동의한다고 밝힘
단, 사측 비밀이 LLM의 사전 학습 데이터에서 외부 입력 없이 드물게라도 누출될 위험이 있는 지점에 대해서는 어떻게 생각해야 할지 질문함
이런 공격 벡터에 대해 LLM을 자체 학습시키더라도 훈련 데이터가 안전하다고 증명하기는 어렵다고 느끼며, 그렇다면 민감한 데이터 처리는 외부와 완전히 격리한 환경에서만 해야 하지 않냐고 제안함
결국 공개 데이터를 다루는 LLM, 민감한 데이터를 다루는 LLM을 각각 컨테이너 내에 격리해 운영해야 하고, 두 환경을 연결하려면 인간이 직접 통제해야 할지, 아니면 수학적으로 안전하게 연결할 방법이 있는지도 궁금함
taintllm이라는 개념이 필요하다고 간단하게 제안함 (참고: taint tracking이란 비신뢰 데이터의 흐름을 추적하는 보안 기법임)
하위 에이전트가 데이터를 읽고 요청을 구조화하는 건 결국 공격자가 탈출 방법만 익히면 되는 것임을 이야기함
이 방식은 마치 VM이나 jail에서 탈출하는 것과 비슷하며, 애초에 하위 에이전트는 신뢰하지 못하는 데이터를 다루므로 그 출력 역시 신뢰할 수 없음
결국 신뢰 못하는 데이터를 상위 AI에 전달하게 되어 버린다고 비판함
Neal Asher의 디스토피아 SF 소설을 읽는 것이 이런 세상에 대비하는 데 도움이 될 것 같다고 재치 있게 덧붙임
이것이 바로 "confused deputy 문제"임을 알림
capability 기반 보안 모델이 예전부터 대안으로 제시되어 왔지만 현실에서는 거의 쓰이지 않는 현실을 언급함
신뢰할 수 없는 사용자 입력을 없앨 수 없으므로, 시스템에서 "개인 데이터"와 "공용 커뮤니케이션" 양쪽 기능을 동시에 가져서는 안 된다고 강조함
의도 필터링 같은 "합리적 요청만 통과"하는 스마트 필터를 적용하면 안전할 거라 기대하는 생각은 아예 포기해야 하며, 실제로 그렇다 하더라도 정치적·시장적 이유로 이런 식 필터링을 만들겠다고 주장하는 사람들이 계속 있을 수밖에 없는 구조임
confused deputy 문제와 capability-based security 설명 링크 제공함
Confused Deputy Problem, Capability-based Security
핵심 원칙으로 문제를 접근한 방식이 훌륭하다고 평가함
주입 공격의 대부분의 설명은 오히려 불완전한 임시방편에 집착하도록 만들 뿐임을 지적함
여기서 제시한 것처럼 "치명적 삼위일체 원칙"이 깨지는 상황은 근본적으로 고칠 수 없다 생각하고, 깨뜨릴 경우에는 위험 분석과 완화 후 남은 최소한의 위험도 결국 받아들여야 한다고 봄
신입 개발자들과 vibe coder들이 만든 API에서의 SQL 및 데이터베이스 커맨드 인젝션 문제를 여전히 고치고 있는 중이라고 밝힘
ITT/TTI, TTS/STT(아마도 입력→텍스트, 텍스트→음성 관련 변환) 보호가 특히 번거로웠으며, 이런 벡터들에 대한 완전한 보안 체계를 갖추기까지 아직 멀었다고 느낌
최근 생각해본 아이디어로, instruction following과 관련된 벡터를 제어하고 신뢰할 수 없는 데이터를 주입할 때 해당 벡터를 억제한다면 LLM이 정보를 인지하되 직접 행동에 옮기지 않을 수 있다고 설명함
이 억제의 스위칭 여부는 전처리기가 따옴표 등 구분자를 분석해서 판단할 수도 있고, 더 확실한 방법은 placeholde가 포함된 prepared statement 같은 구조를 쓰는 것이라고 제안함
이 방식이 잘 작동한다면 AI가 여전히 신뢰할 수 없는 데이터에 노출되더라도, 위험한 형태로 이 데이터를 실행하는 일은 방지할 수 있다고 생각함
Perplexity Comet과 Dia 같은 서비스들은 왜 이런 데이터 유출 문제에서 자유로운지 궁금하다며, 요즘 브라우저 히스토리, 웹데이터, LLM을 한데 섞는 등 lethal trifecta 원칙을 완전히 위배하는 것처럼 보인다고 지적함
아무도 이들을 아직 뚜렷하게 공격해보지 않았을 수도 있다고 답함
실제로 이미 공격이 시도됐을 수도 있지만, 그걸 사용자가 알 방도가 없고, 예를 들어 1x1 픽셀 이미지 요청이나 의심스런 네트워크 트래픽 같은 것을 감시하지 않는다면 확인하기 어려울 것임
Dia는 최근 기준 이와 같은 데이터 유출 방식에 취약하지 않은 구조를 갖췄다고 밝혔으며, 자세한 내용은 NDA로 보호될 수 있음을 명시함
본인의 개인 의견임을 덧붙임
발표 내용 정리 작성이 상당한 수고가 드는 일 같지만, 이런 기록이 영상 링크보다 더 오래가는 가치가 있어서 매우 고맙게 느낀다고 이야기함
annotated-presentations 도구 소개, 도구 사용 링크
인기 있는 MCP server/agent 툴셋에서 치명적 삼위일체(trifecta) 문제를 생각보다 훨씬 자주 접한다고 밝힘
위협 모델링 연습에 관심 있는 사람에게, mcp-scan이라는 툴이 관련 시나리오 분석 기능을 지원한다며
독성 흐름 분석(toxic flow analysis) 및
mcp-scan 링크를 공유함
이번 이슈가 계기가 돼서 capability 기반 보안을 채택하는 OS 도입이 늘어날 거란 기대를 보임
런타임에서 프로그램별로 화이트리스트 제공을 요구하면 현재 수준에서는 거의 완벽한 보안책이 될 수 있다고 생각함
믿을 수 있는 출처에서 부트 미디어로 capability 기반 OS를 설치하고, 대부분의 앱이 별문제 없이 잘 실행되며, GUI 경험도 바로 가능하냐고 실제 사용성 측면에서 질문함
audit2allow(SELinux 용 자동 권한 관리 툴)처럼 편의성 도구만 쓰고 실제로는 최소 권한 지정을 소홀히 해 공격면을 넓힐 가능성에 대한 우려를 이야기함
audit2allow 설명
이러한 형태의 보안도 좋긴 하지만, 필요한 권능(권한)이 실제 악의적·사기성 행위와 겹칠 경우 모든 위험을 예방할 수는 없음
직접 녹음해본 적 있거나 실제로 capability 기반 시스템을 써본 이가 있냐고 질문함
사람의 입장에서는 이런 시스템이 악몽에 가깝다고 생각하며, 이미 현대 OS에서도 "관리자 암호를 입력하세요" 등 빈번한 권한 승격 요청 때문에 다들 무감각해졌음
$프로그램이 $권한을 요구하는 식의 팝업에 반복적으로 시달리고, 막상 거부하면 앱이 실행되지 않는 불편함을 토로함
웹사이트 위치 추적·쿠키 허용 등도 모두 이런 문제의 연장선이라고 보고, 실제로 하늘 보기 웹사이트가 자신의 위치를 IP로 파악한 경험을 예로 듦
Mac IDE의 설치에도 관리자 권한이 필요한지 의문을 제기하며, capability 기반 시스템이 이론상 좋아 보여도 실제 사용성은 걱정된다고 생각함
이와 같은 낙관론에 동의하기 어렵다고 정중하게 의견을 밝힘