AI 에이전트의 메모리가 새로운 공격 표면이 되었지만, 아무도 이를 고려하여 설계하지 않았습니다

이메일 단 한 통. 악성 코드도, 익스플로잇 체인(exploit chain)도, 자격 증명 탈취도 없습니다. 그저 AI 에이전트가 자신의 장기 메모리(long-term memory)를 조용히 재작성하도록—예를 들어, Zelle 송금 한도를 높이도록—설득하는 숨겨진 지침이 있을 뿐입니다. 그러면 그 거짓말은 이후의 모든 상호작용에서 "사실"이 됩니다. 이것이 바로 MemGhost이며, 지금 당장 중요한 이유는 지속성 메모리(persistent memory)가 모든 에이전트 벤더가 출시 경쟁을 벌이고 있는 기능임에도 불구하고, 거의 아무도 이에 대한 위협 모델링(threat-modeling)을 하지 않고 있기 때문입니다.

문맥: 이것은 새로운 것이 아니라, 단지 새로운 모습을 하고 있을 뿐입니다

프롬프트 인젝션(Prompt injection)은 지난 몇 년간 업계의 알려진 미지의 영역(known unknown)이었습니다. 우리는 독이 든 웹 콘텐츠나 이메일을 통해 에이전트가 데이터를 유출하거나 승인되지 않은 작업을 수행하도록 속이는 사례들에 대한 보고서를 모두 읽어보았습니다. 여기서 다른 점은 인젝션 벡터(injection vector)가 아니라 타겟입니다. 에이전트를 속여 단 한 번 무언가를 하게 만드는 대신, MemGhost는 에이전트가 무언가를 영원히 "기억"하도록 속입니다. 이는 의미 있는 에스컬레이션(escalation)입니다. 왜냐하면 메모리 시스템은 에이전트가 더 유용하고 "고착성(sticky)" 있게 느껴지도록—사용자의 선호도를 기억하고, 계정 세부 정보를 기억하고, 한도를 기억하도록—하기 위해 특별히 에이전트에 덧붙여졌기 때문입니다. 아무도 메모리 쓰기(memory-write) 도구를 설계할 때 그 안으로 흘러 들어가는 콘텐츠가 적대적(adversarial)일 수 있다는 가정을 하지 않았습니다. 이는 전형적인 패턴입니다. UX 문제를 해결하기 위해 기능이 출시되면, 보안 모델은 2년 뒤에나 따라오거나, 혹은 아예 따라오지 못합니다.

하이프 체크(Hype check): 숫자는 실제이지만, 프레이밍은 아닐 수 있습니다

프론티어 모델 (Frontier models)을 상대로 한 87.5%의 성공률은 진정으로 경각심을 불러일으키는 수치이며, 이 부분은 과장되었다고 생각하지 않습니다. 제가 반박하고 싶은 점은, 이를 더 나은 필터링으로 해결할 수 있는 "탈옥 (Jailbreak)" 문제로 취급하는 모든 프레이밍입니다. 요약문에는 이 공격이 입력 필터와 강화된 방어 체계를 우회하는 이유가 명시되어 있습니다. 바로 _어떠한 권한 경계 (Authorization boundary)도 깨뜨릴 필요가 없기 때문_입니다. 즉, 에이전트가 메모리 쓰기 (Memory writes)를 위해 사용하도록 설계된 에이전트 자신의 정당한 도구를 사용합니다. 사람들이 퍼센트 수치보다 더 걱정해야 할 디테일은 바로 이것입니다. 방어 전략이 "나쁜 프롬프트를 탐지하는 것"이라면, 당신은 결국 패배하게 될 필터링 게임을 하고 있는 것입니다. 왜냐하면 이 익스플로잇 (Exploit)은 잘못된 형식이 아니라, 도구가 허용하도록 만들어진 바로 그 기능을 수행하는 정상적인 입력이기 때문입니다.

