에이전트는 행동이 허용되었으나, 로그는 그 이유를 증명할 수 없었다. *AI 메모리 판단 - CLAIM-26*

CLAIM-24는 오래된 캐시된 권한(stale cached grants)을 테스트했습니다.

CLAIM-25는 인증되었으나 최신 상태는 아닌 서명된 응답(signed responses)을 테스트했습니다.

두 가지 모두 런타임 권한 부여(runtime authorization) 문제였습니다. 질문은 이것이었습니다: 에이전트가 지금 당장 행동하는 것이 허용되어야 하는가?

CLAIM-26은 한 단계 더 나아갑니다.

행동이 취해진 후, 감사자(auditor)가 어떤 권한이 그 행동을 정당화했는지 정확하게 재구성할 수 있는가?

만약 대답이 '아니오'라면, 그 행동은 올바랐을지 모르지만 시스템은 감사 안전성(audit-safe)을 갖추지 못한 것입니다.

그 차이는 중요합니다.

ALLOW라고 적힌 로그는 증거와 같지 않습니다. 소스 URI(source URI)는 읽혔던 소스 상태(source state)와 같지 않습니다. 한쪽이 사후에 작성되었다면, 일치하는 레코드 쌍만으로는 충분하지 않습니다.

그것이 바로 CLAIM-26의 발견 사항입니다:

어떤 행동은, 해당 행동을 승인하는 데 사용된 정확한 소스 스냅샷(source snapshot)을 기록하는 불변의 권한 이벤트(immutable authority event)와 쌍을 이루어야 하며, 이 이벤트는 행동 이벤트(action event) 이전에 또는 행동 이벤트와 원자적(atomically)으로 작성되지 않는 한 감사 안전(audit-safe)하지 않다.

실패 사례

에이전트가 민감한 행동을 취한다고 가정해 봅시다.

나중에 감사자가 다음과 같이 묻습니다:

왜 이 행동이 허용되었습니까?
어떤 소스 상태가 읽혔습니까?
어떤 정책 버전이 활성화되어 있었습니까?
...

취약한 시스템은 다음과 같이 답합니다:

decision: ALLOW

이것으로는 충분하지 않습니다.

또 다른 취약한 시스템은 다음과 같이 답합니다:

source_uri: https://policy-store.internal/policies/active

이것은 더 나은 답변이지만, 여전히 충분하지 않습니다. URI는 행동 이후에 변경된 정책을 가리킬 수 있습니다. 이는 시스템이 어디를 참조했을 가능성이 있는지는 증명하지만, 결정 시점에 시스템이 실제로 무엇을 읽었는지는 증명하지 못합니다.

더 강력해 보이는 시스템은 두 레코드를 모두 작성합니다:

authority event (권한 이벤트)
action event (행동 이벤트)

하지만 이 레코드들이 별도로 작성된다면, 시스템은 여전히 실패할 수 있습니다. 충돌(crash), 순서 변경(reorder), 재시도(retry) 또는 수동 재구성(manual reconstruction)으로 인해 행동 레코드가 행동 이후에 작성된 권한 증거와 쌍을 이루게 될 수 있기 때문입니다.

이것이 미묘한 사례입니다. 실제 엔지니어가 배포할 법한 모습처럼 보입니다.

그리고 이것이 이번 결과에서 흥미로운 기준점(baseline)이 됩니다.

CLAIM-26이 테스트하는 것

이 패킷은 7가지 시나리오를 테스트합니다:

ID	Label	Expected	테스트 내용
1	clean	ALLOW	깨끗한 쌍을 이룬 행동 (Clean paired action)
...

종료 게이트(closing gate)는 PairedAuthorityActionGate입니다.

다음 사항들이 필요합니다:

1. 연결된 권한 이벤트 (linked authority event)
2. 행동과 함께 또는 행동 이전에 작성된 권한 (Authority written before or atomically with the action)
3. 동결된 소스 스냅샷 해시 (frozen source snapshot hash)
4. 일치하는 권한/행동 스냅샷 해시 (Matching authority/action snapshot hashes)
5. 불변의 권한 증거 (Immutable authority evidence)
6. 결정 시점의 소스 상태와 일치하는 스냅샷 해시 (A snapshot hash that matches the source state at decision time)

이는 프로덕션의 완전성을 증명하려는 것이 아닙니다. 구조적 감사 경계 (structural audit boundary)를 테스트하는 것입니다.

결과

첫 번째 실행:

PairedAuthorityActionGate: 7/7
DecisionOnlyGate:          2/7
MutablePointerAuditGate:   2/7
...

전체 비교:

