Speedle AI · 两个方向,一套策略

用 AI 管权限,用策略约束 AI

用 AI 设计、管理和检查访问策略,也让同一套策略约束 AI 自身,覆盖 MCP 授权、RAG 权限控制和智能体最小权限。两个方向都离不开清晰、可执行的策略决策。

基于开源 Speedle 策略引擎构建。

用 AI 管权限

用 AI 管好访问策略

AI 帮人管理访问:开源技能把制度文档变成 SPDL;Speedle MCP 用于设计、管理和检查策略(预览);AI 风险检测方案已列入计划。

Speedle 策略建模技能 · 开源 Agent Skill可用

把制度文档变成可复核的 SPDL

这个 Agent Skill 适用于所有兼容 Agent Skills 格式的 Agent。它读取员工手册或制度文件,先问清文档没有写明的部分,再生成 RBAC + ABAC 策略,不会凭空猜规则。

产出5 个文件

从条款到可测试的策略

每条策略都标注它实现的条款,或用户确认过的回答。模型文档包含 Mermaid 角色继承图和每条策略的理由。

  • 可直接导入文件存储的 .spdl,并通过 spctl check。
  • 按部门、地点、数据级别和金额设置 ABAC 条件。
  • 覆盖允许、拒绝和审批边界的可执行用例。
打开技能目录
示例输出中英双语

一本合成手册,完整建模

两个示例都从虚构的员工手册出发,最后得到经过测试的模型。各自通过 spctl check,并在本地 PMS 和 ADS 上通过全部 37 条授权用例。

  • 角色继承和按部门限定的经理角色。
  • 明确拒绝覆盖宽泛的员工授予。
  • 用 entity 建模薪资服务账号。
阅读中文示例

技能包遵循 Agent Skills 格式:SKILL.md 包含 name 和 description frontmatter,另有参考文档、脚本和示例,可供任何兼容该格式的 Agent 使用。通用安装方式:把技能文件夹复制到 Agent 的技能目录,再让它读取员工手册并建模。下面分别以 Claude Code 和 Codex 为例。

前置条件

  • spctl — 用 spctl check -f policies.spdl 校验生成的 SPDL。
  • speedle-pms 和 speedle-ads — 在本地 Speedle 上运行端到端授权用例。
  • Python 3 — 运行 scripts/run-cases.py 中的测试用例。
安装与使用Claude Code · 示例
claude plugin marketplace add teramoby/ai.speedle.io
claude plugin install speedle@speedle

# 在 Claude Code 中:
/plugin configure speedle@speedle
/speedle:speedle-policy-modeler ./employee-handbook.md
安装与使用Codex · 示例
git clone --depth 1 https://github.com/teramoby/ai.speedle.io.git
mkdir -p ~/.agents/skills
cp -R ai.speedle.io/skills/speedle-policy-modeler \
  ~/.agents/skills/

# 在 Codex CLI 或 IDE 扩展中:
$speedle-policy-modeler ./employee-handbook.md

Speedle MCP预览

Speedle MCP:两种独立模式

@speedle/mcp 已在 npm 发布。它是一个 npm 包,附带 speedle-mcp 命令,用于在本地以 stdio 方式运行 MCP 服务器。

阅读 README
模式 01check

授权检查

check 模式默认只注册 is_allowed,只读取 ADS 配置。diagnose、all_granted_roles 和 all_granted_permissions 需要分别用 --expose-diagnose、--expose-all-granted-roles 和 --expose-all-granted-permissions 参数显式开启。diagnose 只支持自托管 Speedle,连接 Speedle Cloud 时带上它服务不会启动。它只回答授权问题,不会在调用应用中执行访问控制。

  • 通过 Speedle ADS REST API 发起只读授权检查。
  • 输入:主体、资源、操作和带类型的属性。
  • 从环境变量读取 ADS 基础 URL、服务名和可选的 bearer 令牌。
查看 check 模式配置
模式 02manage

策略设计与管理

manage 模式只注册管理工具,只读取 PMS 配置,通过 PMS REST API 设计和管理 Speedle 策略。

  • 管理服务、授权策略和角色策略。
  • 以 SPDL 展示生效策略;策略在创建时由 PMS 校验。
  • 支持只读选项;执行删除前必须明确确认目标。
查看 manage 模式配置

需要 Node.js 22 或更高版本。这些示例与已发布的包 README 一致。上面的 Claude Code 插件固定使用 @speedle/mcp@0.2.1 版本。

安装npm · npx
npm install @speedle/mcp