현 시점에서 "프롬프트 인젝션 (Prompt injection)은 무섭다"는 서사로부터 누가 이득을 얻습니까? 주로 지난 12건의 프롬프트 인젝션 이야기로부터 이득을 얻었던 이들과 같습니다. 이는 긴급성을 유도하고, 예산을 끌어내며, 헤드라인을 장식합니다. 그렇다고 해서 이번 사례가 틀렸다는 뜻은 아니지만, 아직 아무도 마케팅하지 않고 있는 해결책이 매우 지루하다는 점은 주목할 가치가 있습니다. 그것은 바로 더 똑똑한 프롬프트 분류기 (Prompt classifier)가 아니라, 영구 상태 (Persistent state)에 대한 쓰기 (Write) 작업에 대한 권한 경계 (Authorization boundaries)를 설정하는 것입니다. 탐지 계층 (Detection-layer) 솔루션은 "도구 권한 모델을 재설계하십시오"라는 제안보다 훨씬 팔기 쉬운 제품입니다.

시사점: 메모리는 자금 이동과 동일한 수준의 정밀 조사가 필요합니다

만약 당신의 에이전트가 영구 메모리 (Persistent memory)에 쓸 수 있다면, 그 쓰기 경로 (Write path)에는 금융 거래 API에 적용하는 것과 동일한 엄격함이 필요합니다. 즉, 출처 확인 (Provenance checks), 민감한 필드에 대한 인간 개입 확인 (Human-in-the-loop confirmation), 그리고 메모리 쓰기 도구가 무엇을 건드릴 수 있는지에 대한 엄격한 제한이 필요합니다. 이체 한도 (Transfer-limit) 필드는 프롬프트 상의 "사용자"가 아무리 설득력 있게 보이더라도, 비정형 이메일 콘텐츠에서 파생된 무언가로부터는 절대로 쓰기가 가능해서는 안 됩니다. 이것은 결론입니다.

오늘날 에이전트 메모리 시스템을 구축하는 개발자들을 위한 조언입니다: 콘텐츠의 _출처(source)_에 대한 신뢰 수준을 _행동(action)_에 대한 신뢰 수준과 분리하십시오. 이메일, 웹페이지, 도구 응답 등 그 어떤 것도 설정 변경을 명시적으로 확인하는 인증된 사용자와 동일한 쓰기 권한(write authority)을 가져서는 안 됩니다. 글로 써놓으면 당연하게 들릴 것입니다. 하지만 실제로는 그렇지 않은 것이 분명합니다. 왜냐하면 이러한 원칙 없이 시스템이 계속해서 구축되고 있기 때문입니다.

보안 팀을 위한 실질적인 시사점은, "우리는 입력 필터링(input filtering)을 갖추고 있다"라는 말이 더 이상 통제 수단(control)이 아니라, 그저 말뿐인 구호(talking point)가 되었다는 점입니다. 만약 에이전트형 AI(agentic AI)에 대한 위협 모델(threat model)에 "에이전트 자신의 신뢰할 수 있는 도구가 신뢰할 수 없는 의도(untrusted intent)로 호출될 때 어떤 일이 발생하는가"가 포함되어 있지 않다면, 당신은 위협 모델을 가진 것이 아니라 그저 희망 사항을 가진 것뿐입니다.

열린 질문 (Open question)

지속성 메모리(persistent memory)가 에이전트를 진정으로 유용하게 만드는 요소인 동시에, 에이전트를 영구적으로 오염(poisonable)시킬 수 있게 만드는 요소라면, 우리는 이 기능을 출시하기 위한 필수 요구 사항으로 롤백/감사(rollback/audit) 메커니즘을 수용할 것입니까? 아니면 첫 번째 실제 사고가 헤드라인을 장식할 때까지 이 기능을 계속 출시하며 메모리 무결성(memory-integrity) 문제를 사후 패치하는 방식을 유지할 것입니까?

— Cor, Skyblue Soft

출처 (Sources)

• New MemGhost Attack Plants Persistent False Memories in AI Agents Through One Email