한 문장이 에이전트의 기억을 탈취했습니다. 그래서 모든 기억을 감사 가능하게 만들었습니다.

이번 주에 읽은 글은 불편했고, 제목 자체가 근본적인 문제였습니다. 단어 하나인 '업데이트(update)'가 적절한 맥락 속에서 에이전트의 기억을 탈취하기에 충분했습니다. 이는 익스플로잇 체인이 아닙니다. 단순히 표현 방식일 뿐입니다. 에이전트는 입력이 그렇게 하라고 지시했기 때문에 자신이 믿는 것을 재작성했고, 그 과정에서 어떤 것도 '아니오'라고 말할 수 없었습니다.

cover

본능적으로 이것을 프롬프트 인젝션(prompt injection)으로 분류하고 지나치려 합니다. 하지만 이는 중요한 절반을 놓치는 것입니다. 인젝션은 입력(input)의 문제입니다. 이 글이 실제로 폭로한 것은 저장소(storage)의 문제입니다. 에이전트가 믿는 것이 열 수 없는 상자 안에 존재한다면, 지난주에 읽은 오염된 문장 하나가 이후 모든 세션을 조용히 형성합니다. 재작성된 신념을 볼 수 없고, 어떤 입력이 그것을 재작성했는지 추적할 수 없으며, 되돌릴 수도 없습니다.

제가 대응하기 위해 구축한 것이 바로 이러한 실패 모드(failure mode)입니다. HyperMarrow는 Windows용 에이전트의 로컬 우선 메모리 레이어이며, 아래 속성들은 제가 강제하는 것들입니다. 이들은 작동 시기가 빠른 순서로 배열되었는데, 왜냐하면 위의 모든 실패는 쿼리 시간(query time)이 아니라 쓰기 시간(write time)에 결정되기 때문입니다.

1. 결정은 출처와 타임스탬프를 포함하여 기록되어야 합니다

선호도, 결정 또는 결론은 어디서 왔는지, 그리고 언제였는지를 담아 실제 기록으로 영구적인 로컬 저장소에 남아야 합니다. 매 턴마다 대화록(transcript)에서 재파생되는 가정은 주소가 없고, 출처가 없으며, 이력도 없습니다. 일단 기록이 출처(provenance)를 갖게 되면, '무엇을 믿고 왜 그렇게 생각하는지'는 논쟁거리가 아니라 조회 가능한 정보가 됩니다.

2. 압축하기 전에 쓰기(Write before you compact)

아티팩트가 영구적인 사본이 존재하고 확인될 때까지는 작업 컨텍스트(working context)를 요약하거나 버리는 것이 허용되지 않습니다. 이것은 쓰기 전 규칙(write-ahead rule)이며, 다섯 가지 중 가장 먼저 작동합니다. 만약 압축(compaction)이 먼저 실행되면, 그것이 버린 것은 사라지며, 손실이 발생해도 오류가 발생하지 않습니다. 그저 조용히 무언가를 가져갑니다.

3. 망각은 경계 지어지고 예약됩니다. 고정된 기록은 절대 소멸되지 않습니다

무한한 메모리는 기능이 아닙니다. 관련성이 없어진 기록들은 영원히 보존되는 대신 스케줄에 따라 노후화되며, 사용자가 명시적으로 고정한(pin) 기록은 소멸에서 면제됩니다. 경계가 없다면 검색 공간만 커지고, 긴 기록에 대한 짧은 쿼리는 사용할수록 좋아지기보다 나빠집니다.

4. Recall은 당신의 단어를 반환하며 출처를 보여줍니다

작성된 내용 자체가 이미 손실적(lossy)이었다면, 어떤 순위 지정기(ranker)도 실제로 필요한 문장을 복구할 수 없습니다. Recall은 패러프레이즈가 아닌 저장된 기록을 가져오고, 그 히트가 어디서 왔는지와 함께 제공합니다. 이것이 세션 간 연속성(cross-session continuity)을 실질적으로 만드는 것입니다: 한 세션에서 내린 결정이 다른 세션에서도 출처와 함께 재발견될 수 있습니다.