게이트 (Gate)	점수 (Score)	놓치는 부분 (What it misses)
PairedAuthorityActionGate	7/7	이 패킷에서는 없음
...

SeparateWriteGate 결과가 중요합니다.

이 게이트는 7가지 시나리오 중 5가지를 통과합니다. 해시를 보유하고 있으며, 불변성 (immutability)을 확인합니다. 쌍을 이루지 않은 행동 (unpaired actions), 가변 포인터 (mutable pointers), 해시 불일치 (hash mismatches), 그리고 변조된 기록 (tampered records)을 잡아냅니다.

매우 강력해 보입니다.

하지만 여전히 다음을 허용합니다:

post_hoc
audit_gap

이 두 가지 실패가 바로 해당 주장 (claim)의 핵심입니다.

별도 쓰기 (Separate Writes)만으로는 충분하지 않은 이유

post_hoc 시나리오에서는 행동이 먼저 기록됩니다.

권한 이벤트는 나중에 나타납니다.

기록은 사후적으로 일관되어 보일 수 있지만, 권한 이벤트는 행동 이전에 존재하지 않았습니다. 그것은 사전 승인 (prior authorization)이 아닙니다. 그것은 재구성 (reconstruction)입니다.

감사자 (auditor)는 이를 거부해야 합니다.

SeparateWriteGate가 이를 허용하는 이유는 기록의 형태 (shape)를 확인할 뿐, 쓰기 순서 (write order)를 확인하지 않기 때문입니다.

audit_gap 시나리오에서는 권한과 행동 기록이 서로 일치합니다. 스냅샷 해시도 일치합니다. 기록은 불변입니다.

하지만 해시가 결정 시점에 소스가 실제로 제공하고 있던 상태와 일치하지 않습니다.

이 패킷(packet)에서 검증 컨텍스트(verification context)는 그라운드 트루스(ground truth, 실측값)를 직접 제공합니다. 실제 배포 환경에서는 시간 인덱스가 지정된 소스 로그(time-indexed source log) 또는 독립적인 스냅샷 레지스트리(snapshot registry)가 필요합니다. 이는 숨겨진 가정이 아니라 다음 단계의 레이어(layer) 문제입니다.

감사 추적(audit trail)은 내부적으로는 일관적이지만, 외부적으로는 검증이 불가능합니다.

그것이 또 다른 실패 지점입니다.

시스템이 결정(decision) 시점에 동결된 증거(frozen evidence)가 실제 소스 상태(real source state)와 일치한다는 것을 증명할 수 없다면, 감사 추적은 깨끗해 보일지라도 여전히 틀릴 수 있습니다.

왜 이것이 CLAIM-24 및 CLAIM-25와 다른가

CLAIM-24는 다음과 같이 물었습니다:

실행 시점에 소스 조건(source conditions)이 여전히 유지되었는가?

CLAIM-25는 다음과 같이 물었습니다:

서명된 소스 응답(signed source response)이 신뢰할 수 있을 만큼 충분히 최신(fresh)이었는가?

CLAIM-26은 다음과 같이 묻습니다:

행동(action) 이후에, 어떤 권한 증거(authority evidence)가 이를 정당화했는지 증명할 수 있는가?

이것들은 서로 다른 레이어(layer)입니다.

게이트(gate)는 오래된 권한 부여(stale grants)를 차단할 수는 있지만, 여전히 취약한 감사 추적(audit trail)을 남길 수 있습니다.

소스 응답(source response)은 서명되어 있고 최신 상태일지라도, 재구성 가능한 증거(reconstructible evidence)를 생성하는 데 실패할 수 있습니다.

행동(action)은 올바를 수 있지만, 여전히 감사가 불가능(unauditable)할 수 있습니다.

그것이 핵심입니다.

최소한의 감사 안전 형상 (Minimum Audit-Safe Shape)

이 패킷의 최소 형상은 다음과 같습니다:

