AuthProof 是一种面向代理型 AI 的加密授权协议。该领域的大多数协议都基于操作员定义的策略执行——赋予操作员在事后扩展或重新解释用户原始意图的权力。AuthProof 基于不同的信任模型构建：用户自己的私钥签署控制执行的授权对象，并且在授权时和执行前立即验证实时模型状态。用户签署的权限与实时模型状态门控的结合是具体的主张——而非广泛的执行叙事。
不同之处在于：
用户是签署权威。 每个竞争协议（AIP、AITH、OAP、SAGA、AgentSpec）都基于操作员定义的策略执行。在 AuthProof 中，用户的私钥直接签署授权对象。操作员不能在用户签署后扩大范围。
两阶段模型状态承诺。 在授权时测量模型，并在执行前立即重新测量。如果模型在这两点之间发生漂移，则在前置执行验证时阻止执行。
区分提供者更新与恶意替换。 该协议将模型状态变更分为两类：合法的提供者更新（PROVIDER_UPDATE_REQUIRES_REAUTH）和未经授权的替换（MALICIOUS_MODEL_SUBSTITUTION）。每种都会生成一个机器可读的拒绝原因代码，标识哪些组件发生了变化。
在任何代理操作执行前运行的确定性门控。
PreExecutionVerifier 位于代理运行时之外。运行时在验证器通过之前永远不会获得控制权。受损或恶意的代理无法跳过它——它在运行时启动之前运行。
传统的授权检查发生在代理运行时内部。如果运行时被攻破，这些检查可以被跳过、重排序或绕过。PreExecutionVerifier 通过将授权完全移出运行时来消除这一攻击面。代理只有在——且仅当——所有六项顺序检查首先通过时才会执行。
import { PreExecutionVerifier, DelegationLog } from 'authproof-sdk/pre-execution-verifier' import { RevocationRegistry } from 'authproof-sdk'
// 1. Set up the gate const delegationLog = new DelegationLog() const revocationRegistry = new RevocationRegistry() await revocationRegistry.init({ privateKey, publicJwk })
const verifier = new PreExecutionVerifier({ delegationLog, revocationRegistry }) await verifier.init({ privateKey: verifierKey, publicJwk: verifierPub })
// 2. Register your delegation receipt delegationLog.add(receiptHash, receipt)
// 3. Gate every action â before the agent runs const result = await verifier.check({ receiptHash, action: { operation: 'read', resource: 'calendar' }, operatorInstructions: 'Summarize meetings. Stay within scope.', programHash, // optional: prevents code substitution attacks })
if (!result.allowed) {
throw new Error(Blocked: ${result.blockedReason})
}
// Agent runtime only reaches here after all six checks pass
### 六项顺序检查（在首次失败时停止）
| # | 检查项 | 阻塞条件 |
|---|-------|-------------|
| 1 | 收据签名 | ECDSA P-256 签名无效或收据被篡改 |
| 2 | 撤销 | 收据已通过 `RevocationRegistry` 撤销 |
| 3 | 时间窗口 | 收据已过期或尚未生效（日志时间戳预言机，非客户端时钟） |
| 4 | 作用域 | 操作不在 `ScopeSchema.allowedActions` 中或基于文本的作用域匹配失败 |
| 5 | 操作指令 | 当前指令与签发时锁定在收据中的哈希不匹配 |
| 6 | 程序哈希 | 提供的 `programHash` 与提交的 `executes` 哈希不匹配（防止代码替换） |
每个检查结果——通过或失败——都会自动记录到由验证者自己的密钥签名的不可变 `ActionLog` 中。
### 中间件集成
常见框架的即插即用封装器。每个封装器在包装的代码执行之前，通过 `PreExecutionVerifier` 对每次调用进行门控。
- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — 包装任何具有 `invoke()` 方法的代理
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — 适用于任何兼容 Express 的框架的请求中间件
- **[通用函数封装器](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — 包装任何异步函数```js
// LangChain
import { authproofMiddleware } from 'authproof-sdk/middleware/langchain'
const guardedAgent = authproofMiddleware(agent, { receiptHash, verifier })
// Express
import { authproofMiddleware } from 'authproof-sdk/middleware/express'
app.use(authproofMiddleware({ verifier, getReceiptHash: (req) => req.headers['x-receipt-hash'] }))
// Any function
import { guardFunction } from 'authproof-sdk/middleware/generic'
const guardedExecute = guardFunction(executeAction, { receiptHash, verifier, action })
所有现有的 IETF 代理身份框架——AIP、draft-klrc-aiagent-auth、WIMSE——都涉及服务到代理的信任：即下游服务如何验证某个代理有权调用它。它们都没有涉及用户到操作者的信任。
当前代理系统中的委托链是：``` User â Operator â Agent â Services
用户指示操作员。操作员指示代理。但在委托时刻，不存在用户原始意图的加密记录。操作员成为拥有不受制约权力的可信第三方，可以在指令到达代理之前对其进行扩展、扭曲或省略。
后果：
- 用户无法证明他们授权了什么。
- 监管者没有审计追踪。
- 法院没有证据链。
- 代理无法区分合法的操作员指令与受损害或恶意的操作员指令。
AuthProof 填补了这一空白。
---
## 核心原语：委托收据（Delegation Receipt）
**委托收据**是一个已签名的授权对象，在任何代理行为开始之前，它被锚定到去中心化的仅追加日志中。它包含四个必填字段：
### Scope
允许操作的显式白名单。未列出的一切默认被拒绝。以结构化格式表达——而非自然语言。操作类别：
| 类别 | 描述 |
|---|---|
| `reads` | 对指定资源的读取权限 |
| `writes` | 对指定资源的写入权限 |
| `deletes` | 删除指定资源 |
| `executes` | 执行特定程序，通过其**静态能力签名哈希**引用 |
`executes` 是最危险的类别。它必须引用 Safescript 程序静态能力 DAG 的加密哈希——而非名称、URI 或描述。哈希不匹配意味着不能执行。
### Boundaries
在任何情况下都不能被操作员指令覆盖的显式禁止项。由用户定义的硬性限制，在后续任何操作员指令中依然生效。
### Time Window
授权有效期。**日志时间戳**是时间神谕——而非客户端时钟。客户端时钟被明确排除在时间验证之外。
### Operator Instruction Hash
委托时操作员所述指令的加密哈希。如果操作员随后以不同方式指示代理，则差异可从日志中检测，无需任何额外的信任假设。
用户通过 **WebAuthn/FIDO2 使用设备安全飞地**，用其私钥签署此对象。签名在任何代理行为之前发布到日志中。每个后续代理行为都引用该收据的哈希。超出 scope 的行为在密码学上无效。
---
## 信任栈架构
三个协议层消除了三个可信第三方：
### 第 1 层——已签名的能力清单（*消除对注册中心的信任*）
在当前的 MCP 生态系统中，不存在密码学证明来确保工具服务器的描述与其实际行为一致。操作员可以呈现任意的模式。
修复方法：工具服务器在任何用户授权发生之前，发布**密码学签名的能力清单**。委托收据的 `scope` 字段引用该**清单的哈希**——而非操作员自报的模式。服务器行为与清单之间的偏差可在日志层检测到。
### 第 2 层——委托收据（*消除对操作员的信任*）
用户的原始意图在操作员指令到达代理之前被不可篡改地记录。操作员偏离是可证明的。
### 第 3 层——Safescript 执行（*消除对代码的信任*）
[Safescript](https://github.com/safescript) 是一个用于 AI 代理执行的开源沙盒语言。其静态 DAG 结构意味着每个程序的完整能力签名可在运行前计算——没有动态分发，没有运行时能力扩展。
`executes` scope 类别引用特定的 Safescript 能力签名哈希。如果操作员提供的程序不匹配已提交的哈希，则执行被阻止。委托后，代理不能替换为另一个程序。
---
## 快速开始
---```js
import { AuthProof, Scope, KeyCustody } from 'authproof-sdk';
// Initialize with hardware-backed key custody (recommended)
const authproof = new AuthProof({
custody: KeyCustody.HARDWARE, // WebAuthn/FIDO2 via device secure enclave
log: 'https://log.authproof.dev',
});
// Define permitted operations â explicit allowlist, deny-by-default
const scope = new Scope()
.allow('reads', ['resource://calendar/events', 'resource://email/inbox'])
.allow('writes', ['resource://calendar/events'])
.deny('deletes', '*')
.execute('sha256:a3f1c9d8...', { program: 'scheduler-v1.sg' }); // Safescript hash
// Hard limits that survive any operator instruction
const boundaries = {
never: ['external-network', 'credential-store', 'payment-methods'],
};
// Issue the Delegation Receipt â anchored to log before any agent action
const receipt = await authproof.delegate({
scope,
boundaries,
window: { duration: '8h' }, // validated against log timestamp
operatorInstructions: instructionText, // hashed and committed
});
// receipt.id â unique receipt identifier
// receipt.hash â reference in every agent action
// receipt.log â append-only log anchor
// Agent-side: validate an action against the receipt
const check = await authproof.validate({
receiptHash: receipt.hash,
action: { class: 'writes', resource: 'resource://calendar/events' },
});
if (!check.authorized) {
// Out-of-scope action: surface a micro-receipt request to the user
const microReceipt = await authproof.requestMicroReceipt({
action: check.requestedAction,
parent: receipt.hash,
});
}
对于原始委托收据未涵盖的工具调用，代理不能静默执行。协议规定：
未知操作需要明确的新用户授权。依赖解析遵循相同规则 —— 依赖项会根据委托时提交的依赖清单哈希进行检查。意外依赖属于范围违规。
每个委托事件携带唯一的收据 ID。并发代理各自引用自己的收据哈希。它们通过收据而非代理身份加以区分。
| 模型 | 描述 | 推荐 |
|---|---|---|
| 硬件 | 通过设备安全飞地使用 WebAuthn/FIDO2。私钥绝不离开硬件。 | 是 —— 默认 |
| 委托 | 受信任的密钥管理器代表用户持有密钥。 | 不支持 FIDO2 的环境 |
| 自托管 | 用户持有并管理自己的私钥。 | 高级用户、气隙工作流 |
硬件托管是推荐的默认方式。私钥绝不离开安全飞地；签名受设备生物识别或 PIN 保护。
委托收据定义了 AI 代理被授权执行的操作。操作日志 记录了它实际执行的操作 —— 并使得任何偏差均可即时验证。
代理采取的每个操作都会生成一条已签名、带时间戳的条目，并关联到当前生效的收据。条目形成防篡改链：每个条目嵌入前一条目的 SHA-256 哈希，因此任何追溯性修改都可在无需可信第三方的情况下被检测到。diff() 方法是审计原语 —— 它将收据的授权范围与每条记录的操作进行比对，并返回任何偏差。```js
import AuthProof, { ActionLog } from 'authproof-sdk';
// 1. Issue a delegation receipt as normal const { privateKey, publicJwk } = await AuthProof.generateKey();
const { receipt, receiptId } = await AuthProof.create({ scope: 'Search the web for competitor pricing. Read calendar events.', boundaries: 'Do not send emails. Do not make purchases.', instructions: 'Cite sources. Keep under 500 words.', ttlHours: 4, privateKey, publicJwk, });
// 2. Initialize the action log with the agent's signing key const log = new ActionLog(); await log.init({ privateKey, publicJwk });