InterAI Risk Oracle

InterAI 风险预言机

面向重要 Agent 操作的独立执行前决策层。

Agent 执行之前，InterAI 先行验证。

我是 Alejandro Bolognese，通过 InterAI Labs 构建 InterAI，持续探索 Agent 基础设施、执行控制、信任边界和生产系统。

实时演示：操作边界实验室 · 受控安全演示 · 架构与权限边界 · OpenAPI

InterAI 位于自主 Agent 与重要操作之间。Agent 提出想要执行的操作；InterAI 会结合上下文评估该操作，应用权威的主机／账户约束以及任何按请求指定的调用方约束，并返回机器可读的权限决策：

proposed action
      |
      v
   InterAI
      |
      +--> ALLOW
      +--> REVIEW_REQUIRED
      +--> BLOCK
      |
      v
 signed trust receipt

关键问题不只是**此主体在技术上能否执行该操作？**而是：

在此时此地、依据此政策，是否应该执行这项特定操作？

因此，InterAI 与身份验证、权限、支出限额、工作流规则和特定领域的控制措施互为补充，而非取而代之。

InterAI 的定位

Identity / authentication
  "Who is this?"
        |
Permissions / deterministic limits
  "Can this principal do this class of operation?"
        |
InterAI
  "Should this exact proposed action execute in this context?"
        |
Execution / escalation / abort

当 Agent 即将执行会产生实际后果的操作时，请使用 InterAI：执行工具、转移资金、更新生产环境状态、审批工作流、签署钱包操作、发送外部消息，或触发其他不可逆或成本高昂的操作。

决策契约

对于自主执行请求，InterAI 的核心权限契约包括：

• recommended_action：allow、review_required 或 block
• policy_result：有效政策下的权限结果
• policy_violations：适用时的明确政策发现
• trust_receipt_id：持久化的决策证据
• execution_intent_digest：用于标识已评估的确切意图的确定性标识符
• 已认证决策回执中的有效主机／账户／调用方政策来源信息

review_required 表示当前 Agent 不应依据当前政策自主执行。审核可由主管 Agent、政策系统、治理队列、钱包规则或人工操作员处理。

精确操作绑定

对于可执行的试点授权，宿主机构建受信任的操作信封 interai-canonical-action/v1 和由宿主机证明的执行上下文 interai-host-execution-context/v1。InterAI 返回 CanonicalExecutionIntent（interai-canonical-execution-intent/v2）、execution_intent_digest，并且仅在经过身份验证的 allow 情况下返回 ExecutionAuthorization（interai-execution-authorization/v1）。宿主机必须验证回执，在产生副作用前立即重建最终调用，重新计算规范摘要，验证授权，并在出现任何不匹配时采取失败关闭策略。工具、参数、权威主体、运行、工作区、环境、资源／目标或相关策略发生变化，都会使先前的 allow 失效，必须重新作出决策。review_required 和 block 均不构成授权。

执行授权为单次使用且有效期短：1–300 秒，默认 60 秒。InterAI 不会在外部运行时之间提供通用的分布式重放防护；在需要此保证时，宿主机必须以原子方式持久地使用该授权。

如果审查改变了操作，它就是一个新的待议操作。在 Pydantic AI 中：proposal → review/override → final validation → InterAI → exact-intent check → execute；在最终验证和 InterAI 处理前应用 ToolApproved.override_args。

当前托管测试版还会返回 score、risk_level 和机器可读的 signals。这些字段仍属于当前兼容性接口的一部分，对诊断和现有集成很有用，但不应将其解读为根本性的授权契约。执行边界是依据有效策略作出的最终 allow / review_required / block 决策。

策略权威边界

托管式身份验证自主执行会按严格的权威顺序组合策略：

HOST -> ACCOUNT -> CALLER -> EFFECTIVE

• 宿主机策略 是由 InterAI 控制、不可削弱的底线。
• 账户策略 是存储在操作请求之外的版本化配置文件，只有在持有者凭据解析到对应账户后才会附加。
• 调用方策略 可以添加请求范围内的限制，但不能削弱宿主机或账户的要求。
• 有效策略 是用于决策的更严格组合。

账户策略管理目前由 InterAI 管理的控制平面负责。这尚不属于客户自助式策略管理、委派式租户管理或企业策略管理产品。

无账户／x402 执行没有可解析的账户配置文件，因此仍采用 HOST -> CALLER -> EFFECTIVE。

外部证据

InterAI 可以接受外部系统生成的可验证声明，而无需将执行权限转交给这些系统。

外部证据。内部授权。

提供方提出声明。InterAI 决定授权。

此边界是有意设定的：

external provider
      |
      | signed / verifiable assertion
      v
   InterAI
parse -> verify -> bind -> record

当前 Stage 2 证据经过验证、绑定并记录为非权威性外部证据。它不会改变 InterAI 的执行决策或当前兼容性风险信号。

提供方的判定仍然是声明，而不是 InterAI 的执行指令。上游的 PASS、CAUTION 或 BLOCK 不会直接转化为 InterAI 内部的 ALLOW、REVIEW_REQUIRED 或 BLOCK。

