身份与多租户

OceanWay 的身份模型必须同时支持个人创作、企业协作、开发者集成和自动化。核心原则是：自然人身份、企业成员关系、服务身份和凭据是不同对象，不能都压缩成一个 userId。

层级模型

Identity

全局登录主体，保存认证方式、MFA、状态和安全信息。一个自然人只应拥有一个独立 OceanWay 身份。

个人空间

独立用户注册后自动创建。它拥有个人钱包、默认 Workspace、个人项目和个人资产，对企业管理员不可见。

企业组织

企业的合同、数据所有权、成员、安全策略和计费边界。用户通过 Membership 加入，不复制出一套“企业用户”。

Workspace

品牌、客户、部门或长期业务单元。企业资产默认归 Workspace；Workspace 是日常协作和资源授权的核心边界。

Project

一次明确的跨产品业务目标。共享 Project 只保存通用外壳、上下文和关联；漫剧、商品、Canvas 和 Developer App 仍由各自领域对象承载。

例如“秋季新品发布”是一个共享 Project，它可以关联一个 Commerce Campaign、多个 CanvasDocument、一个素材集合和若干 Agent Run，而不是要求这些产品使用同一张项目 JSON。

主体类型

DeveloperCredential 不是用户，Agent Definition 也不是运行权限主体。DeveloperCredential 只证明“哪个 Service Account 在请求”，真正权限仍需服务端根据完整资源链和当前上下文计算。

Playground Execution Grant 同样不是 Principal：它将一个已认证 Customer User 的受限执行意图委托给目标 Service Account，不创建独立 Playground Principal。DeveloperCredential 与 Playground Grant 只在 api.oceanway.tech/v1 的 Public API Edge 解析；Customer Session 只由 console.oceanway.tech/ai 等产品 BFF 接受。Text/Media 私有网关只接收短期 Workload Credential 和最小 traceId/attemptId 上下文，不接收用户 Session、Membership、客户组、DeveloperCredential 或 Playground Grant。

企业成员，而不是复制账号

产品文案优先使用“企业成员”，不要用含义模糊的“子账号”。普通企业协作流程是：

1. 用户以自己的 OceanWay 账户接受邀请。
2. 系统建立该 Identity 与 Organization 的 Membership。
3. 组织为 Membership 分配角色、Workspace 和 Project 范围。
4. 用户保留个人空间，也可以加入其他企业。
5. 企业只能管理该用户在本组织中的关系，不能接管个人空间。

接受邀请不会自动发生以下行为：

• 合并个人与企业钱包；
• 把个人资产迁入企业；
• 把个人 MCP Connection 共享给企业；
• 允许企业管理员查看个人项目；
• 让企业余额不足时改扣个人余额。

个人资产进入企业项目时，必须通过“复制到企业”“提交到企业资产库”或明确授权完成，并记录来源、版权与责任主体。

企业受管身份

大型企业可能要求严格意义上的“企业子账号”。这类需求通过 Managed Identity 实现，而不是共享账号：

• 由企业 SSO、SCIM 或管理员创建和停用；
• 登录、MFA、恢复策略受企业控制；
• 可限制加入外部组织；
• 默认不创建个人空间；
• 每个员工仍有独立 Principal，禁止多人共用账号和密码。

Independent Identity 与 Managed Identity 不自动合并或相互转换。释放、合并或身份接管必须经过明确验证、企业批准和审计。Managed Identity、SSO 与 SCIM 建议作为企业版后续阶段，不阻塞首期邀请制 Membership。

Membership 与邀请

Membership 至少包含：

organizationId
principalId
membershipType: owner | member | guest
controlType: independent | managed
source: invite | domain | sso | scim
status: invited | active | suspended | revoked
joinedAt

邀请应固定受邀邮箱、组织、角色、可访问 Workspace/Project、有效期和邀请人。接受前明确展示：

• 邀请人和企业名称；
• 初始角色与可访问范围；
• 企业资产归属规则；
• 是否允许使用组织钱包；
• 企业安全与数据外发政策。

登录邮箱与邀请邮箱不一致时必须提示切换或由管理员重新邀请，禁止静默绑定。

资源归属

任何共享资源至少区分四个关系：

不变量：

• 企业 Workspace 中上传、生成和导入的资产归企业。
• 个人空间资产归个人 Workspace。
• 资源只能有一个直接所属 Workspace。
• 跨 Workspace 使用通过授权引用、复制或派生完成。
• API、Canvas、Agent 与 MCP 输出在执行前必须确定目标 Workspace。
• 删除 Project 不能直接删除仍被其他 Project 引用的共享资产。

因此员工离职时通常不需要转移资产所有权；企业本来就是所有者，只需重新指定业务负责人。

当前上下文

每次业务请求都必须解析以下上下文：

actorPrincipalId
executionPrincipalId
organizationId
workspaceId
projectId（可选）
billingAccountId
authenticationType / authenticationRef
callerWorkloadPrincipalId?（仅服务跳转审计）

浏览器业务请求中，Actor 与执行主体通常都是 Customer User；正式 API 中二者都是 Service Account；Playground 中 Actor 是 Customer User，执行主体是 Service Account。Customer Session、DeveloperCredential、Playground Execution Grant 或 Workload Credential 按入口择一作为认证材料。内部服务的 Workload Principal 只表示当前 Hop 的调用方，不得覆盖原业务 Actor。

