검색은 메모리를 찾아냈지만, 무엇이 행동을 승인했는가?

에이전트 메모리 안전성(Agent Memory Safety)의 나머지 절반
검색 시점의 권한(Retrieval-time authority)은 문제의 첫 번째 절반이었습니다.

저는 열 편의 글을 통해 하나의 발견을 향해 나아왔습니다. 에이전트 메모리 시스템이 올바른 메모리를 검색하더라도, 해당 메모리에 권한 메타데이터(authority metadata)가 포함되어 있지 않다면 여전히 잘못된 행동을 취할 수 있다는 점입니다. 관련성(Relevance)과 권한(Authority)은 서로 다른 것입니다.

하지만 검색 시점의 권한은 단 하나의 질문에만 답할 수 있습니다. '올바른 규칙이 쿼리(query)에 도달했는가?'

더 어려운 질문은 실행 시점(execution-time)의 질문입니다. '그 규칙이 행동을 통제했는가?' 검색된 메모리의 특정 필드에서 에이전트가 취한 특정 행동까지 선을 그어 추적할 수 있는가 — 그리고 그 선이 해당 작업의 위험 수준(risk level)에 대해 충분한가?

이 글은 그 두 번째 계층을 구축하는 것에 관한 것입니다. 게이트(gate)는 실재합니다. 또한 그것이 구제할 수 있는 것과 없는 것의 한계도 실재합니다.

무엇이 누락되었는가

검색 시점의 작업 이후, 평가기(evaluator)는 "행동 정확성: 예/아니오(action correct: yes/no)"를 기록했습니다. 이는 검색 결과의 하류(downstream) 단계입니다. 그것은 어떤 필드가 행동을 승인했는지, 혹은 그 필드가 충분했는지는 기록하지 않았습니다.

저는 이를 드러내기 위해 귀속 추적(attribution trace)을 추가했습니다. 이제 모든 결정은 다음을 기록합니다:

• action_authorized_by — 행동을 트리거한 특정 필드
• attribution_status — 다음 중 하나: GOVERNED, AUTHORITY_ONLY, DEFAULT, 또는 UNATTRIBUTABLE

UNATTRIBUTABLE은 위험한 분류입니다. 이는 행동이 허용적(permissive)이었으나 시나리오는 제한(restriction)을 예상했으며, 선택된 메모리의 어떤 권한 필드도 이를 제약하지 않았음을 의미합니다. 시스템은 결정의 근거 없이 자신 있게 답변한 것입니다.

이전 작업의 경계 패킷(boundary packets) — 자격 증명/개인정보(credential/PII) 및 산업 안전(industrial safety) — 에 대해 귀속 추적을 실행했을 때, 모든 거짓 확신(false-certainty) 오류는 UNATTRIBUTABLE로 매핑되었습니다. 모든 거버넌스 조정된 깨끗한 행동은 GOVERNED로 매핑되었습니다.

그것이 간극을 명시했습니다. 하지만 간극을 메우지는 못했습니다.

실행 시점의 게이트

저는 단순히 결과를 라벨링하는 것이 아니라, 행동 시점에 개입할 수 있는 게이트를 구축했습니다.

중앙의 필드는 governs.action_types이며, 이는 메모리가 어떤 종류의 연산 (operations)을 제어할 수 있는지에 대한 선언입니다. 이 프레임워크에서 유효한 값으로는 read (읽기), write (쓰기), execute (실행)가 포함됩니다. 결제 처리를 제어하는 메모리는 ["execute", "write"]를 가질 수 있습니다. 읽기 전용 조회를 제어하는 메모리는 ["read"]를 가질 수 있습니다.

게이트 로직 (gate logic)은 직관적입니다. 검색 (retrieval)이 메모리를 선택하고 layered_action이 행동을 결정한 후, 게이트는 governs.action_types가 해당 행동이 반영하는 것보다 더 높은 위험도의 연산을 암시하는지 확인합니다.

governs_restrictive = bool(action_types & {"execute", "write"})

if governs_restrictive and action in {"answer", "answer_context"}:
    # governs는 이 메모리가 상태를 변경하는 연산을 제어한다고 말하지만
    # 행동은 허용적인(permissive) 상태임 — 에스컬레이션(escalate) 수행
    return "GATE_FAIL", escalate to "verify_first"

저는 verify_first를 보수적인 구조 작업 (rescue action)으로 사용했습니다. 게이트가 불충분한 실행 권한을 감지할 수는 있지만, 해당 연산을 완전히 차단해야 하는지 여부까지는 아직 판단할 수 없기 때문입니다. 일괄적으로 통과시키는 것보다 일괄적으로 에스컬레이션하는 것이 더 안전합니다.

governs 필드가 없거나 그 안에 action_types가 없는 경우, 게이트는 GATE_SKIP을 반환합니다. 즉, 작동할 수 없습니다.