npx @speedle/mcp check
npx @speedle/mcp manage
check 模式自托管
{
  "mcpServers": {
    "speedle-check": {
      "command": "npx",
      "args": ["-y", "@speedle/mcp", "check"],
      "env": {
        "SPEEDLE_ENDPOINT": "http://127.0.0.1:6734",
        "SPEEDLE_SERVICE_NAME": "books"
      }
    }
  }
}
check 模式 · 可选工具自托管
{
  "mcpServers": {
    "speedle-check": {
      "command": "npx",
      "args": [
        "-y",
        "@speedle/mcp",
        "check",
        "--expose-diagnose",
        "--expose-all-granted-roles",
        "--expose-all-granted-permissions"
      ],
      "env": {
        "SPEEDLE_ENDPOINT": "http://127.0.0.1:6734",
        "SPEEDLE_SERVICE_NAME": "books"
      }
    }
  }
}
manage 模式自托管
{
  "mcpServers": {
    "speedle-manage": {
      "command": "npx",
      "args": ["-y", "@speedle/mcp", "manage"],
      "env": {
        "SPEEDLE_PMS_ENDPOINT": "http://127.0.0.1:6733"
      }
    }
  }
}

AI 风险检测

计划中

AI 能从更多维度和关系中发现单条规则看不到的风险。这是 Speedle 正在探索和构建的方向,尚未发布。策略保留否决权:风险信号可以加强审查或防护,但绝不能把拒绝改成允许。

查看目标流程

用策略约束 AI

AI 构建与运行,权限全程可控

从模型上线前的构建阶段,到模型服务与执行操作的运行阶段,Speedle 策略引擎都能管理 AI 系统对数据、模型、工具和其他智能体的访问。这里介绍的是解决方案模式,不是任何机器学习或智能体平台的已发布集成。

概念

AI 构建与运行,共用一个决策点

每个区域都在应用里设有策略执行点:操作前先问 Speedle,再按结果放行或拒绝。

概念:AI 构建与运行共用 Speedle 策略决策点 顶部是身份区:你的 IdP 和 OAuth 负责认证用户与智能体,MCP 授权基于 OAuth,主体信息再传给 Speedle。左侧构建区包括数据与训练、模型发布:前者的请求来自数据加载器和任务调度器,后者来自模型注册表和发布流水线。右侧运行区包括推理与 RAG、智能体代用户操作、MCP 工具调用和智能体间调用:检索器逐文档检查,API 网关发起请求;智能体运行时先查智能体的令牌范围,再查委托用户;MCP 宿主或网关检查工具调用;调用方或接收方智能体检查 A2A 调用。各区域的策略执行点都向中央的 Speedle 策略决策点请求允许或拒绝。底部的审计与解释区记录决策和原因:诊断 API 说明匹配了哪条策略、为什么匹配,应用同时记录智能体和委托用户。 身份输入 贯穿全流程 你的 IdP 和 OAuth 认证用户与智能体,MCP 授权基于 OAuth。 应用将身份作为主体传入,Speedle 根据这些主体决策。 主体 构建 模型上线前 运行 AI 服务并执行操作时 01 数据与训练 数据加载器、任务调度器 数据集、训练任务、 检查点导出 02 模型发布 模型注册表、发布流水线 注册、审批、晋升、 回滚 03 推理与 RAG 检索器逐文档请求 · 网关 04 智能体代用户操作 智能体运行时 · 用户 + 智能体 05 工具调用(MCP) MCP 宿主或网关,逐次请求 06 智能体间调用(A2A) 调用方或接收方智能体 SPEEDLE 策略 决策点 针对每个区域的请求 评估 SPDL 策略 允许 | 拒绝 决策及原因 审计与解释输出 贯穿全流程 Speedle 诊断 API 说明每项决策:匹配了哪条策略,为什么。 应用记录决策、智能体和发起委托的用户。 概念:AI 构建与运行共用 Speedle 策略决策点 内容自上而下排列。身份输入:你的 IdP 和 OAuth 负责认证用户与智能体,MCP 授权基于 OAuth,Speedle 根据收到的主体作出决策。Speedle 策略决策点评估 SPDL 策略,返回允许或拒绝,每个区域的策略执行点都向其发起请求。构建区:数据与训练的请求来自数据加载器和任务调度器,模型发布的请求来自模型注册表和发布流水线。运行区:推理与 RAG 由检索器逐文档检查,API 网关发起请求;智能体运行时先查智能体的令牌范围,再查委托用户;MCP 宿主或网关逐次检查工具调用;调用方或接收方智能体检查 A2A 调用。审计与解释输出:诊断 API 说明匹配了哪条策略、为什么匹配,应用记录每项决策、相关智能体和委托用户。 身份输入 贯穿全流程 你的 IdP 和 OAuth 负责 用户与智能体认证。 MCP 授权基于 OAuth。 Speedle 根据收到的主体 作出决策。 主体 SPEEDLE 策略决策点 评估 SPDL 策略 允许 | 拒绝 构建 模型上线前 运行 AI 服务并执行操作时 01 数据与训练 数据加载器、任务调度器 02 模型发布 模型注册表、发布流水线 03 推理与 RAG 检索器逐文档请求 · 网关 04 智能体代用户操作 智能体运行时 · 用户 + 智能体 05 工具调用(MCP) MCP 宿主或网关,逐次请求 06 智能体间调用(A2A) 调用方或接收方智能体 审计与解释输出 诊断 API 说清每项决策 匹配了哪条策略、为什么。 应用记录每项决策,同时记下 执行操作的智能体和 发起委托的用户。
策略执行点向 Speedle 提供主体、操作、资源和属性,请求授权。 Speedle 返回允许或拒绝,应用据此放行或拦截。

