Tenuo 智能体授权
用加密授权凭证限制智能体在单次任务中可调用的工具、参数范围和委派权限。
按维度查看评分与理由
最小权限有充分的静态证据：工具名、实参、持有者和 TTL 均受签名 warrant 约束，委派只能收窄，且在执行边界失败关闭。敏感操作可要求签名人工批准，但批准机制是可选项，所引用的完整批准文档未提供，因此 user_confirmation 扣分。数据流说明较清楚：本地验证无需联网，实验分享明确限定联网命令、固定脱敏字段并测试 HTTPS。密钥保管、仅分发公钥、短 TTL、信任根和审计建议较完整。依赖安全有锁定构建、提交哈希固定的多数 Actions、cargo audit、CodeQL/模糊/变异测试等证据，但仍有按标签引用的 Action、curl 管道安装及未展示全部依赖清单与审计结果，故非满分。外部效果在调用前拦截并可生成收据，但不是所有效果都要求人工确认。没有撤销已执行副作用或恢复业务状态的回滚机制，rollback 为 0。许可证、贡献者、既有工作和安全联系人提供了来源归属，但发布者身份未经企业注册验证，维护主体的法律身份仍不明确。
README、SECURITY、CI 与实验测试共同展示了跨 Rust、Python、TypeScript、MCP、Temporal、Docker 和多平台的广泛检查，以及明确的拒绝异常和用户输出；但本次未执行这些检查。自洽性存在明显版本冲突：README 宣称 v0.2 Production/Stable，示例和镜像使用 0.3.0，实验记录 0.2.5-beta.0，而 SECURITY 仅列 0.1.x 受支持，因此 self_consistency 显著扣分。依赖可用性由多版本矩阵、预构建轮子、锁定构建和兼容性任务充分覆盖。失败消息有 AuthorizationDenied、MonotonicityError、缺失/无效 warrant 的说明以及实验 CLI 期望，但未提供整个产品错误分类与恢复指导，所以未满分。
材料清楚区分应用开发者、平台团队、代理编排器和学习者等受众，并覆盖进程内、MCP、API/网关、Kubernetes、Temporal 与代理交接场景。能力边界明确说明其不是沙箱、提示工程、LLM 过滤器或 IAM 替代品，并列出应用方责任。触发点精确位于真实工具调用及实参的执行边界，缺失、过期、签名错误或工具不符均拒绝。Python 3.9–3.14、Node 20+、Rust、Linux/macOS/Windows、容器和多框架集成均有静态配置及 CI 矩阵支持，足以给满分；但这不代表本次独立运行验证。
README 的安装、快速开始、委派模型、部署选择、需求、生产清单、Rust 示例、贡献与许可证结构完整，并提供大量可运行示例和教学实验。已明确记录非沙箱属性、路径规范化、nonce/幂等、节点覆盖、网络 TLS 和应用责任等限制。Apache-2.0 正文完整。命名总体稳定，但 Python、Rust、TypeScript、镜像和实验中的版本号及稳定性标签并不统一，因此 naming_stability 扣分。CHANGELOG 被引用但未提供，无法核验版本迁移质量，versioning_changelog 仅给部分分。安全邮箱、PGP、响应时限和贡献流程给出维护路径，但发布者身份未知，且没有明确的可核验法人或长期维护承诺，因此 maintenance_responsibility 非满分。
API 示例、边界部署方案、拒绝行为、实验 HUD、脱敏分享报告和多语言 SDK 使输出具有很高的实际可用性。相较身份或角色授权，该项目提供任务级、持有者绑定、可衰减的多跳授权和本地验证，边际价值明确。成本收益方面，材料声称低于 50 微秒并强调离线验证，但没有提供本次范围内的基准方法或结果，也未量化密钥管理、控制平面、全节点包装和集成维护成本，因此扣一分。
主要安全主张能够追溯到 README 示例、SECURITY 中的责任和测试命令、CI 工作流、实验的脱敏与网络行为测试以及所引用的形式化验证文件；但若干关键引用文件、测试实现、CHANGELOG、基准和执行结果未包含在材料中，claim_traceability 非满分。跨来源印证较强：文档中的最小权限、失败关闭、平台覆盖及数据分享描述分别被 CI 或测试代码呼应。事实与推断多数通过“不是沙箱”和应用责任作了区分，但“抵御提示注入”、生产稳定性、低于 50 微秒及“形式化验证”等表述在所给材料中缺少完整证明或结果，仍带有宣传性推断。
- 本次仅为静态低置信度审查；未执行构建、测试、模糊测试、形式化模型或基准。
- 生产使用前应核对 v0.1、v0.2、v0.2.5-beta.0 与 v0.3.0 之间的真实支持状态、兼容性和升级路径。
- Tenuo 只授权调用，不提供进程隔离或业务副作用回滚；仍需沙箱、TLS、幂等控制及应用级补偿机制。
- 确认所有工具和图节点都经过 guard，正确规范化路径，并配置显式信任根、撤销策略、短 TTL、审计与安全密钥存储。
- 对低于 50 微秒、生产稳定和形式化验证等声明，应在固定修订上检查原始模型、测试结果和可复现基准。
这个 Agent 能做什么，适合哪些场景？
Tenuo 是面向 AI 智能体和工作流的任务级授权系统，由 Rust 核心、Python SDK、测试版 TypeScript SDK、验证 sidecar、控制平面示例及多种框架适配器组成。控制平面或应用签发带有工具名、参数约束、持有者公钥和有效期的 warrant，智能体调用工具时提交 warrant 与持有密钥生成的持有证明。执行边界上的 Authorizer、Python `@guard`、Rust `Guard`、MCP 中间件或 API 网关会在动作运行前验证完整委派链和实际参数。委派者只能删除能力、收紧参数范围或缩短有效期，不能把子 warrant 的权限扩大到父 warrant 之外。它可作为进程内库、MCP 服务保护层、FastAPI/网关 sidecar、Kubernetes 组件或 Temporal 工作流授权层部署，并能选择性地产生签名授权回执。适合需要让智能体自主选择工具、同时以密码学方式限定实际执行权限的团队；它不提供进程隔离，也不替代现有 IAM。
签发方通过 SigningKey、Capability 和 Warrant.mint_builder() 定义允许调用的工具、参数约束、持有者和 TTL。Python 应用可以用 configure()、mint()/mint_sync() 将 warrant 放入任务上下文，再用 @guard(tool="...") 在函数运行前检查调用；Rust SDK则通过 Runtime、session_from_warrant()、Call 和 session.guard()执行同类检查。跨进程的 MCP 部署使用 Authorizer、MCPVerifier、TenuoMiddleware 和 SecureMCPClient，客户端发送 warrant 及覆盖工具名、精确参数和短时间窗口的持有证明，服务器使用受信任签发方公钥在本地验证。编排器可调用 grant_builder() 生成更窄的子 warrant；若增加工具、放宽约束或提高上限，系统抛出 MonotonicityError。同一 warrant 格式还能用于 A2A、HTTP、FastAPI、Temporal、LangChain、LangGraph、CrewAI、AutoGen、Google ADK 和 OpenAI 集成。验证结果允许或拒绝动作；需要审计时还可生成签名授权回执。
- 平台工程团队允许运维智能体扩缩
staging-*集群，但需要禁止其触碰生产集群或把副本数提高到指定上限以上。 - 多智能体系统的编排器需要把子任务交给工作智能体，同时保证每次交接后的权限只能缩小，不能发生权限升级。
- MCP 工具提供方希望在服务器端验证工具名、真实参数和调用者的持有证明，而不是信任模型或客户端自己的判断。
- API 与基础设施团队希望在 FastAPI、网关、sidecar 或 Kubernetes 边界统一执行智能体授权，并在控制平面不可用时继续本地验证。
- 使用 Temporal 的团队需要让授权上下文跟随重试、队列和长时间运行的工作流。
- 受审计约束的团队需要为敏感操作加入签名人工批准，或保存说明调用为何获准或被拒的签名回执。
这个 Agent 有哪些优点和局限？
- 授权在真实工具边界基于工具名和精确参数执行，即使模型遭到提示注入，调用也不能超过 warrant 已授予的范围。
- 委派具有单调衰减约束：子 warrant 只能删除工具、收紧参数或缩短期限，验证端会检查从受信任根到叶节点的整条链。
- warrant 与持有者公钥绑定，每次调用还要提交签名持有证明，复制单纯的 warrant 不能直接冒用。
- 验证可在本地完成且不依赖网络；来源声称检查耗时低于 50 微秒，控制平面中断时仍可继续执行授权。
- 同一协议覆盖 Python、Rust、测试版 TypeScript、MCP、HTTP、A2A、Temporal、网关和多种智能体框架，部署边界选择较多。
- Tenuo 不是沙箱，只判断调用是否获准；需要进程或主机隔离时仍须部署容器或虚拟机。
- 生产采用需要管理签名密钥、受信任根、短 TTL、撤销策略、审计回调和每个执行边界的强制验证，运维复杂度高于只依赖现有 IAM。
- TypeScript SDK仍为 beta 且要求 Node.js 20+；部分生态接入依赖可选 Python 扩展，MCP、AutoGen 等扩展要求 Python 3.10+。
- 托管的 Tenuo Cloud 仍处于 Early Access，且 Cloud SDK/控制平面客户端被明确标为专有组件。
- warrant 退出应用上下文后仍会持续有效到 TTL 到期，因此错误配置的过长 TTL 会扩大凭证暴露窗口。
如何安装或部署这个 Agent？
Python 3.9-3.14 可运行 uv pip install tenuo，也可执行 pip install tenuo。按集成选择额外依赖，例如 uv pip install "tenuo[mcp]"、uv pip install "tenuo[fastmcp]"、uv pip install "tenuo[openai]" 或 uv pip install "tenuo[temporal]"；MCP 相关扩展要求 Python 3.10+。Node.js 20+ 可安装测试版 TypeScript SDK：npm i @tenuo/core@beta。Rust 项目运行 cargo add tenuo --features sdk；文档示例也给出了 tenuo = { version = "0.3.0", features = ["sdk"] }。容器演示可在仓库中运行 docker compose up，官方镜像可用 docker pull tenuo/authorizer:0.3.0 和 docker pull tenuo/control:0.3.0。Kubernetes 可执行 helm install tenuo-authorizer ./charts/tenuo-authorizer --set config.trustedRoots[0]="YOUR_CONTROL_PLANE_PUBLIC_KEY"。
如何使用这个 Agent？
最小 Python 流程是生成 SigningKey，调用 configure(issuer_key=..., dev_mode=True, audit_log=False)，用 Capability("scale_cluster", cluster=Pattern("staging-*"), replicas=Range.max_value(10)) 描述权限，再在 with mint_sync(authority): 中调用受 @guard(tool="scale_cluster") 保护的函数。dev_mode=True 仅适合本地粘贴运行；生产环境应把签名密钥放入 Vault、AWS Secrets Manager 或 GCP Secret Manager，向验证端配置控制平面的公开 trusted_roots，关闭 dry_run，要求每个执行点都提供 warrant，并启用审计回调和指标。MCP 服务端只接收签发方公钥，将 Authorizer(trusted_roots=[issuer_public_key]) 交给 MCPVerifier(require_warrant=True) 和 TenuoMiddleware；客户端使用 SecureMCPClient(..., inject_warrant=True) 调用工具。生产 warrant 应采用短 TTL；退出 mint_sync 上下文只会移除当前作用域中的 warrant，不会提前撤销其密码学有效期。
这个 Agent 与同类方案有什么区别？
与传统 IAM 相比，Tenuo 不主要回答调用者是谁，而是限定某个工作负载在当前任务和时间窗口内具体能做什么；它被设计为叠加在 IAM 之上。与普通 bearer token 相比，warrant 绑定持有者公钥并要求每次调用提供签名证明。与依赖中心策略服务的运行时检查相比，它把签名权限携带在请求中，可在执行端离线验证。项目将 Macaroons、Biscuit、UCAN 和 CaMeL 列为相关或启发性工作，但来源没有给出足以断言全面优劣的基准比较。