5. 개인 정보 보호 경계는 약속이 아닌 설정입니다

기록이 어디에 존재하며, 주어진 기록이 기기를 벗어날 수 있는지 여부는 정책의 한 단락이라기보다는 구성(configuration) 결정 문제입니다. 이것은 특히 하이재킹 사례에서 로컬 우선(local-first)이 중요한 이유이기도 합니다. 오염된 입력은 공급업체의 모델로 방송되어 우리가 전혀 통제할 수 없는 곳에 있는 대신, 당신의 저장소에 남아 있어 찾고 제거할 수 있습니다.

감사 가능성(auditability)이 실제로 바꾸는 것

하이재킹에 대한 재검토:

• 믿음을 볼 수 있습니다. 모든 기록은 출처를 가지므로, 재작성된 항목은 어느 입력에서 재작성되었는지 가리킵니다.
• 되돌릴 수 있습니다. 잘못된 기억도 편집 가능하며 영구적이지 않습니다. 사용자님과 나쁜 기록 사이에는 지원 티켓이 없습니다.
• 무엇이 바뀌었는지 볼 수 있습니다. 결정은 다시 도출되는 것이 아니라 기록으로 저장되기 때문에, 재작성은 알아차리기를 기대하는 다른 답변이라기보다는 눈에 보이는 편집입니다.
• 유지할 수 있습니다. 스토어는 내보내기가 가능하므로, 기억은 어떤 단일 도구, 세션 또는 공급업체보다도 오래갑니다.

이 모듈들은 기록(record), 회상(recall), 통합(consolidation) 및 파일 브릿지(file-bridge)이며, MCP를 통해 노출되므로 에이전트는 도구별 맞춤형 연동이 필요하지 않습니다.

여전히 부족한 점

• 출처(Provenance)는 기록의 출처가 어디였는지 보여줄 뿐입니다. 그 출처가 신뢰할 만했는지는 알려주지 않습니다. 포유독성(poisoned) 기록을 읽고 그것을 판단하는 것은 여전히 사용자님의 몫입니다. 출처 태그는 증거이지, 판결이 아닙니다.
• 편집 가능한 기억은 나쁜 편집도 가능하다는 의미입니다. 해킹된 기록을 복구할 수 있게 하는 열린 문은, 스토어의 누군가에게 그 반대로 변경할 기회를 줍니다. 로컬 우선(local-first) 방식은 사용자님의 장치에 위험을 감수하게 하는데, 적어도 검사할 수 있는 장치입니다.
• 분류는 모델 의존적입니다. 작성 시점에 어떤 종류의 기억인지 결정하는 것은 어느 정도 비율로 오분류를 할 것입니다. 데이터 손실보다 더 조용히 실패하지만, 여전히 실패합니다.
• 출처(Provenance)가 탐지(detection)는 아닙니다. 기록은 완벽하게 정직한 출처를 가질 수 있지만 여전히 틀릴 수 있으며, 스토어의 어떤 것도 그것을 알려주지 않을 것입니다.

사용자님 차례입니다

기억이 문장 하나로 재작성될 수 있다면, 검사 가능성은 더 이상 '있으면 좋은 것(nice-to-have)'이 아니라 기본 전제(floor)가 됩니다. 따라서 에이전트가 오작동할 때, 공급업체의 로그를 읽는 것이 좋겠습니까, 아니면 직접 메모리 파일을 여는 것이 좋겠습니까?

HyperMarrow는 Windows 데스크톱 메모리 레이어입니다. 로컬 우선 빌드는 여기에서 이용 가능합니다: HyperMarrow

공개 사항: 저는 HyperMarrow를 구축했으므로 이 점을 염두에 두고 위 내용을 읽어주세요. 여기에 인용된 커뮤니티 게시물은 실제이며 공개된 것이고, 이 게시물을 위해 숫자, 사용자 수 또는 추천사는 조작되지 않았습니다.