我为 AI 代理构建了密码学审计轨迹。原因如下。

Source: Dev.to

没有人解决好的问题

这里有一个日益常见的情景。你部署了一个 AI 代理，它会处理客户请求、访问数据库、调用外部 API，并代表用户执行操作。它运行了一周后，出现了问题。某位客户投诉出现了未经授权的更改。你的团队提出了显而易见的问题：这个代理到底做了什么？

你查看日志。日志是文本文件，可能是数据库中的 JSON 行。日志显示代理执行了 X、Y、Z 操作。但这些日志是可变的。任何拥有写权限的人都可能对其进行修改，代理本身也可能修改日志。没有加密证明能够保证日志的准确性。

这就是 2026 年代理可追溯性的现状。代理正获得对生产数据库、金融系统和客户数据的访问权限。大多数团队用于审计的手段仅是 print() 语句和希望。代理能够做的事与我们能够证明它们所做之事之间的差距正在快速扩大。

底层模式

这不是一个新问题。它是一个被换了新装的已被充分理解的问题。分布式系统在几十年前就用追加日志、哈希链和密码签名解决了这类问题。模式很简单：让每一次操作生成一个记录，并在数学上链接到前一个记录。如果有人在中间修改了记录，所有后续的链接都会断裂。篡改不仅变得困难，而且会显而易见。

大多数代理框架不采用这些技术的事实并不是技术缺口，而是注意力缺口。工具已经存在。密码学原语已经成熟。没有人把它们组合起来用于 AI 代理行为的特定场景。

于是我做了。

Sigil 的作用

Sigil 为 AI 代理提供防篡改的审计追踪。每一次代理操作都会生成一个证明（attestation），即带有签名和时间戳的记录，其中包含前一个证明的哈希。这形成了一条哈希链。每个证明都使用 Ed25519 进行签名，这是一种快速且研究成熟的签名方案。签名证明该证明是由特定密钥在特定时间创建的。

每个代理拥有各自独立的哈希链。没有全局瓶颈，也不存在代理之间的交叉污染。架构刻意保持简洁，因为信任基础设施应当易于推理。

Sigil 以 MCP 服务器的形式提供。如果你使用任何兼容 MCP 的客户端（Claude Code、OpenHands 或你自己的），只需添加 Sigil 即可立即开始记录证明。

from sigil import SigilClient

client = SigilClient(api_key="sg_...")

# Record an action
receipt = client.attest(
    action_type="database.query",
    payload={"table": "customers", "rows_returned": 142}
)

# Verify the chain is intact
result = client.verify(receipt.id)
assert result.valid and result.chain_valid

每个证明包括：

• agent_id
• action_type
• payload
• timestamp
• prev_hash（SHA‑256 链接）
• signature（Ed25519）

该链是只追加的、可查询的，并且可以独立验证。

为什么开源

MCP 服务器和 Python SDK 使用 MIT 许可证。您可以自行托管整个堆栈。这是一个刻意的选择，而非增长策略。信任基础设施应当是可检查的。如果您无法阅读生成审计日志的代码，您实际上并没有解决信任问题。您只是把问题转移了。

接下来会怎样

Sigil 采用分层结构，每一层都建立在下层之上：

• Notary（当前可用）：哈希链式证明和验证
• Identity（计划中）：使用 Ed25519 密钥对的代理 PKI
• Delegation（计划中）：授权链的加密证明

我还在与流行的代理框架进行集成，以实现自动记录证明。目标是让可审计成为默认，而非例外。

Try It

pip install sigil-notary

GitHub:
PyPI:

我为将代理部署到生产环境的开发者构建了这个工具。如果你是这类用户，请打开 issue、发起讨论，或直接联系我。

Sigil 的意思是“权威的印章”。我认为 AI 代理需要一个这样的印章。