解决方案模式

每个区域一条策略模式

每个区域一句话、一条代表性规则。完整 SPDL 示例和每次检查需要的属性,都在模式页面。

构建 · 01 数据与训练

数据与训练

训练任务读取数据集并写入检查点;同意状态和区域逐数据集检查,受限数据不会进入训练。

grant role training-pipeline read expr:^/datasets/ if consent == true && data_region == job_region

构建 · 02 模型发布

模型发布

模型注册、审批、晋升和回滚是分开的操作,训练模型的人不能审批同一个模型。

deny role release-manager approve expr:^/models/ if trained_by == request_user

运行 · 03 推理与 RAG

推理与 RAG

检索器在文档内容进入提示词前逐篇请求授权,模型只看到用户有权阅读的内容。

grant role tenant-user retrieve expr:^/collections/ if doc_tenant == user_tenant && doc_label in user_clearances

运行 · 04 智能体代用户操作

智能体代用户操作

先检查智能体是否在委托令牌的范围内,再检查委托用户此刻本人的权限。

grant entity triage-agent in-time if request_time < token_expires

运行 · 05 工具调用(MCP)

MCP 工具调用

每次工具调用都在执行前检查,参数作为属性,交给策略限制。

grant role billing-agent call /tools/issue-refund if amount <= 100 && customer_verified == true

运行 · 06 智能体间调用(A2A)

智能体间调用

委托链每一跳都要检查,接收方只能拿到调用方已有的权限范围。

grant role planner-agent call /agents/researcher if IsSubSet(requested_scopes, caller_scopes) && hops <= 2

运行 · 07 零常驻权限 · 自托管

零常驻权限

签发和管控到位时,即时签发、短期有效的令牌可以支撑零常驻权限模式。在 Speedle 里,你可以把零常驻权限策略写成 SPDL 策略,并在每次请求时强制执行:权限只在你设定的时间窗口和条件内存在。

grant role agent-runtime invoke /api/orders if expires_at > issued_at && expires_at - issued_at <= 600 && issued_at <= request_time + 60 && not_before <= request_time + 60 && request_time < expires_at && TokenUnused(token_id)

查看完整模式与 SPDL 示例

贯穿全流程

每个区域共有的四件事

身份、审计、风险映射和能力边界贯穿构建和运行的每个区域。

身份集成

Speedle 管授权,IdP 管认证

Speedle 是授权决策点,用户和智能体则由你的 IdP 或 OAuth 授权服务器认证,MCP 授权基于 OAuth。应用先把验证过的身份映射为主体(用户、用户组、实体),再向 Speedle 请求决策。

审计与可解释性

诊断与审计日志

Speedle 的诊断 API 返回决策、原因、生效角色和检查过的策略,说清匹配了哪条策略、为什么。应用记录每项决策、相关智能体和发起委托的用户。诊断接口会暴露策略和请求详情,只向可信运维人员开放。

风险映射

对应 OWASP LLM06:2025 过度代理

OWASP 2025 年大模型应用十大风险提到的过度代理,是指智能体的功能、权限或自主性超出任务需要。按智能体划分角色、按工具检查、让委托绑定任务和时限,再对高风险操作做人工审批,可以分别收敛这三类风险。

边界

Speedle 的能力边界

Speedle 不检测提示词注入,不过滤模型输入或输出,也不验证模型和数据集供应链,这些需要专门的控制措施。它能限制遭攻陷或受误导的智能体做什么:无论提示词怎么写,只要请求不符合策略,Speedle 就拒绝。

Speedle 生态

从 Speedle 基础组件入手

Python SDK · 发起决策请求0.2.0
from speedle import Auth, Client

with Client(backend="speedle", endpoint="http://localhost:6734",
            auth=Auth.none(), service_name="docs") as speedle:
    allowed = speedle.is_allowed("alice", "get", "/docs/public")
    # docs 服务授予 alice get /docs/public 后为 True

一个简短示例;SDK 文档介绍各语言的客户端、请求模型和错误处理。Node.js 客户端已在 npm 发布:npm install @speedle/sdk。

开源 · 共同探索

分享真实 AI 授权场景

一起完善后续示例:说说你的应用需要保护哪些数据集、模型、工具或智能体工作流。

Speedle 源自 Oracle Speedle,由原开发者继续维护,并采用 Universal Permissive License(UPL)1.0 授权。了解项目历程。