출처가 없으면 AI 에이전트 메모리에 쓰지 못하게 하는 출처 검증 게이트
요약
AI 에이전트의 메모리 시스템에 '출처 검증 게이트(provenance gate)'를 도입하여, 출처가 명시되지 않은 사실은 메모리에 기록되는 것을 원천적으로 차단하는 방법을 제시합니다. 이 게이트는 쓰기 전에 Junk/중복 검사, 모순 검사, 신뢰도 하한선, 그리고 가장 중요한 '출처 검사'를 통해 정보의 정확성을 강화했습니다. 레드팀 테스트 결과, 출처가 없는 새로운 주장은 초기 시스템에서 쉽게 통과했으나, `needs_provenance` 규칙 도입 후 30개의 적대적 쓰기 시도 모두 차단하는 효과를 입증했습니다.
핵심 포인트
- 출처 검증 게이트는 에이전트 메모리 오염을 방지하는 핵심 방어선입니다.
- 쓰기 전에 출처 추적 가능 여부를 결정론적으로 확인합니다.
- 모순되거나 출처가 없는 주장은 자동으로 기록되지 않도록 격리됩니다.
- 시스템의 신뢰도를 높였으나, 경쟁 조건(race condition) 같은 취약점은 남아있습니다.
_Mikhail Oskola 작성, Retailbox Automation 설립자.
출처 검증 게이트(provenance gate)는 AI 에이전트의 메모리 앞에 위치하는 규칙입니다. 에이전트는 사실을 제안할 수 있지만, 그 사실이 어디서 왔는지 출처를 명시하지 않으면 메모리가 될 수 없습니다. 출처가 없으면 쓰기(write)도 불가능합니다. 저희는 FleetMemory라는 해커톤 프로젝트를 위해 이를 구축했고, 스스로 이 시스템에 공격을 가해 보았습니다. 첫 번째 버전은 6번의 시도 중 6번 모두 거짓 정보를 통과시켰습니다. 수정된 버전은 30번의 시도 중 30번 모두 차단했습니다.
출처 검증 게이트가 실제로 확인하는 것
대부분의 에이전트 메모리 시스템은 에이전트가 쓰는 모든 것을 신뢰합니다. 이것이 바로 실패 모드입니다: 에이전트가 숫자를 추론하고, 자신감을 가지고 이를 진술하며, 시스템은 이 정보를 고객이 실제로 말한 사실들 옆에 저장합니다. 한 달 뒤에 다시 읽어보면 어느 것이 무엇인지 알 방법이 없습니다.
출처 검증 게이트는 쓰기가 커밋되기 전에 결정론적인 확인을 추가합니다: 이 사실이 출처를 추적할 수 있는가? 고객이
- 쓰레기 및 중복 검사 (Junk and duplicate checks): 형식이 잘못되었거나 이미 알려진 쓰기는 검증자 호출 비용을 발생시키기 전에 걸러냅니다.
- 모순 검사 (Contradiction checks): 기존 사실과 충돌하는 새로운 값은 조용히 덮어쓰여지지 않고 플래그가 지정됩니다.
- 신뢰도 하한선 (Confidence floor): 최소 신뢰도보다 낮은 추측은 메모리에 도달하지 못합니다.
- 출처 검사 (Provenance check): 고객의 발화(utterance)를 근거로 하지 않은 주장은 에이전트가 아무리 자신감 있게 들려도 격리됩니다.
취약점을 발견한 레드팀 테스트
게이트는 던지는 것에 비례하여 좋을 수밖에 없습니다. 우리는 모의 시스템이 아닌 실제 게이트와 검증자를 대상으로 5가지 공격 클래스에 걸쳐 30개의 적대적 쓰기(adversarial writes)를 실행했습니다. 스크립트와 전체 결과는 공개 리포지토리에 배포됩니다.
첫 번째 테스트에서 실제 간극이 포착되었습니다: 출처가 없는 새로운 주장들, 메모리 내의 어떤 것과도 모순되지 않는 사실들은 (모순시킬 것이 없기 때문에) 결정론적 게이트를 6번 중 6번 통과했습니다. 완전히 새롭고, 자신감 넘치며, 지어낸 사실 하나가 플릿(fleet)의 공유 메모리로 곧장 들어갔습니다.
수정된 부분은 needs_provenance라는 규칙을 도입한 것입니다: 고객 발화를 근거로 하지 않은 주장은 격리되어 검증자를 거쳐야 하며, 주장된 신뢰도만으로는 이미 출처가 있는 사실을 자동으로 대체할 수 없게 되었습니다. 우리는 동일한 30가지 공격을 다시 실행했습니다. 이번에는 쓰레기, 너무 큰 페이로드, 터무니없는 신뢰도의 추측, 출처 없는 모순, 그리고 첫 번째 테스트에서 통과했던 출처 없는 새로운 주장들을 포함하여 모두 차단되었습니다.
게이트는 여전히 10개의 고객 확인 업데이트 중 9개만 통과시켰을 뿐, 10개 중 10개를 통과시키지는 못했습니다. 놓친 하나는 공개된 경쟁 조건(race condition)입니다: 중간 업데이트가 해결되지 않은 상태에서 원래 값으로 루프백하는 값입니다. 이는 결정 저널(decision journal)에 기록되며 숨겨지거나 조정되지 않습니다. 테스트 전반의 평균 게이트 지연 시간은 293밀리초였습니다.
이 기록(trace)이 존재하는 곳: 결정 저널(decision journal)은 일반적인 CockroachDB 테이블입니다. 이 뷰는 데모 고객의 것이며, 레드팀 실행 결과가 아닙니다. 여전히 활성화된 사실 7가지, 깨끗하게 수락된 것 6가지, 그리고 검증자에 의해 거부된 모순되는 쓰기 기록 2개가 있습니다.
검증자가 기본적으로 거부하는 이유
격리된 주장(quarantined claim)은 그저 거기에 머물러 있지 않습니다. 적대적인 LLM 검증자(adversarial LLM verifier)가 이를 읽고 판단하며, 그 기본값은 수락이 아닌 거부입니다. 만약 어떤 이유로든 검증자 호출 자체가 실패하면, 그것 역시 거부로 간주됩니다.
검증자의 임무는 출처(provenance)를 구체적으로 따지는 것입니다: 직접적인 고객 진술은 오래된 사실보다 우선하며; 출처가 없는 값은 그럴듯하게 들리더라도, 심지어 주장하는 에이전트가 자신감 있게 들리더라도 거부됩니다. 모든 판결은 한 문장의 이유와 함께 원래의 쓰기 시도와 동일한 결정 저널 행에 기록됩니다.
수정 역시 아무것도 삭제하지 않습니다. 우선순위가 밀린 사실(superseded fact)은 이전 행을 유지하며, 무효화 처리되고 무엇으로 대체되었는지 가리킵니다. 시스템에게 과거 특정 날짜에 믿었던 것이 무엇인지 물어보면, 그것이 포기된 신념까지 포함하여 알려줄 수 있습니다.
그 주장에 대한 검증자의 판결: 거부됨(refused), 취소선 처리되었으며, 카드에 한 문장의 이유가 적혀 있습니다. $1,800에는 고객 진술이 뒷받침되지 않았고, $18,000에는 그랬습니다.
가장 강력한 종류의 증거: 다른 누군가가 검증하는 것
누구나 자신의 시스템이 작동한다고 주장할 수 있습니다. 이 기능을 개발하는 과정에서 저희는 LangChain의 AsyncPostgresSaver 체크포인터가 CockroachDB와 충돌하는 것을 발견했고, 독립적인 재현(repro) 사례와 제안된 수정 방향을 담아 상위 저장소에 이슈를 등록했습니다 (langchain-ai/langgraph#8620).
한 커뮤니티 기여자가 이 문제를 맡아 해당 방향에 따라 완전한 수정을 구현했고, PostgreSQL 17.5와 CockroachDB v26.2.4 모두에서 독립적으로 검증했습니다. 현재 작성 시점 기준으로 유지보수자 검토를 기다리고 있습니다. 저희 팀 누구도 그 수정 사항을 작성하거나 검증을 실행하지 않았다는 사실 자체가 저희가 발표할 수 있는 어떤 벤치마크보다 더 강력한 신호입니다.
작동 방식 확인하기
FleetMemory는 유료 고객 프로젝트가 아닌, CockroachDB x AWS의 'Agentic Memory를 활용하여 구축하기' 해커톤에 제출한 저희 자체 작품입니다. 공개적이며 MIT 라이선스이므로 누구나 게이트 로직을 읽거나 레드팀(red team) 테스트를 재실행할 수 있습니다.
구성 요소가 작동하는 방식: 모든 에이전트의 기록은 게이트를 통과하며, 격리된 주장(quarantined claims)은 검증기(verifier)로 이동하고, 사실 정보와 결정 일지(decision journal)는 CockroachDB에 저장됩니다. AWS는 세션 상태(AgentCore Memory), 모델(Bedrock), 그리고 공개 데모(Lambda)를 담당합니다.
- 로그인 없이 라이브 데모: 에이전트 Alex와 대화하고, 에이전트 Maria로 돌아온 다음, '사실 환각 생성하기(hallucinate a fact)'를 실행하여 게이트가 이를 포착하는 것을 지켜보세요. https://pskmxv5sm4k3fj2rjoh2aoijka0ofgob.lambda-url.us-east-1.on.aws/
- 공개 레포지토리 (MIT 라이선스): 게이트, 검증기(verifier), 레드팀 스크립트, 그리고 평가 결과. https://github.com/retailbox-automation/fleetmemory
- 격리 및 거부 순간을 보여주는 1:15 데모 영상.
- 업스트림 이슈: 제3자 기여자(third-party contributor)가 검증한 수정 사항으로, 유지 관리자의 검토를 기다리는 중입니다. https://github.com/langchain-ai/langgraph/issues/8620
FAQ
AI 에이전트 메모리에서 출처(provenance) 게이트란 무엇인가요?
출처 게이트는 어떤 사실(fact)이 에이전트의 메모리에 기록되기 전에 실행되는 검사입니다. 이는 해당 사실이 에이전트 자체의 신뢰도에 의존하기보다, 직접적인 고객 진술과 같은 명명된 출처를 추적하는지 여부를 확인합니다. 출처가 없는 주장은 메모리에 바로 쓰기(writing straight to memory) 하는 대신 격리(quarantines)됩니다.
신뢰도 점수만으로 나쁜 사실을 걸러내기에 충분하지 않나요?
아닙니다. 그리고 이것이 바로 저희 레드팀이 발견한 정확한 간극입니다. 에이전트는 높은 신뢰도로 완전히 새로운, 출처가 없는 사실을 진술할 수 있으며, 메모리에 이미 존재하는 것이 이를 모순하지 않는다면, 신뢰도만으로 필터링하는 것은 비교할 대상이 없습니다. 이 주장은 저희의 첫 번째 게이트를 6번 중 6번 통과했습니다. 수정 사항은 신뢰도 숫자가 아닌 출처(source)를 확인합니다.
게이트가 거부한 사실은 어떻게 되나요?
사라지지 않습니다. 거부 이유와 함께 의사 결정 저널(decision journal)에 기록됩니다. 따라서 누구나 무엇이 시도되었는지, 언제, 그리고 왜 통과하지 못했는지를 조회할 수 있습니다. 나중에 수정된 승인된 사실 역시 삭제되지 않습니다. 이전 값은 무효(invalid)로 표시되어 보존되므로, 시스템이 이전에 믿었던 것이 무엇이었는지 답변할 수 있게 합니다.
이것은 RAG 답변에서 출처를 인용하는 것과 같은 건가요?
관련되지만 파이프라인의 더 앞 단계에 있습니다. RAG 인용(citations)은 사용자에게 답변 텍스트가 어디에서 왔는지 알려줍니다. 출처 검증 게이트(provenance gate)는 에이전트가 해당 주장을 검색하고 반복하기 전에, 아예 메모리 내에 지속적인 사실(durable fact)로 저장되는 것을 허용할지 여부를 결정합니다.
직접 레드팀을 실행해 볼 수 있나요?
네. 이 레포는 MIT 라이선스를 따르며, 레드팀 스크립트와 여기에 인용된 평가 결과가 포함되어 있습니다. 사용자의 CockroachDB 클러스터에 연결하여 동일한 30가지 공격을 재실행할 수 있습니다.
원래 게시일: https://retailbox-automation.com/blog/ai-agent-provenance-gate. 이 기술의 패턴, 즉 공유 메모리에 쓰기할 때 검증 게이트를 통해서만 접근하는 에이전트 방식은 저희가 고객을 위해 구축해 드릴 수 있는 AI 에이전트 프로젝트입니다: AI Agent Development Company.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기