AI 资源库 · 已整理 2 项

身份提供商

查看与身份提供商相关的 AI 资讯、工具、Skill、工作流和开源项目。

Agent 与工作流

为 Harness MCP 引入自有身份提供商｜OAuth 代理模式

Harness 为自托管的 MCP 服务器新增了 OAuth 代理模式。以前企业自建 MCP 服务器时，只能把 Harness 的个人访问令牌（PAT）或服务账号令牌放在服务器或开发者电脑上，这种令牌长期有效、容易被复制和共享，泄露后照样能用，审计日志也分不清是谁在操作。新模式下，MCP 服务器充当中间人：开发者先用公司自己的身份提供商登录，服务器再在后台换成短期有效的 HarnessID 令牌并加密保存，开发者机器上不再出现 Harness 凭证。这样，受到严格监管、只信任内部身份系统的企业也能把 Harness 接入自己的 AI 开发平台，同时每次操作都能对应到具体的人。该功能已随文章发布，具体开通条件和限制原文未说明。

文中可用工具

  • Harness MCP让编程智能体获得软件交付上下文（构建、测试、扫描、部署）的 MCP 服务器，可云端运行或自托管
  • HarnessIDHarness 的身份认证系统，负责签发短期访问令牌
  • Harness执行构建、测试、扫描和部署的软件交付平台
# 身份提供商# Harness MCP# OAuth 代理模式# MCP 服务器# 令牌安全
☆ 收藏查看来源 ↗
评论 · 分享第一个看法
Agent 与工作流

Agent 干了活，审计日志却说不出是谁下的指令

CloudBolt 的首席客户官 Shawn Petty 和售前工程总监 Mike Bombard 在一次网络研讨会上，分享了他们对客户和潜在客户环境的检查结果：超过 20% 与 MCP 相关的访问策略要么失效要么缺失，多数情况下 MCP 服务器跑在某个人的私人令牌上，而不是服务账号。这带来的麻烦是出事后审计日志查不清责任：私人令牌会把某个工程师的名字写进日志，共享服务账号则只留下账号名，两种都说不准到底是谁下的指令、谁批准了这次访问。他们演示的做法是把 Agent 的活动对接到企业已有的身份提供商，限制 Agent 能碰哪些资源，再读出可追溯的审计记录。对用 Agent 操作云基础设施的团队来说，这提供了一个把 Agent 行为追责到具体人的思路；该研讨会需注册后参加，具体产品能力原文未说明。

文中可用工具

  • CloudBolt把 Agent 活动对接到已有身份提供商、限制 Agent 可访问范围并输出审计记录的方案
# MCP# 审计日志# 身份提供商# 访问策略# CloudBolt
☆ 收藏查看来源 ↗
评论 · 分享第一个看法