这种区分很重要，因为证据和授权是不同的职责。专业系统可能掌握有关现实世界的宝贵信息，但这并不意味着它就成为决定是否授权执行自主操作的系统。

当前外部证据边界有意保持狭窄且不具权威性。实时引用解析或未来任何具有授权效力的模式，都将是单独的信任边界决策，而非当前契约的隐式扩展。

请参阅 docs/external-evidence.md 和 docs/architecture.md。

Insight ↔ InterAI

已验证的互操作性

Insight 和 InterAI 分别独立实现了互操作性，并针对冻结的 external-evidence/v0 rev6 合约进行了交叉验证。结果表明，特定领域的提供方可以生成签名证据，由 InterAI 独立验证、绑定并记录为非权威外部证据，同时保持提供方声明与 InterAI 执行权限之间的界限。

这是通过独立实现取得的技术互操作性成果，并不意味着 Insight 与 InterAI 之间存在生产合作关系或实时生产依赖。

示例

{
  "use_case": "agent-before-payment",
  "action": {
    "type": "payment",
    "name": "release_vendor_payment",
    "description": "Release payment to a vendor agent after delivery validation",
    "amount_usd": 125,
    "currency": "USD",
    "irreversible": false,
    "external_side_effect": true
  },
  "context": {
    "agent_id": "agent_123",
    "environment": "production",
    "counterparty_id": "vendor_agent_456",
    "user_confirmation": false
  },
  "policy": {
    "require_trust_receipt": true,
    "amount_usd_limit": 500
  }
}

可能的权限判定结果：

{
  "request_contract": "autonomous_execution",
  "recommended_action": "allow",
  "policy_result": "allow",
  "execution_intent_digest": "sha256-hex-digest",
  "trust_receipt_id": "tr_01JZPUBLICEXAMPLE"
}

托管版 Beta 目前还包含 score 和 risk_level 等兼容性字段；为清晰展示执行权限边界，上文省略了这些字段。

随后，调用系统会决定如何遵循该权限判定：

ALLOW             -> verify receipt + exact intent + authorization, then execute
REVIEW_REQUIRED   -> route / pause / escalate
BLOCK             -> abort

InterAI 不会执行该操作。周边执行层必须根据判定结果进行路由，并强制执行最终的精确意图比对。

试用托管版 Beta

Action Boundary Lab — 更改拟议操作，并检查真实的执行前决策边界：

https://api.interailabs.dev/lab

受控安全演示 — 使用真实信任收据进行一次有限的只读沙箱验证：

https://api.interailabs.dev/demo

托管版验证：

curl -sS -X POST https://api.interailabs.dev/verify \
  -H "Authorization: Bearer <interai_credential>" \
  -H "Content-Type: application/json" \
  -H "X-Idempotency-Key: vendor-payment-001" \
  -d '{
    "use_case":"agent-before-payment",
    "action":{"type":"payment","name":"release_vendor_payment","amount_usd":125,"currency":"USD","irreversible":false,"external_side_effect":true},
    "context":{"environment":"production","counterparty_id":"vendor_agent_456","user_confirmation":false},
    "policy":{"require_trust_receipt":true,"amount_usd_limit":500}
  }'

信任收据

每项重要决策都可以生成持久的信任收据。收据旨在让执行前决策可供检查，并能在重试、移交、治理系统和后续审计中传递。

经过身份验证的自主 DecisionReceipts 会绑定策略来源和 execution_intent_digest。ExecutionReceipt 是有关调度或结果的独立主机／运行时证据。DecisionReceipt 是决策证据，不是持有者令牌，也不能证明副作用已经发生。

当前收据签名使用 HMAC-SHA256，且由 InterAI 服务端验证。这能提供经过身份验证的服务端完整性，但不等同于可由第三方离线验证、无需 InterAI 参与的独立公钥签名保障。

收据仅能证明签名收据载荷在该时间点所验证的内容。它不能证明底层声明普遍属实，也不能替代特定领域的控制措施或必要的人工审核。

请参阅 docs/trust-receipts.md。

开源工具

公共仓库在 toolkit/ 下提供了一些小型、与框架无关的工具。这些工具单独采用 Apache-2.0 许可，并有意与专有的 Risk Oracle 决策引擎分开：

• Agent Action Gate — 在提供方状态不确定时默认拒绝，仅执行明确无误的 allow。
• Exact Action Binding — 针对与 JSON 兼容的拟议操作，在主机端确定性地检测修改。
• Decision Receipts — 使用所有者身份验证的签名证据，断言精确的执行意图摘要，并使用 InterAI 的服务验证端点，而不重新序列化不透明的签名载荷。

无需安装软件包，即可运行独立的公共合约：

