Aegis Latent Core

AI 治理与密码学证据网关

Aegis Latent Core 在响应到达调用方之前，为每一次受治理的 AI 调用提交已签名、哈希链接的证据——并签发一份可移植证明，使第三方无需信任网关、我们或你即可验证。

本文件中的每一项关键主张都带有定位符和明确的边界；强制执行这一纪律的门禁在 CI 中运行。

当前版本： v5.0.1 —— 最新发布的版本（检出的源码为 v5.0.2，这是一个 Apache-2.0 源码目标，尚未发布），于 2026-09-24 在所有渠道发布（PyPI aegis-latent-core 5.0.1 于 2026-09-26 跟进），并于同日回读（Release Status §1.0a）。Sigstore 签名的标签通过 gitsign verify-tag；GitHub Release 包含 31 个资产，其 SHA256SUMS 中列出的全部 15 个文件重新哈希后均与摘要一致；PyPI aegis-latent-sdk 5.0.1 和 npm aegis-latent-sdk 5.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、PyPI aegis-latent-core 4.1.2、PyPI aegis-latent-sdk 4.1.2、npm aegis-latent-sdk 4.1.2，以及 GHCR 网关和仪表盘镜像。4.1.2 是第一个可从 PyPI 以 aegis-latent-core 安装的版本；在此之前，网关只能从源码或 GHCR 获取。npm 版本列表跳过了 4.1.1，其发布步骤失败。还存在一个 v4.1.0 发布对象，但它是在流水线之外创建的，不包含任何资产；请忽略它。两个 4.1.2 PyPI 网关产物与同名发布资产逐字节不同——内容相同，构建主机不同——因此 SHA256SUMS 不覆盖这些下载；5.0.1 的 PyPI 网关产物则与其一致。有关来源和回读，请参见 Release Status。

问题所在

你的 AI 决策被记录到一个管理员可以编辑的数据库中。当有人问起六个月前模型被告知了什么时，你只能依据利益相关方本可以修改的记录来回答。

在受监管行业中，这不是文书问题——而是生存问题。监管机构、法院和审计师各自都会问同一个问题，而“我们的日志大概没问题”不是他们会接受的答案：

利益相关方本可以篡改的记录不是证据——它只有在没有人有理由质疑时才读起来像证据，一旦有人提出一个问题，它就不再是。
你已经欠某人一份你能为之负责的记录——EU AI Act 第 12 条、HIPAA 审计控制、SEC 17a-4 的审计追踪替代方案、MiFID II。那些是你的义务；本软件是履行这些义务的一项输入，绝不是对它们的免除。
修复方案必须能被不信任你的人核查，否则就只是同一个问题换上了更好的外衣。

Aegis 解决方案

仅追加、防篡改的 MMR。 每条记录都是 Merkle Mountain Range 中的一个叶子。一份可移植的包含证明（O(log n)，不涉及零知识声明）让第三方能够依据其独立获得的根来验证一条已披露的记录。verify_integrity() 在读取时检测篡改；篡改是被检测到，而非被阻止——请参见下方的边界说明。
密码学密封。 每条记录被哈希进一个链环并签名——默认使用 HMAC，在配置的情况下使用 Ed25519（RFC 8032）或 ML-DSA-65（FIPS 204），企业服务器中还有 HSM 路径。可选的按主体粉碎（AES-256-GCM 密钥销毁）从密文持有者的视角抹除明文，而不改变 MMR 根或先前已签发的证明。
零信任验证。 证明可离线验证：一个 313 行的纯 Python 验证器、一个语义相同的 TypeScript 孪生实现，以及零网络调用。不信任网关、供应商或披露记录的操作者——只信任你通过披露方无法控制的渠道获得的根。
监管输入。 MiFID II 第 16(6)/16(7) 条和 MiFIR 第 25(1) 条记录保存框架（持久、进程内有序的记录；不涉及订单——RTS 24——也不涉及时钟可追溯性——RTS 25）；EU AI Act 第 12 条日志输入（响应前提交、篡改检测、可验证包含）；HIPAA 安全港式模式脱敏；ISO/IEC 27037 式提取。这些是技术输入，不是合规。 不存在任何认证，也没有任何认证在进行中，是否满足任何义务由你和你的评估人判定（CLM-039 为 LEGAL-REVIEW-REQUIRED）。

→ 自己证明它 —— 十二行 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。一份精确字节的终端摘要被提交，只有在此之后才发出终端标记。如果该提交失败，标记将被扣留。

故障关闭。 没有签名器、没有分布式限流器，或账本无法重放，就意味着不提供服务——而不是悄悄地为无证据的流量提供服务。

详情：Architecture · Failure Semantics

真实世界基准测试

来自保留的 2026-09-24 产物的真实测量数据（evidence/benchmarks/benchmarks_5.0.1_2026-09-24.json），针对真实后端采集——每次提交一次真实的 WAL fsync——在一个共享、未固定 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,727 次提交/秒（10 线程）· 1,630/秒（50）· 1,482/秒（100）	单进程、单 WAL、单写入者——按设计不随线程扩展（`AD-16`）
内存	+20.1 MB RSS，用于 1,000 个并发进程内 SSE 流（每个 20 个事件）	有界流摄取，而非网络或持久 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），并未强制执行。

这一切都不是容量主张。 提供的负载不等于接受的吞吐量。绝对延迟是单个共享容器的属性；可迁移的是形状——每次提交的成本不再随链长度增长——而不是那些数字。在依据其中任何一项进行规划之前，请在你自己的环境中重新运行测试工具。

Evidence Index · Benchmark Method · Benchmark Record

快速开始

三个步骤，可复制粘贴。首先诚实地说明渠道：pip install aegis-latent-core 安装的是 5.0.1（2026-09-29 回读，CLM-113）；在 5.0.0 时网关从未上过 PyPI（UC-047，作为历史保留）。你也可以使用本仓库、GHCR 镜像 ghcr.io/juanlunaia/aegis-latent-core:5.0.1，或附加在 v5.0.1 GitHub Release 上的 wheel。

步骤 1 —— 获取源码：

git clone https://github.com/JuanLunaIA/aegis-latent-core.git && cd aegis-latent-core
python3 -m venv .venv && . .venv/bin/activate
python -m pip install --require-hashes -r requirements.lock
python -m pip install --no-deps -e .

步骤 2 —— 运行它（隔离的本地评估，针对 127.0.0.1:9999 上的模拟上游）：

export AEGIS_SECURITY_ENFORCEMENT_MODE=development
export AEGIS_DEBUG_MODE=true
export AEGIS_AUTH_DISABLED=true
export AEGIS_BACKEND_URL=http://127.0.0.1:9999
aegis

aegis-latent-core

最受欢迎