Cyril 信任中心
我们对你数据的安全、隐私与可靠性负责。本页概述 Cyril 的安全态势、合规承诺与运营实践。
安全实践
传输中加密
所有发往 Cyril 的流量都使用 TLS 1.2 或更高版本加密。所有端点强制 HTTPS，HTTP 请求会被重定向。
静态加密
各组织的集成密钥、OAuth 令牌和 TOTP 种子在应用层加密，主密钥存放在数据库之外。备份在上传到对象存储之前，先通过 age 加密写出。主数据库依赖托管服务商的卷加密——由服务商管理的 AES-256。
访问控制
基于角色的访问控制，默认遵循最小权限。平台管理员强制启用多因素认证；客户方管理员也可以在整个组织范围内强制要求。
漏洞管理
自动依赖扫描（Dependabot + pnpm audit）、静态分析（CodeQL）和容器扫描（Trivy）为每一次生产部署把关。协同披露通过我们的漏洞赏金计划进行。
事件响应
有成文的事件响应手册，包含严重级别与明确的 SLA。个人数据泄露在确认后 72 小时内通知受影响的客户，符合 GDPR 第 33 条。
租户隔离
共享数据库，在服务层按 org_id 做行级隔离。按照我们的“完成的定义”，每种实体类型都必须有跨租户隔离测试。不存在任何跨租户的数据共享。
AI 与你的数据
Cyril 把 AI 层内建在产品里。既然这一层要读你的业务记录才有用，我们就让它遵守与平台其余部分完全相同的访问规则，并且把哪些内容会离开我们的基础设施讲清楚。
AI 只能看到你能看到的
Cyril 的 AI 以你这个用户的身份作答，而不是以整个组织的身份。检索要经过与界面相同的记录归属、角色和工作区权限过滤，所以它永远不可能取出一条你在界面上无权查看的记录。这一点是用代码强制的——不是给模型的一句叮嘱，那种叮嘱是可以被绕过去的。
这条限制是测出来的，不是嘴上说的
每次改动都会运行跨角色隔离的自动化测试；只要低权限角色能通过 AI 拿到别人的记录，这次发布就会被拦下。AI 的检索行为也会写入访问日志，以备审计。
标识信息在离开之前就被剥离
在任何提示词到达模型服务商之前，结构化的直接标识信息——邮箱地址、电话号码、IP 地址、国民保险号与社会保障号、IBAN 和银行卡号——都会被替换为可逆的令牌，再在你看到的回复里还原。散落在自由文本中的标识信息，比如写在句子中间的人名，没有可靠的规律可循，因此不做令牌化。
外部 AI，你可以直接关掉
组织管理员可以为自己的租户完全停用外部大模型处理。这个开关设在每一次 AI 调用都必经的那一个点上，会在请求体被构造之前就拒绝调用——而不是在界面层拦一道。
还有一条“数据不出门”的选项
完全不能把数据发给第三方模型的组织，可以改走自托管推理——部署在我们的基础设施内，或部署在他们自己的环境里。这条路径没有公有服务商兜底：请求要么到达私有端点，要么直接失败。
租户隔离同样适用于 AI
每一次 AI 调用和检索查询都限定在单一组织之内。两个组织之间不会共享检索结果，也不会与模型服务商共享同一段缓存的提示词前缀。
模型训练。我们通过 Anthropic 和 OpenAI 的商用 API 层使用其模型；按这两家服务商公开的条款，这部分数据不会被用于训练他们的模型。大家通常担心的那种消费级聊天产品的训练行为，并不适用于 API 流量。
还有哪些没做完。与其让你自己去猜，我们宁愿直说。有两项承诺尚未生效：以我们的运营主体与每一家模型服务商签署的数据处理协议，以及能够取消服务商短期滥用监控留存窗口的零数据保留条款。在这两项落定之前，我们只能按服务商公开的标准条款使用他们的服务，面向客户的数据处理协议也只能以草案而非经法律顾问审定的正式协议形式提供；除了那些公开条款所给予的保障之外，我们不作任何合同层面的留存承诺。需要更早拿到保证的组织，可以使用上面提到的租户 AI 开关或“数据不出门”方案。每完成一项，我们都会带上日期更新这一节。
上面这些工程层面的控制措施，出自一次内部 AI 信任态势审计，其中也写明了我们发现的缺口以及各自的处理办法。可应要求提供——请发邮件至 security@getcyril.com。
合规与认证
SOC 2 Type 1
正在准备首次审计
SOC 2 Type 1 是 Cyril 正式发布的前置条件。Type 2 将在 Type 1 出具鉴证报告六个月之后进行。我们目前没有任何认证，也没有可提供的审计报告。
GDPR
已合规
我们按照 GDPR 处理个人数据。数据主体的各项权利——访问、删除、更正和可携带——都可以通过平台行使。
数据处理协议
草案 — 待法律顾问审阅
我们的数据处理协议现在就可以查阅，但它尚未完成法律顾问审阅，因此是以草案形式发布供评估，而不是最终协议。需要正式签署版本的客户请联系我们，我们会确认时间安排。
可用性与服务状态
Cyril 是仍在积极开发中的预发布软件，我们的服务条款也写得很直白：不承诺可用性，也没有服务级别协议。我们不在这里公布任何可用率数字，也没有服务补偿。实际使用中，服务可能因维护而中断，功能可能在部署期间短暂不可用；产品还年轻，缺陷一定会在生产环境里被发现。
只有在企业订购合同中另行约定时，服务级别和支持响应时间才成立。那些约定只对该客户生效，并优先于这里的一般立场；默认情况下一项都不适用。如果你必须先拿到承诺的服务级别才能采用 Cyril，这件事应该在签订订购合同时谈，而不是从这个页面上想当然。
实时服务状态——正在发生的事件、计划内维护和历史可用性——都在 status.getcyril.com。这个状态页是正式发布前加固工作的一部分，仍在搭建中；在它上线之前，客户可以通过组织的邮件联系人订阅事件通知。
次级处理方
有些第三方本来就是 Cyril 运转方式的一部分——主机托管、邮件投递、AI 层背后的模型服务商。平台上的每一个组织都会用到它们，没有开关可以关掉。另一些则是可选的：只有当你们组织里有人在设置 → 集成中打开某个集成时，它们才会被启用。如果始终没有配置该集成，就不会有任何数据流向那一方。
我们不在这里另存一份副本；权威披露——每一家服务商、发送给它的内容、处理所在区域，以及它所受的数据条款——完整发布在 /legal/sub-processors/。
变更通知。那个页面是变更最先出现的地方：新增、移除或更换次级处理方时，我们会连同它标注的日期一起更新。数据处理协议第 3.2 条承诺，任何始终启用的服务商发生变更前，会提前 60 天书面通知，你也有权在这个窗口内提出异议。该协议仍是待法律审阅的草案，所以这项承诺只能达到草案所能达到的约束力——但它就写在你今天可以下载的那份文件里，我们宁愿被它约束，也不愿它躺在那里没人看。想在名单变更时收到通知，请发邮件至 legal@getcyril.com。
漏洞赏金
我们运行一个协同漏洞披露计划，欢迎善意的安全研究人员提交报告。符合条件的报告会获得公开致谢；我们也承诺，绝不对遵守该政策的研究人员采取法律行动。