node --test toolkit/*/*.test.mjs

这些工具仅公开集成／强制执行逻辑。生产验证、评分、原生决策策略、计费／存储、签名内部机制、信任情报和运营系统仍为私有。请参阅公共工具边界。

InterAI 采用中心辐射式模型：本仓库仍是 Risk Oracle 产品／合约／SDK 中心，而精选的稳定工具也可能拥有专门的独立仓库，以便于发现和贡献，同时避免复制私有核心逻辑。

集成接口

InterAI 可通过托管服务提供，并可通过多个公共接口发现或调用：

• HTTPS API 和 OpenAPI 3.1
• 在 npm 上发布的 TypeScript SDK：[email protected]（beta dist-tag）
• 在 PyPI 上发布的 Python SDK：interai-risk-oracle==0.1.7b0
• MCP 远程服务
• A2A 端点
• .well-known 发现元数据
• x402 / Base USDC 支付路径
• 预付费 API 密钥路径

SDK 软件包版本独立于托管运行时版本。托管服务及其发现清单会保持在当前运行时版本，直到另行发布新的运行时版本。

安装已发布的 SDK：

npm install [email protected]
pip install interai-risk-oracle==0.1.7b0

推荐的入门资源：

• 开源工具
• 架构与权限边界
• 外部证据边界
• 框架集成示例
• OpenAI Agents SDK 示例
• Mastra 示例
• Google ADK 示例
• 集成模式
• 测试者准备情况
• TypeScript SDK
• Python SDK
• TypeScript 中间件示例
• Python 中间件示例
• 支付前的 Agent
• x402 支付前的 InterAI
• 工具执行前的 Agent

当前产品范围

InterAI 目前处于受控技术测试阶段。

现已具备：

• 自主操作验证
• 明确的 allow / review_required / block 决策
• 强制执行的 InterAI 主机策略下限
• 面向已认证账户的、按账户划分且有版本管理的权威策略
• 按请求限定的调用方策略，只能收紧更高权限的约束
• 非权威外部证据的摄取、验证、绑定与记录
• 带有主机／账户／调用方／生效策略来源信息、由服务验证的签名信任凭证
• 规范化的执行意图摘要和精确意图分派契约
• 公共凭证查询
• 幂等的付费验证；已认证决策标识中包含账户策略版本／摘要
• 托管的 OpenAPI、MCP、A2A 和机器可读发现信息
• 已发布的 TypeScript 和 Python SDK 软件包

目前尚未宣称具备：

• 客户自助服务或委托式租户策略管理
• 向外部证据提供方委派权限
• 对外部证据进行不受限制的实时引用解析
• 可独立验证的公钥凭证签名
• 跨外部运行时的分布式单次执行或并发重放防护
• 广泛支持高流量生产环境的能力
• 满足企业采购要求的能力
• 对事实真伪的普遍保证
• 替代医疗、法律、金融、安全关键或其他特定领域的审核

当前的就绪状态边界请参阅 docs/professional-readiness.md。

旧版兼容性

InterAI 仍支持早期的提示词／响应验证契约，以保持兼容性。产品的主要发展方向是 autonomous_execution 契约和执行前决策边界。

托管测试版还保留了当前实现及现有集成所用的评分／风险兼容字段。这些字段并非 InterAI 权限边界的长期概念定义。

仓库边界

此公开仓库包含集成材料：SDK 源码、架构、示例、OpenAPI/发现元数据、采用 Apache 许可证的开源工具，以及托管服务文档。

生产验证引擎、计费基础设施、信任逻辑、评分内部机制、本机决策实现、签名内部机制和托管服务实现仍为专有内容。

工程

我有意将 InterAI 的主张限定在较窄范围内。我并不打算把每一次 Agent 交互都说成安全问题；我正在构建明确的权限边界，以确保后续执行具有重大影响的操作之前，权限界限清晰。

我正在将 InterAI 作为更广泛工作的组成部分，涉及 Agent 基础设施、执行系统、信任边界和生产自动化。对于存在具体互操作性或执行控制问题需要解决的情况，我愿意开展有选择的技术合作和基础设施交流。

链接

• 托管版测试： https://api.interailabs.dev
• Action Boundary Lab： https://api.interailabs.dev/lab
• 受控安全演示： https://api.interailabs.dev/demo
• 定价： https://api.interailabs.dev/pricing
• 入门： https://api.interailabs.dev/onboard
• OpenAPI： https://api.interailabs.dev/.well-known/openapi.json
• MCP： https://api.interailabs.dev/mcp
• npm： https://www.npmjs.com/package/interai-risk-oracle
• PyPI： https://pypi.org/project/interai-risk-oracle/0.1.7b0/
• 支持 / 安全 / 合作： [email protected]

凭证隐私（2026 年 9 月）

不带凭证调用 GET /trust/receipts/{receiptId} 时，只会返回包含凭证 ID 和签发时间的 public_summary。它不是已签名的证据，也不是执行授权。要获取完整凭证、原始不透明的 verification.signed_payload、签名和授权信息，请提供属于该凭证账户的有效 Bearer 密钥。 无效密钥会返回 401；其他账户则会收到 404。不得缓存响应。

无账户的 x402/付款引用客户端必须保留原始验证返回的完整证据；公开查询无法恢复私有内容。演示链接也只显示公开引用。不要将 API 密钥放入凭证 URL。验证时请保持已签名载荷的字节内容不变。