Gumloop 功能规格 - Team Level Secrets

初始上下文

1. 概览

背景 — 凭据体系三次演进

Gumloop 的凭据体系经历了三个阶段的演进：Phase 1 仅支持 Personal Apps（每个用户独立配置 OAuth/API Key）；Phase 2 (v7.2.0) 引入 Team Apps（共享 OAuth 连接，如 marketing@company.com 的 Gmail 账户），但仅限预定义的服务连接；Phase 3 (v9.10.0) Team Level Secrets 填补最后一块空白——团队管理员现在可存储任意变量和密钥（不限于预定义 OAuth 服务），且这些凭据自动对团队所有成员可用。

核心痛点

目标

1. 集中化共享：团队凭据存储在一个位置，管理员一次配置，全团队自动可用

1. 自动分发：团队成员无需手动配置即可在 Agent 和 Workflow 中使用团队凭据

1. 单点轮换：凭据更新一次，所有引用该凭据的 Agent/Workflow 立即生效

1. 最小权限：管理员控制哪些成员/角色可以查看和使用团队凭据

1. 审计可见性：记录凭据的创建、修改、使用和轮换事件

2. 核心机制详解

2.1 团队作用域绑定

Team Level Secrets 的核心设计是作用域绑定 (Scope Binding)——凭据与特定团队绑定，仅在团队范围内可用：

凭据存储层级:
┌──────────────────────────────────────────────────┐
│ Organization (组织)                                │
│  ├── Team A                                        │
│  │   ├── Secret: OPENAI_API_KEY   仅 Team A 可访问  │
│  │   ├── Secret: GITHUB_TOKEN     仅 Team A 可访问  │
│  │   └── Variable: DEFAULT_MODEL  仅 Team A 可访问  │
│  ├── Team B                                        │
│  │   ├── Secret: AWS_ACCESS_KEY   仅 Team B 可访问  │
│  │   └── Secret: DATABASE_URL     仅 Team B 可访问  │
│  └── Personal                                      │
│      ├── Secret: MY_OPENAI_KEY (User 1) 仅 U1 可访问│
│      └── Secret: MY_OPENAI_KEY (User 2) 仅 U2 可访问│
└──────────────────────────────────────────────────┘

• 团队凭据与特定团队绑定，跨团队不可见

• Personal Secrets 与 Team Secrets 共存——当同一服务存在两种凭据时，使用优先级由节点配置决定

• 组织级凭据（跨多团队）可能作为未来能力

2.2 凭据注入机制

团队凭据在 Agent 运行时和 Workflow 执行时被安全注入：

┌──────────────┐     ┌──────────────────┐     ┌─────────────────┐
│ Team Secrets │────>│ 凭据解析器         │────>│ Agent / Workflow │
│ Store        │     │ (Credential       │     │ Runtime          │
│              │     │  Resolver)        │     │                  │
│ OPENAI_KEY   │     │                   │     │ $TEAM_OPENAI_KEY │
│ GITHUB_TOKEN │     │ 作用域检查 →      │     │ 在代码节点中可用  │
└──────────────┘     │ 解密 → 注入       │     └─────────────────┘
                     └──────────────────┘

推断的注入方式：(1) 代码节点变量注入——通过模板语法引用（如 ${{team.secrets.OPENAI_API_KEY}}）或环境变量；(2) Agent 凭据选择器——团队凭据作为第三选项出现在下拉菜单中（继 Personal Default、Team App 之后）；(3) Workflow 节点注入——在需要凭据的节点下拉菜单中出现。

2.3 权限模型

关键设计决策：(1) 查看凭据值与使用凭据权限分离——Team Member 可使用但不看到原始值 (2) 凭据值在注入时解密，Agent 日志中自动遮蔽 (3) Security 角色有只读审计权但不能修改。

2.4 与现有体系的集成点

3. 功能需求

模块一：凭据创建与存储

模块二：团队绑定

模块三：成员访问

模块四：管理员轮换

模块五：审计可见性

模块六：代码节点集成

4. 用户场景与故事

5. 竞品分析

核心差异：AI Agent 原生

1. 凭据消费者是 Agent 而非 CI Runner：凭据在 Agent 执行上下文中注入，使用是动态的、由 Agent 决策驱动的，而非静态流水线脚本

1. 与 Agent 权限模型深度集成：团队凭据的可用性与 Agent 的分享权限、App Policies、Composable Roles 联动

1. 凭据遮蔽在 Agent 日志中：Agent 对话记录和工具调用日志需自动检测并遮蔽凭据值——传统 Secret Manager 不需要面对此问题（Agent 可能将凭据写入对话上下文，而对话上下文可能被子 Agent 共享）

1. 零摩擦 UX：非技术用户在凭据选择器中选择"团队凭据"即可，无需理解凭据管理

6. 遥测

7. 路线图与未来演进方向

关键演进判断

1. 轮换提醒是下一步的关键能力：当前版本解决了"一次更新，全员生效"，但轮换触发依赖管理员记忆。基于轮换周期的自动通知将凭据管理从"被动响应"升级为"主动防护"。

1. 审计日志是 SOC 2 合规的硬性要求：企业安全评估中，"谁在什么时候用凭据做了什么"是必问问题，凭据使用审计日志是回答这一问题的关键基础设施。

1. 条件访问控制是差异化机会：Agent 场景下，基于条件的访问控制（如 IP 段限制、工作时间限制）比传统二态开关（开/关）更具价值——Agent 可能在任何时间被触发。

1. 外部 Vault 集成减少企业采购阻力：大型企业已有 Vault/Secrets Manager 投入。Gumloop 作为消费端（而非替代者）将减少"又一个 Secret Store"的采购阻力。

1. 凭据健康检查建立信任：检测弱密钥、重复凭据、过期凭据——这类主动安全能力在 Agent 平台中尚未普及，可作为 Gumloop 差异化点。

由 Claude spec-generate 系统生成 · 来源：Gumloop Credentials 帮助文档 + Gumloop Changelog v9.10.0 · 部分机制基于现有文档的合理推断