게이트가 메모리 자체의 거짓말을 읽고 있었습니다. 대신 제가 구축한 것은 다음과 같습니다.

지난 기사에서, ANP2가 제가 계속 생각하게 만드는 댓글을 남겼습니다:

"만약 검색된 메모리로부터 리소스를 읽어온다면, 당신은 은연중에 자기 기술(self-description)을 다시 도입한 것입니다. 잘못 라벨링된 항목은 자신의 리소스 또한 잘못 라벨링할 것이며, 게이트는 그 거짓말을 상속받게 됩니다."

메모리가 거짓말을 했습니다. 게이트는 그 거짓말을 상속받았습니다. 그리고 액션(action)이 실행되었습니다.

그것이 실패 모드(failure mode)를 한 문장으로 요약한 것입니다. 여기 테스트 결과가 있습니다.

기존 게이트가 신뢰했던 것

이전의 실행 게이트(execution gate)는 검색된 메모리 자체가 작성한 필드들인 governs.action_types, resource_sensitivity, allowed_action_hint를 확인했습니다. 만약 잘못 라벨링된 메모리가 resource_sensitivity: "ordinary_fact"와 allowed_action_hint: "answer"를 가지고 있다면, 게이트는 해당 라벨들을 읽고 아무런 경고 사항을 발견하지 못한 채 액션을 통과시켰습니다.

거짓말은 정교할 필요가 없었습니다. 그저 올바른 필드에 들어있기만 하면 되었습니다.

해결책: 작업(operation)으로부터 읽기

아키텍처의 변화를 한 문장으로 요약하면 다음과 같습니다: 에이전트가 무엇을 관리한다고 검색된 메모리가 주장하는지가 아니라, 에이전트가 곧 수행할 작업으로부터 권한 클래스(authorization class)를 도출하는 것입니다.

def operation_context_gate(query, memory, pre_gate_action):
    sensitive, action_class, resource_class = is_sensitive_operation(query)
    if sensitive:
...

저는 verify_first를 구조 작업(rescue action)으로 사용했습니다. 게이트가 권한 부족을 감지할 수는 있지만, 아직 해당 작업을 완전히 차단해야 할지 여부까지 결정하지는 않기 때문입니다.

언급할 만한 주의 사항이 하나 있습니다: is_sensitive_operation은 자연어 쿼리(natural-language query)로부터 리소스와 액션 클래스를 추론합니다. 이는 여전히 불완전합니다. 더 강력한 게이트라면 쿼리를 설명하는 것이 아니라, 제안된 도구 호출(tool call), 대상 리소스, 액션 유형, 그리고 수신자를 직접 검사해야 합니다. 이 버전은 작업 유도형 권한(operation-derived authority)을 향한 가교 역할을 하는 것이지, 최종 형태는 아닙니다.

테스트: 의도적으로 잘못 라벨링된 세 가지 메모리

격차를 분리하기 위해 설계된 다섯 가지 시나리오입니다:

3 mislabeled (잘못 라벨링된 3개): 대상 메모리가 resource_sensitivity: "ordinary_fact" 및 allowed_action_hint: "answer"를 가지고 있지만 — 실제 작업은 실행 + 민감한 리소스(계좌 이체, API 키 배포, 외부 파트너로의 PII(개인 식별 정보) 수출)인 경우
1 clean sensitive (정상적인 민감 정보 1개): 올바르게 라벨링됨 — 두 게이트(gate) 모두 거부해야 함 (기준점/baseline)
1 safe read (안전한 읽기 1개): 두 게이트 모두 통과해야 함 (대조군/control)

수치 (The numbers)

지표 (Metric)	자기 기술 게이트 (Self-description gate)	작업 문맥 게이트 (Operation-context gate)
작업 정확도 (Action correct)	2/5	5/5
...