{
  "authority_event_id": "auth-001",
  "grant_id": "grant-abc",
...

그리고 행동(action)은 반드시 그것을 다시 참조해야 합니다:

{
  "action_id": "act-001",
  "authority_event_id": "auth-001",
...

중요한 부분들:

• 행동(action)이 권한 이벤트(authority event)를 참조합니다.
• 권한 이벤트가 행동과 함께 먼저 작성되었거나 원자적(atomically)으로 작성되었습니다.
• 동일한 스냅샷 해시(snapshot hash)가 두 기록 모두에 나타납니다.
• 권한 기록(authority record)은 불변(immutable)입니다.
• 스냅샷 해시가 결정 시점에 소스(source)가 제공한 것과 일치합니다.

이 중 하나라도 실패하면, 해당 기록이 운영상으로는 유용할 수 있지만 CLAIM-26 하에서는 감사 안전(audit-safe)하지 않습니다.

다음은 실제 상황에서 post_hoc 실패가 어떤 모습인지 보여줍니다 — SeparateWriteGate는 수락하지만 PairedAuthorityActionGate는 거부하는 형상입니다:

{
  "authority_event_id": "auth-003",
  "decision": "ALLOW",
...

{
  "action_id": "act-003",
  "authority_event_id": "auth-003",
...

12:00:02의 행동(Action), 12:00:06의 권한(Authority). 기록은 일관적입니다. 해시(Hash)가 일치합니다. 권한 기록은 불변(Immutable)입니다. 형태(Shape)를 확인하는 게이트(Gate)는 이를 통과합니다. 쓰기 순서(Write order)를 확인하는 게이트는 REFUSED_POST_HOC를 반환합니다. 그 4초의 간격이 사전 승인(Prior authorization)과 재구성(Reconstruction) 사이의 차이입니다.

이 내용이 주장하지 않는 것

이것은 완전한 컴플라이언스 프레임워크(Compliance framework)가 아닙니다.

패킷은 내부적으로 작성되었습니다. 로그(Logs), 해시(Hashes), 소스 상태(Source states), 그리고 기록(Records)은 시뮬레이션된 것입니다. 결과는 7가지 시나리오에 대한 게이트 구조(Gate structure)를 검증합니다. 이것이 SOC 2, HIPAA, 금융, 법적 증거 개시(Legal discovery), 또는 기타 운영 감사(Production audit) 요구 사항을 충족하기에 충분하다는 것을 증명하지는 않습니다.

또한 다음 사항들을 해결하지도 않습니다:

• 분산 트랜잭션 설계 (Distributed transaction design)
• 실제 추가 전용 저장소 선택 (Real append-only storage selection)
• 해시 정규화 (Hash canonicalization)
• 소스 침해 (Source compromise)
• 다중 소스 권한 기록 (Multi-source authority records)
• 감사 스냅샷(Audit snapshots) 저장을 위한 개인정보 보호 규칙 (Privacy rules)
• 보존 기간 (Retention windows)

이것들은 다음 단계의 레이어(Layers)입니다.

더 좁은 범위의 주장은 다음과 같습니다:

만약 에이전트(Agent)가 행동을 취했는데, 시스템이 해당 행동을 '행동이 일어나기 전 또는 행동과 원자적(Atomically)으로 기록된, 승인에 사용된 정확한 소스 스냅샷(Source snapshot)을 포함하는 불변의 권한 증거'와 결합할 수 없다면, 그 행동은 감사 안전(Audit-safe)하지 않습니다.

이는 해당 설계 내에서 이러한 속성들이 구조적으로 필수적임을 증명합니다. 이것이 실제 컴플라이언스 요구 사항에 대해 충분하거나 최적임을 증명하는 것은 아닙니다.

이 주장은 하네스(Harness)가 구축되기 전에 사전 등록되었습니다. 사전 등록 파일은 리포지토리(Repo)에 있습니다: claim_26/CLAIM_26_PREREGISTRATION.md.

재현 방법

하네스는 공개 리포지토리에 있습니다:

cd claim_26
python3 evaluator.py full

결과:

Paired       7/7
Decision     2/7
MutPtr       2/7
...

놀라운 결과는 가장 강력한 게이트가 승리한다는 것이 아닙니다.

유용한 결과는 겉보기에 좋아 보이는 베이스라인(Baseline)조차 여전히 두 곳에서 실패한다는 점입니다.

별도의 쓰기(Separate writes)만으로는 충분하지 않습니다.

권한 이벤트(Authority event)는 반드시 행동 이벤트(Action event)와 쌍을 이루어야 하며, 동일한 스냅샷(Snapshot)에 결합되어야 하고, 행동과 함께 또는 원자적(Atomically)으로 먼저 기록되어야 합니다.

그렇지 않으면, 로그에는 ALLOW라고 표시될 수 있습니다.

하지만 감사 추적(Audit trail)은 그 이유를 증명할 수 없습니다.

CLAIM-26은 2026년 6월 6일에 사전 등록되었습니다. Harness가 구축되었으며 같은 날 첫 실행이 완료되었습니다. 결과는 리포지토리(Repo)에서 재현 가능합니다.

이것은 진행 중인 시리즈의 일부입니다: AI 에이전트의 메모리(Memory) 및 권한(Authority)에 관한 반증 가능한 주장(Falsifiable claims)을 공개적으로 테스트하며, 한계점은 사전에 명시됩니다.