이 구분이 바로 발견 사항 (finding)이 존재하는 지점입니다.

테스트 결과

저는 세 가지 시나리오—결제 처리, 운영 데이터베이스 자격 증명 (production database credentials), 그리고 개인정보 (PII) 대량 내보내기 요청—를 포함한 테스트 패킷을 구축했습니다. 각 대상 메모리는 governs.action_types: ["execute"] 또는 ["execute", "write"]로 올바르게 범위가 지정되었지만, 권한 신호 (authority signals)는 의도적으로 누락되었습니다. verification_required 없음. 기본 allowed_action_hint: answer. 권한 memory_type 없음.

이는 현실적인 작성 오류 (authoring failure)입니다. 개발자가 올바른 governs 블록을 작성했지만 verification_required: true를 잊어버린 경우입니다. 검색 시스템은 올바른 메모리를 선택합니다. layered_action은 권한 신호에서 제한적인 요소를 찾지 못하고 answer를 반환합니다.

게이트(gate)가 없다면, 모든 검색 전략은 해당 패킷에서 3/3의 잘못된 확신(false-certainty) 오류를 발생시켰습니다. 즉, 올바른 메모리는 찾아냈지만 잘못된 행동을 취한 것입니다.

게이트가 활성화된 상태에서는 모든 전략이 3/3의 행동 정확도(action correct)를 달성했으며, answer에서 verify_first로 3건의 에스컬레이션(escalations)이 발생했습니다. 게이트가 세 가지 사례를 모두 구제했습니다.

한 가지 직접적으로 밝혀둘 점은, 이 패킷은 실패 모드(failure mode)가 이미 알려진 상태에서 내부적으로 작성되었다는 것입니다. 제가 직접 그 간극(gap)을 설계한 후 수정 방안을 구축했습니다. 이는 독립적인 검증(independent validation)이 아니라 반복적인 엔지니어링(iterative engineering)입니다. 결과는 실제적이지만, 그에 따라 해석되어야 합니다.

게이트가 도달할 수 없는 곳

게이트는 governs가 존재할 때만 작동합니다.

이전의 경계 패킷(boundary packets)들에서, 잘못 라벨링된 민감한 메모리들은 governs 필드가 전혀 없었습니다. 게이트는 모든 사례에서 GATE_SKIP을 반환했습니다. 권한 신호(authority signals) 또한 부재한 UNATTRIBUTABLE 사례들은 여전히 보호되지 않은 상태로 남아 있습니다.

이것이 현재 프레임워크의 줄일 수 없는 간극(irreducible gap)입니다.

또한 이는 이전 연구의 전제 조건을 더욱 명확히 합니다. 이전의 연구 결과는 다음과 같이 명시했습니다: 민감한 메모리에는 governs 메타데이터 또는 권한 신호(authority signals) 중 하나가 필요하다.

게이트는 그것만으로는 완전한 보호를 위해 충분하지 않다는 것을 보여줍니다. 두 유형의 메타데이터는 서로 다른 계층에서 서로 다른 역할을 수행합니다:

• 권한 신호 (verification_required, memory_type: policy, allowed_action_hint: block)는 검색 시점(retrieval time)에 보호를 수행합니다. 이들은 어떤 메모리가 선택될지, 그리고 layered_action이 어떤 행동을 반환할지에 영향을 미칩니다.
• governs.action_types는 실행 시점(execution-time)의 게이트를 활성화합니다. governs가 없다면, 메모리 내용이 얼마나 민감하든 상관없이 게이트는 보지 못합니다.

어느 하나만으로는 완전한 커버리지(coverage)를 제공할 수 없습니다. 게이트는 governs는 존재하지만 권한 신호는 부재한 경우를 위한 최후의 보루(backstop)입니다. 게이트가 누락된 governs를 대체할 수는 없습니다.

커버리지 맵 (The Coverage Map)

┌─────────┬────────────────┬────────────────┬──────────────────┬───────────────────┐
│ Governs │ Authority │ Attribution │ Gate │ Protection │
│ │ signals │ │ │ │
├─────────┼────────────────┼────────────────┼──────────────────┼───────────────────┤
│ Absent │ Absent │ UNATTRIBUTABLE │ GATE_SKIP │ None │
├─────────┼────────────────┼────────────────┼──────────────────┼───────────────────┤
│ Absent │ Present │ AUTHORITY_ONLY │ GATE_SKIP │ Retrieval-time │
│ │ │ │ │ only │
├─────────┼────────────────┼────────────────┼──────────────────┼───────────────────┤
│ Present │ Absent │ DEFAULT │ GATE_FAIL → │ Gate rescues │
│ │ │ │ escalate │ │
├─────────┼────────────────┼────────────────┼──────────────────┼───────────────────┤
│ Present │ Present │ GOVERNED │ GATE_PASS │ Full chain │
└─────────┴────────────────┴────────────────┴──────────────────┴───────────────────┘