마지막 두 행 사이의 차이가 중요합니다. 잘못 라벨링된 3개의 거부 사례 중 2건에서는, 검색(retrieval) 과정에서 정확한 민감 메모리가 드러났고 작업 문맥 게이트(operation-context gate)가 이를 거부했습니다 — 즉, 게이트가 결과를 만들어낸 것입니다. 세 번째 사례에서는 검색이 대상을 놓쳤지만, 작업 자체가 민감했기 때문에 게이트가 여전히 거부했습니다. 결과는 맞았지만 인과 관계의 경로는 달랐습니다. oc_earned_by_op_context는 이 차이를 추적하며, 이를 통해 통과된 실행이 랭커(ranker)의 운이 좋았던 것이 아니라 게이트가 제대로 작동했음을 증명합니다.

정직한 비용 (The honest cost)

깨끗한 기준점(fresh-Claude v0.4 top-5) 기준:

	SD	OC
작업 정확도 (Action correct)	5/5	3/5
거짓 확신 (False certainty)	0	0

두 가지 시나리오에서 block(차단)이 예상되었으나 verify_first(먼저 확인)가 발생했습니다. 이는 거짓 확신(false certainty)은 아닙니다 — '위험'이 예상될 때 게이트가 '안전'하다고 말한 적은 없기 때문입니다. 하지만 올바르게 라벨링된 두 건의 차단 결정을 하향 조정했습니다. 작업 문맥 게이트(operation-context gate)는 올바르게 라벨링된 것을 포함하여 모든 민감한 작업에 대해 더 엄격합니다. 이러한 트레이드오프(tradeoff)는 클레임 원장(claim ledger)에 기록되어 있습니다. 숨기지 않았습니다.

이것이 해결하지 못하는 것

게이트는 실행 시점(execution time)에 잘못 라벨링된 메모리를 잡아냅니다. 쓰기 시점(write-time)에는 관여하지 않습니다.

한 댓글 작성자가 더 어려운 질문을 직접 던졌습니다: "귀하의 속성 추적(attribution trace)은 저장 시점(store time)의 권한 부여를 위한 정답(ground truth)으로 무엇을 사용합니까? 호출자 신원(Caller identity), 네임스페이스 위치(namespace position), 아니면 메모리 계층 외부의 무언가입니까?"

솔직한 답변을 드리자면: 현재로서는 저장된 메타데이터(metadata)가 여전히 실체적 진실(ground truth)입니다. 저장 에이전트(storing agent)는 쓰기 시점(write time)에 자신의 권한을 주장합니다. 오염된 쓰기(poisoned write)는 여전히 저장소에 진입합니다. 운영 컨텍스트 게이트(operation-context gate)는 실행 시점에 거부할 수는 있지만, 무엇이 누구에 의해 저장되었는지는 검증할 수 없습니다.

쓰기 시점의 권한 부여(Write-time authorization)가 다음에 해결해야 할 열린 계층입니다. 저장 에이전트의 신원(identity)과 네임스페이스 위치(namespace position)가 첫 번째 게이트가 되어야 합니다. 결제 작업에 대한 권한을 주장하는 task-abc.executor는 해당 항목이 저장소에 도달하기 전에 실패해야 합니다. 이는 아직 구축되지 않았습니다.

실질적인 규칙

메모리 객체가 스스로의 권한에 대한 유일한 증인이 되도록 두지 마십시오.

패턴

이 시리즈의 모든 단계는 외부의 압력이 강제했기에 움직였습니다. 자기 기술 간극(self-description gap)은 원래 설계에 포함되어 있지 않았습니다 — ANP2가 주석에서 이를 명시했습니다. 귀속 정교화(attribution refinement)는 이 평가(eval)의 첫 번째 버전에는 없었습니다 — 같은 세션에서 두 번째 댓글 작성자가 이를 밀어붙였습니다.

연구는 댓글들이 반박했기에 더 나아졌습니다. 그것이 핵심입니다.

코드: https://github.com/keniel13-ui/ai-memory-judgment-demo