前端的组织切换只是用户体验，真正隔离必须在服务端 Repository、对象存储签名、搜索、任务和账本中执行。Session 不应长期固化完整角色快照，关键操作需要读取最新 Membership 与策略。

所有写 API 应显式携带或由当前入口允许的 Customer Session、DeveloperCredential、Playground Execution Grant 或 Workload Credential 解析：

• Actor、执行 Principal 与认证决策；
• Organization 与 Workspace；
• 可选 Project；
• idempotencyKey；
• 修改已有资源时的 expectedRevision。

Developer Access Domain

生产 API 和自动化不得依赖某位员工的 Customer Session 或直接归属自然人的 Key。Developer Access Domain 是下列资源链的唯一事实源：

Organization / Personal Space
└── Developer App
    └── Environment
        └── Service Account
            └── DeveloperCredential

• Developer App 唯一归属一个 Organization 或 Personal Space，是客户应用与集成的业务容器。
• Environment 唯一归属一个 Developer App，隔离开发、测试与生产配置、Webhook、限额和风险策略。
• Service Account 唯一归属一个 Environment，并通过 Environment 和 App 继承所有者；它不直接悬挂在 Organization、Personal Space 或 User 下。
• DeveloperCredential 唯一归属一个 Service Account。API Key 是其首期类型，不能直接绑定 App、Environment、Organization 或 User。
• Workspace 与 Project 是 App 或 Service Account 的授权绑定，不插入上述父子层级。

个人开发者首次进入登录后的 console.oceanway.tech/ai 时，系统幂等创建 Personal Space、默认 App、默认 Environment 与默认 Service Account；界面可以折叠层级，但数据库不能退回 User-owned Key。ai.oceanway.tech 只公开展示模型、文档、API 列表价与状态，不管理上述资源；所有机器调用只进入 api.oceanway.tech/v1。

Developer Control 的用量视图只统计 API Surface；钱包充值、服务购买、订阅、发票与跨产品消费总览归 Console 的统一 Commerce/Billing 界面。console.oceanway.tech/ai 可以展示授权摘要或跳转入口，但不能拥有第二份钱包、订单或账本事实。

Service Account：

• 唯一归属一个 Environment，可进一步限制 Workspace/Project；
• 没有交互式登录，也不创建自己的 Organization、Personal Space 或钱包；
• 具有独立角色、预算、模型白名单、MCP Tool Grant 和网络策略；
• DeveloperCredential 可轮换、到期和立即撤销；
• 由团队或岗位负责，并保留实际创建者和调用者审计。

Developer App 可以拥有多个 Environment；Environment 可以拥有多个 Service Account、Webhook Endpoint 与用量视图；每个 Service Account 可以拥有多枚 DeveloperCredential。配额和预算是限制，不是第二个钱包。

Credential 名称必须按用途分型，不能把不同信任边界压成一个通用 Secret：

这些类型不互相交换、复用或继承。DeveloperCredential 的 Secret 只在创建时显示一次，服务端保存校验 Hash；WebhookSigningSecretVersion、MCPConnectionSecret 和 ProviderCredentialVersion 按各自 Vault 与版本契约托管。

成员离职与撤权

企业成员退出或被移除时，系统应在同一撤权流程中：

1. 将 Membership 设为 suspended 或 revoked。
2. 撤销该组织下的 Session、PAT、OAuth Grant 和临时 Run Token。
3. 禁止创建新 Run 和新消费。
4. 停用其个人 MCP Connection；组织 Connection 保留但重新检查负责人。
5. 转交 Project、Agent、Service Account、审批和资产管理责任。
6. 企业资产、Canvas、Run、账本和审计记录原地保留。
7. 复核该成员可能接触的长期 Secret，并按策略轮换。
8. Independent Identity 仍可登录个人空间；Managed Identity 可由企业整体停用。

唯一 Owner 不能直接退出，必须先转移所有权。删除个人账户不能删除企业资源；必须在隐私删除与企业法定留存之间保留可审计、可去标识化的边界。

核心不变量

• 登录成功不等于获得某个 Workspace 的资源权限。
• Project 是业务关联，不替代 Workspace 所有权边界。
• 企业成员是 Membership；严格受管账号是 Managed Identity。
• 企业资源归 Workspace，createdBy 只代表创建事实。
• 个人和企业钱包、资产、MCP Connection 永不静默混用。
• 非人类主体必须有负责人、用途、范围、预算和有效期。
• 任何深链接和后台任务都必须重新验证当前组织上下文。
• Developer Access Domain 统一拥有 Developer App → Environment → Service Account → DeveloperCredential，父级停用立即阻止子 DeveloperCredential 发起新请求。
• ai.oceanway.tech 只提供公开开发者中心，console.oceanway.tech/ai 承载登录后 Developer Control，api.oceanway.tech/v1 是唯一机器入口。
• DeveloperCredential、WebhookSigningSecretVersion、MCPConnectionSecret、ProviderCredentialVersion 与 Workload Credential 不得混用。