오른쪽 하단 셀이 목표 상태입니다. 두 필드가 모두 존재합니다. 권한 신호(authority signals)에 의해 검색 시점에 행동이 승인됩니다. 게이트(gate)에 의해 실행 시점에 행동이 확인됩니다. 완전하게 추적 가능한 체인입니다.

다른 모든 셀은 공백을 가지고 있습니다. 빌더는 자신의 메모리 스키마를 보고 즉시 질문할 수 있습니다: 당신의 스키마는 현재 커버리지 맵의 어느 셀에 위치합니까?

이것이 해결하지 못하는 것들

게이트는 verify_first로 균일하게 에스컬레이션(escalates)합니다. 차단해야 할 경우를 구별하지 못합니다. 이것은 현재 구현의 알려진 한계입니다.

또한 게이트는 검색 노이즈에 대해서도 테스트되지 않았습니다. 만약 검색이 잘못된 메모리—우연히 governs.action_types: ["execute"]을 포함하는 메모리—를 선택한다면, 게이트는 잘못된 대상을 대상으로 작동합니다. 에스컬레이션은 스키마 상으로는 기술적으로 정확하겠지만 실제로는 오해의 소지가 있습니다. 이 엣지 케이스(edge case)에는 저장소에 경쟁하는 고-액션 타입 메모리(competing high-action-type memories)를 가진 전용 스트레스 패킷이 필요합니다.

더 근본적으로, 게이트(gate)는 요청된 특정 작업(operation)이 아니라 action_types 카테고리를 확인합니다. 제안된 작업이 해당 field가 실제로 관할한다고 주장하는 관할권(jurisdiction) 내에 있는지 여부를 평가하지는 않습니다. 그러기 위해서는 governs.any_terms 또는 governs.all_terms를 도구 호출(tool call) 자체와 대조하여 확인해야 하는데, 이는 현재 스키마(schema)가 지원하지만 게이트가 아직 수행하지는 않는 더 세밀한(finer-grained) 확인 절차입니다.

실질적인 시사점은 간단합니다: 검색 메타데이터(retrieval metadata)와 실행 메타데이터(execution metadata)는 동일한 계층이 아닙니다. 하나는 메모리를 선택하는 데 도움을 주고, 다른 하나는 선택된 메모리가 수행되는 작업을 관할할 권한이 있음을 증명하는 데 도움을 줍니다.

날카로워진 전제 조건 (The Sharpened Precondition)

이 작업의 각 계층이 진행됨에 따라 최소 메타데이터 요구 사항은 더욱 구체화되었습니다.

현재의 정직한 진술은 다음과 같습니다:

▎ 검색 시점(retrieval-time)과 실행 시점(execution-time)의 완전한 보호를 위해, 민감한 메모리는
▎ governs 관할권 메타데이터와 권한 신호(authority signals)가 모두 필요합니다. governs는
▎ 실행 시점의 게이트를 활성화합니다. 권한 신호는 검색 시점에 보호를 제공하며
▎ layered_action이 올바른 액션 클래스(action class)를 반환하도록 보장합니다. 어느 한 필드만으로는
▎ 다른 필드가 메울 수 없는 공백이 발생합니다.

이것은 여전히 작고 통제된 패킷(packets)을 대상으로 내부적으로 작성된 증거입니다. 아키텍처 과적합(overfitting) 위험은 실재합니다. 게이트는 그것이 구조하는 실패 사례들을 목격한 후에 설계되었기 때문입니다. 이 결과는 일반적인 원칙이 아니라 제한된 내부 결과로 취급되어야 합니다.

다음으로 필요한 단계는 외부 저술(external authorship)입니다. 즉, 이 프레임워크를 설계하지 않은 사람이, 자신이 선택한 도메인에서, 혼합된 품질의 메타데이터를 사용하여 작성한 패킷이 필요합니다. 만약 그 압박 속에서도 커버리지 맵(coverage map)이 유지된다면, 전제 조건은 더욱 강력해질 것입니다. 만약 무너진다면, 그것은 오히려 더 유용합니다. 어떤 조건이 누락되었는지 우리에게 알려주기 때문입니다.

외부 패킷을 작성하고 싶다면, 스키마, 평가 하네스(evaluation harness), 그리고 게이트 구현체는 공개되어 있습니다: https://github.com/keniel13-ui/ai-memory-judgment-demo

만약 여러분이 에이전트 메모리 시스템 (agent memory systems)을 구축하고 있다면 — 각각의 민감한 메모리 (sensitive memory)가 거부 규칙 (governs block)과 최소 하나 이상의 권한 신호 (authority signal)를 모두 포함하고 있습니까? 여러분의 스키마 (schema)는 현재 커버리지 맵 (coverage map)의 어느 셀 (cell)에 위치하고 있습니까?