HN 표시: AI 에이전트에 대한 Merkle Mountain Range 감사 로그 및 실행 티켓

LICITRA-MMR is a tamper-evident audit ledger for AI agent systems that makes any retroactive modification to agent actions cryptographically detectable using a Merkle Mountain Range (MMR). Every action taken by an AI agent is committed to an append-only cryptographic structure. If any historical event is modified — even a single byte — the Merkle root changes and verification fails. The design uses a Merkle Mountain Range (MMR), an append-only authenticated data structure widely used in blockchain-adjacent systems, and adapts it for AI runtime accountability. Verification of any individual event requires O(log n) hashing operations using Merkle inclusion proofs, allowing large ledgers to be audited efficiently. - Relationship to LICITRA-SENTRY - Core Security Invariant - The Problem - How It Works - Architecture - API Reference - Quick Start - Environment Modes - Test Suite - Experiments - Evidence Bundles - Inclusion Proofs - Project Structure - Design Decisions - Citation - References - License LICITRA-MMR provides the tamper-evident audit ledger for the LICITRA runtime security architecture. - LICITRA-SENTRY enforces runtime authorization for AI agents using execution tickets and mandatory mediation. - LICITRA-MMR records the resulting actions in an append-only cryptographic ledger. Together they provide both: - Runtime enforcement of agent permissions - Post-execution cryptographic verifiability of agent actions If any historical event is modified, the MMR root hash changes and ledger verification fails. tamper(event_i) → leaf hash changes → ancestor nodes change → MMR root mismatch → epoch hash mismatch → ledger verification failure This invariant guarantees that agent activity cannot be silently altered after the fact. Log files can be deleted. Databases can be edited. Timestamps can be forged. LICITRA-MMR makes tampering cryptographically detectable, not just policy-prohibited. Agentic AI systems act autonomously — browsing the web, writing code, calling APIs, managing files. There is currently no standard mechanism to prove, after the fact, that an agent did exactly what it claims to have done, and nothing more. Current approaches store audit records in mutable databases. An operator with database access — or an attacker who compromises the operator's infrastructure — can rewrite historical records without detection. Regulators, auditors, and counterparties must trust the operator's infrastructure. LICITRA-MMR provides cryptographic tamper-evidence: any modification to any event, at any point in history, is mathematically detectable through Merkle root divergence. Every agent action is serialized to canonical JSON — keys sorted alphabetically, no whitespace — and hashed with SHA-256. Key order is irrelevant: the same logical payload always produces the same hash. canonical_json = sort_keys(payload) leaf_hash = SHA256(canonical_json) Each leaf_hash is appended to a binary MMR. Internal nodes are computed as: node_hash = SHA256(left_child || right_child) The MMR root summarizes the entire ledger at any point in time. Any modification to any historical leaf changes every ancestor node up to the root. Every 1,000 events (configurable via BLOCK_SIZE ), the MMR is sealed into an epoch: epoch_hash = SHA256(prev_epoch_hash || mmr_root || canonical_metadata) Epochs chain together like blockchain blocks. Modifying epoch N breaks the hash of epoch N+1, N+2, and every subsequent epoch. The genesis epoch uses prev_epoch_hash = "00" * 32 . No event enters the ledger without passing a policy check: POST /agent/propose → policy engine evaluates risk → APPROVED or REJECTED (both recorded) POST /agent/commit → only APPROVED proposals can be committed Rejected proposals are retained in the staged events table — a permanent audit trail of what was attempted and why it was blocked. Each organization has a completely independent MMR, epoch chain, and event sequence. Tampering with one org's ledger has zero effect on any other org's cryptographic state. Figure 1 — LICITRA-MMR pipeline: agent actions pass through policy evaluation, canonical serialization, SHA-256 hashing, MMR append, and epoch sealing before commitment to persistent storage. Rejected proposals are permanently recorded in staged_events. ┌─────────────────────────────────────────────────────┐ │ FastAPI Service │ ├──────────────┬──────────────┬───────────────────────┤ │ /agent │ /verify │ /evidence /proof │ │ propose │ full chain │ JSON + PDF bundles │ │ commit │ validation │ inclusion proofs │ └──────┬───────┴──────┬───────┴───────────────────────┘ │ │ ┌──────▼──────┐ ┌─────▼──────────────────────────────┐ │ Policy │ │ PostgreSQL 16 │ │ Engine │ │ events │ mmr_nodes │ epochs │ │ hard rules │ │ staged_events │ │ risk score │ └──────────────────────────────────────┘ └─────────────┘ Stack: Python 3.12 · FastAPI · PostgreSQL 16 · SQLAlchemy · reportlab The API layer orchestrates a pipeline consisting of canonical JSON serialization, SHA-256 hashing, MMR append