
AI 시스템을 위한 자체 호스팅 증거 게이트웨이: fail-closed 정책, WAF, 이그레스 제어, 서명된 내구성 MMR 증명, 그리고 LLM 제공자 전반에 걸친 오프라인 검증.
AI 거버넌스 및 암호화 증거 게이트웨이
Aegis Latent Core는 모든 거버넌스된 AI 호출에 대해 서명되고 해시로 연결된 증거를 — 응답이 호출자에게 도달하기 전에 — 커밋하며, 게이트웨이, 우리, 또는 당신을 신뢰하지 않고도 제3자가 검증할 수 있는 이식 가능한 증명을 발급합니다.
이 파일의 모든 핵심 주장에는 위치 지정자와 명시된 경계가 따르며, 이 규율을 강제하는 게이트는 CI에서 실행됩니다.
현재 릴리스:
v5.0.1— 최신 공개 릴리스(체크아웃된 소스는v5.0.2로, 공개되지 않은 Apache-2.0 소스 대상입니다), 2026-09-24에 모든 표면에서 공개되었으며(PyPIaegis-latent-core5.0.1은 2026-09-26에 뒤따랐습니다), 같은 날 다시 읽어 확인했습니다(Release Status §1.0a). Sigstore 서명 태그는gitsign verify-tag를 통과합니다. GitHub Release는 31개의 자산을 포함하고 있으며,SHA256SUMS에 나열된 15개 파일 모두 해당 다이제스트로 재해시됩니다. PyPIaegis-latent-sdk5.0.1과 npmaegis-latent-sdk5.0.1은 동일한 이름의 릴리스 자산과 바이트 단위로 동일합니다. GHCR 게이트웨이 및 대시보드 이미지는cosign verify를 통과하고 빌드 출처 증명이 검증되며, 각각 정확한 게시 워크플로 신원에 대해 검증됩니다. 게이트웨이 배포판aegis-latent-core는 2026-09-26에 PyPI에서5.0.1에 도달했습니다 (publish_pypi_gateway.yml의 실행36224961909, 2026-09-29에 다시 읽음, Release Status §1.0b).pip install aegis-latent-core는5.0.1로 해석되며, 해당 wheel과 sdist는 릴리스 자산과 바이트 단위로 일치합니다. GHCR 이미지와 Release 자산은 계속 사용 가능합니다. 이전 릴리스인v5.0.0은 2026-09-16에 동일한 표면에서 공개되었습니다(§1.0).4.2.0은 존재하지 않습니다. 해당 번호는 건너뛰었습니다.게이트웨이가 PyPI에 처음 공개된 버전:
v4.1.2, 2026-09-04에 다시 읽음 — 서명된 주석 태그, 31개 자산이 포함된 GitHub Release, PyPIaegis-latent-core4.1.2, PyPIaegis-latent-sdk4.1.2, npmaegis-latent-sdk4.1.2, 그리고 GHCR 게이트웨이 및 대시보드 이미지.4.1.2는 PyPI에서aegis-latent-core로 설치 가능한 첫 번째 버전입니다. 그 이전에는 게이트웨이가 소스 또는 GHCR에서만 제공되었습니다. npm 버전 목록은 게시 단계가 실패한4.1.1을 건너뜁니다.v4.1.0릴리스 객체도 존재하지만 파이프라인 외부에서 생성되었으며 자산을 포함하지 않습니다. 무시하십시오. 두 개의4.1.2PyPI 게이트웨이 아티팩트는 동일한 이름의 릴리스 자산과 바이트가 다르므로(동일한 내용, 다른 빌드 호스트)SHA256SUMS가 해당 다운로드를 포함하지 않습니다.5.0.1PyPI 게이트웨이 아티팩트는 일치합니다. 출처 및 재확인에 대해서는 Release Status를 참조하십시오.
귀하의 AI 결정은 관리자가 편집할 수 있는 데이터베이스에 기록됩니다. 누군가 6개월 전에 모델에게 무엇이 전달되었는지 물을 때, 귀하는 이해관계자가 변경할 수 있었던 기록을 근거로 답변하게 됩니다.
규제 산업에서 이것은 서류상의 문제가 아니라 존재론적 문제입니다. 규제 기관, 법원, 감사인은 각각 같은 질문을 하며, "우리 로그는 아마 괜찮을 것입니다"는 그들이 받아들이는 답변이 아닙니다:
verify_integrity()는 읽기 시 변조를 감지합니다. 변조는 감지되지만 방지되지는 않습니다 — 아래 경계를 참조하십시오.CLM-039는 LEGAL-REVIEW-REQUIRED입니다).→ 직접 증명하십시오 — 12줄의 Python, 우리 서버 호출 없음, 세 가지 사례로 그중 두 가지는 실패해야 합니다.
pip install aegis-latent-sdk aegis-latent-core # verifier + gateway, both 5.0.1 on PyPI python tools/sales/prove_it/prove_it.py --demo # accepts one record, rejects two forgeries python -m examples.demo # gateway + mock upstream, tamper detected두 명령 모두 이 저장소의 체크아웃에서 실행됩니다. 각 명령이 보여주는 것과 보여주지 않는 것.
caller ──────────► Aegis gateway ──────────────────────────► upstream provider
│ admission: auth · scope · bounds
│ WAF · rate limiting · session checks
│
│ (policy passed) forward
│ ◄─────────────── response ─────────
│
│ redact → hash → sign → WAL append + fsync → MMR leaf
│ (refused requests: the refusal is committed to the
│ same signed chain before the error returns)
│
caller ◄────────── response + X-Aegis-Evidence-Status
+ X-Aegis-Request-ID + X-Aegis-MMR-* proof headers
비스트리밍. 증거 레코드는 응답이 호출자에게 관찰 가능해지기 전에 커밋됩니다.
스트리밍. 정제된 이벤트는 증거 상태가 pending-terminal을 읽는 동안 경계가 있고 바이트로 계산된 큐를 통해 점진적으로 방출됩니다. 정확한 바이트의 터미널 요약 하나가 커밋되고, 그 후에야 터미널 마커가 방출됩니다. 해당 커밋이 실패하면 마커는 보류됩니다.
Fail-closed. 서명자 없음, 분산 제한기 없음, 또는 재생에 실패하는 원장은 서비스 없음을 의미합니다 — 증거 없는 트래픽을 조용히 제공하는 대신에.
세부 사항: Architecture · Failure Semantics
보존된 2026-09-24 아티팩트(evidence/benchmarks/benchmarks_5.0.1_2026-09-24.json)에서 얻은 실제 측정값으로, 실제 백엔드에 대해 — 커밋당 실제 WAL fsync — 하나의 공유되고 고정되지 않은 4-CPU x86_64 컨테이너(Linux, CPython 3.11.15)에서 수행되었습니다. scripts/run_benchmarks_5.0.1.py --json으로 재현하십시오.
| 지표 | 결과 (2026-09-24) | 측정 대상 |
|---|---|---|
| 커밋 지연 (P99) | 1.22 ms (p50 0.62 · p95 1.00 · max 4.18 ms, n = 1,000) | 커밋당 MMR 추가 + HMAC 서명 + 실제 WAL fsync 1회 |
| 처리량 | 10 스레드에서 1,727 커밋/s · 50에서 1,630/s · 100에서 1,482/s | 하나의 프로세스, 하나의 WAL, 하나의 작성자 — 설계상 스레드에 따라 확장되지 않음(AD-16) |
| 메모리 | 1,000개의 동시 인프로세스 SSE 스트림(각 20 이벤트)에 대해 +20.1 MB RSS | 경계가 있는 스트림 수집, 네트워크 또는 내구성 있는 WAL 비용이 아님 |
| 백프레셔 (현재) | p50 33.545 ms · p99 51.875 ms; 2,500 제공 → 2,500 내구성, 실패 제로 | 2 ms 주입된 fsync 지연; 대체된 그룹 커밋 이전 실행은 p99 836.35 ms; 이전의 10,000 레코드 실행 p99 1,189.89 ms는 철회됨(UC-018) — 이 트리의 어떤 아티팩트도 이를 생성하지 않음 |
| Ed25519 서명 / 검증 | 40.5 µs/op · 128.6 µs/op (cryptography, RFC 8032) | 기록된 호스트에서의 장치 차수 크기 타이밍 |
| ML-DSA-65 서명 / 검증 | 173.0 µs/op · 62.4 µs/op (aegis_rust, FIPS 204) | 지연 샘플일 뿐 — 상수 시간 주장은 여전히 차단됨(REG-041, UC-012) |
측정된 스위트(날짜가 기록된 레코드, 테스트가 추가됨에 따라 수치가 변동 — 평가하는 커밋에서 pytest -q 실행): 7,444 통과 / 39 건너뜀 / 0 실패(pytest -n auto -q) 및 7,449 통과 / 34 건너뜀 / 0 실패(CI의 정확한 직렬 Forensic 명령), 둘 다 2026-09-24 체크아웃된 5.0.1 트리에서. 문장 커버리지: 91.30% (2026-09-24; 같은 날 이후 실행에서 91.25%). CI가 강제하는 하한은 65% (--cov-fail-under=65, .github/workflows/ci.yml)입니다. 90% 수치는 일회성 미션 하한으로, 2026-09-21에 90.07%로 충족되었으며(REG-D36) 강제되지 않습니다.
이 중 어느 것도 용량 주장이 아닙니다. 제공된 부하는 수용된 처리량이 아닙니다. 절대 지연은 하나의 공유 컨테이너의 속성입니다. 전이되는 것은 형태 — 커밋당 비용이 체인 길이에 따라 증가하는 것을 멈춤 — 이지 숫자가 아닙니다. 이들 중 어느 것에 대해서도 계획하기 전에 자신의 환경에서 하네스를 재실행하십시오.