Archyl Cloud 的数据安全：我们保护什么、如何保护，以及我们不声称什么

在你的供应商安全问卷里，总有一行写着“客户数据是否进行静态加密？是 / 否”。对 Archyl Cloud 来说，准确的回答是“是，具体是以下这些字段”。你的架构文本（名称、描述、ADR、文档）和你的凭据，会在数据库看到它们之前由我们的应用程序加密。上传的文件由存储服务商加密。标识符、时间戳、图中的位置和账户邮箱保持明文，因为数据库必须对它们建立索引并进行 join。一个只勾选“是”却不说明哪些是哪些的供应商，等于在要求你对问卷的其余部分盲目信任。

这篇文章是那个详细的回答。它涵盖我们加密什么以及如何加密、数据如何流动、谁能访问什么、我们的 AI 服务商收到什么、我们如何测试，以及你在 GDPR 下可以做什么。它也会坦白说明我们尚未做到的地方：Archyl 目前没有任何安全认证。

本文所有内容都与安全白皮书（v3.0）和数据处理协议（DPA）保持一致，两者都于 2026 年 9 月 27 日更新，也都可以从信任中心找到链接。如果这里的某句话和那里的某句话出现不一致，请告诉我们，因为其中必有一句是错的。

简要版

给此刻正在填表的人：

文章的其余部分是每一行背后的细节。

静态加密，逐字段说明

Archyl 在应用程序中加密字段，然后才写入数据库。每个存有客户内容的模型都带有一个保存钩子，在写入时用 AES-256-GCM 加密其文本字段，并有一个对应的钩子在读出时解密。每次加密都使用一个全新的随机 nonce，因此同一个值存储两次会产生两个不同的密文。

这覆盖的是你的架构内容，而不仅仅是你的密钥：

• C4 模型： 系统、容器、组件和代码元素（名称、描述、标签）；关系（描述、标签）
• Architecture Decision Records： 标题、背景、决策、后果、标签
• 文档： 标题、内容、文件路径、标签；以及针对文档的评论
• API 契约： 名称、描述、内容、端点、版本
• 流程和白板： 名称、描述、技术标签
• 此外还有： 叠加层、事件通道、洞察、发布、一致性规则、变更历史和快照

以及 Archyl 存储的每一项凭据和密钥：

• 来自 GitHub、GitLab 和 Bitbucket 的 OAuth 令牌
• API 密钥
• MFA 密钥和恢复码
• 集成和应用市场的凭据
• 仓库访问令牌
• 云连接设置

这项加密始终开启。加密密钥通过 Argon2id 从一个配置的密钥派生而来，如果该密钥缺失或少于 32 个字符，服务器会在启动时退出。不存在任何让 Archyl 运行并以明文写入这些字段的配置。

实际的结果是：仅凭一份数据库副本，只能看出你的数据的形状，看不到其中的文字。你的服务名称、ADR 中的推理、文档正文、GitHub 令牌和 MFA 密钥，全都还需要密钥才能读取。

凭据也永远不会通过 API 再次返回。集成设置在每次读取时都会被遮蔽，所以一旦你把密钥粘贴进 Archyl，界面可以告诉你已存储了一个密钥，但无法再次向你显示它，也没有任何 API 调用会把它返回给你组织中的其他任何人。

这不覆盖什么

数据库必须能够查找、排序和 join 数据行，而在密文上做不到这一点。所以有些字段保持明文：

• 标识符以及元素之间的链接。 数据库知道元素 A 属于容器 B，并且与元素 C 存在关系。它不知道它们各自叫什么名字。
• 时间戳和图中的位置。
• 账户邮箱地址以及名字和姓氏。 邮箱带有唯一索引，因此两个账户不能使用同一个地址。

这些字段受到下文所述的访问控制以及传输中 TLS 的保护。本文对数据库的磁盘级加密不作任何声称，无论是肯定还是否定。

上传的文件

你附加到文档中的文件（图片、PDF、其他文档）不存放在数据库中。它们存储在 Google Cloud Storage 中，并且：

• 存储桶是私有的。 其中的任何内容都无法被公开读取或列出。
• 文件在静态时使用 AES-256 加密，由 Google Cloud Storage 执行，密钥由服务商管理。
• 文件只通过短期有效的签名 URL 提供。 每个链接只授予对一个文件的访问权限，并在生成后不久过期，因此被复制到工单或聊天中的链接会失效，而不会变成一个永久的公开 URL。
• 默认区域为欧盟：比利时，europe-west1。

传输中加密

你的浏览器、你的工具与 Archyl Cloud 之间的流量使用 TLS 1.3。应用程序到其 PostgreSQL 数据库的连接强制要求 SSL，因此应用程序不会以明文与数据库通信。

谁能进入

人员

• 多因素认证使用 TOTP，也就是身份验证器应用中的六位数字验证码。每个 MFA 质询只能使用一次，恢复码以 bcrypt 哈希形式存储，因此可以校验，但无法读回。
• 单点登录支持 SAML 2.0 和 OpenID Connect。登录总是从 Archyl 发起（仅支持 SP-initiated），将身份提供商的响应与该请求关联起来的 state 绑定到发起请求的浏览器，并且只能使用一次。我们的 SSO 文章介绍了配置方法。
• OAuth 登录支持 GitHub、GitLab 和 Bitbucket。
• 修改密码或移除 MFA 会撤销所有更早的会话。 如果你认为某个密码已经泄露，修改它就会让所有其他使用该密码的设备退出登录。
• 密码重置不会透露某个账户是否存在，而且重置链接一经使用即失效。
• 登录、MFA 和密码重置都有速率限制，限制是分层的，因此单个 IP、单个账户或单个质询各自只能被尝试有限的次数。

机器：API 密钥和 AI 智能体

• API 密钥默认是只读的。 写入权限必须单独授予，并且密钥可以限定到特定项目，因此交给一个只读取某个项目模型的 CI 任务的密钥，就只能做这件事。
• MCP 服务器是 AI 智能体用来读取和更新你的架构的入口，它通过 OAuth 并强制使用 PKCE 进行认证。每一次变更操作都需要写入 scope，因此你为回答架构问题而接入的智能体，除非你授予了写入权限，否则无法修改架构。

租户隔离

每个多租户产品都必须在设计上防范的失败，描述起来很简单：服务器检查你已登录并属于某个组织，然后就信任请求中携带的任何标识符。改一下 URL 里的 ID，你就在读别人的数据了。

Archyl 针对每个请求所访问的资源对其进行授权。请求一张图、一份文档或一个密钥，意味着要检查拥有该具体资源的项目或组织是否是你有权访问的，而不仅仅是检查你是否已登录。同样的规则适用于 HTTP API 和 MCP 服务器。

有两个特性保证这一点长期有效：

• 授权采用失败即拒绝（fail closed）策略。 如果无法确定某个资源的归属，答案就是否。
• 自动化的租户隔离测试在 CI 中运行，一旦有授权检查被移除，构建就会失败，而不是等到有人注意到。

AI 能看到什么

Archyl Cloud 的 AI 功能使用 OpenAI，不使用任何其他 AI 服务商，除非你的组织配置了自己的密钥。

对于架构发现（读取一个仓库并提出一个 C4 模型），我们发送的是代码签名，而不是源代码。下面是一个文件在你仓库中的原样：

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

下面是架构发现为它构建的片段，也就是进入提示词的内容：

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

审批规则、阈值以及 Finalize 的函数体都不会发送。会发送的是：仓库名称、文件和目录结构，以及这些签名（import、类型和函数声明、导出的常量）。这足以推断出一个计费组件在与 Stripe 通信。但这并非无足轻重：函数名和类型名描述了你的系统，所以请把它们当作你正在共享的数据。

对这一说法有两点限定，以免你读出超出其本意的含义：

• 它描述的是架构发现对源代码的处理方式。 如果架构发现在仓库中找到用 Markdown 编写的 Architecture Decision Records，它会发送其文本，以便将其转换为结构化的决策；它还会发送文档文件的开头几行，用来为它们生成标题。
• 其他 AI 功能发送其任务所需的内容。 例如，编码智能体处理它正在修改的文件，因此它能看到这些文件。

如果你的政策规定代码只能发送给与你签有合同的服务商，组织可以使用自己的 AI 密钥。这样 AI 请求就会发往该服务商，适用你的合同。如果任何东西都不能离开你的网络，自托管的 Archyl 可以在你自己的硬件上用 Ollama 运行模型。

我们如何测试

在流水线中

我们的 CI 流水线运行四个安全扫描器：

• govulncheck：检查我们实际调用的 Go 依赖中的已知漏洞
• CodeQL：对我们自己的代码进行静态分析
• gitleaks：检查被误提交的密钥
• Trivy：检查容器镜像和基础设施配置中的漏洞

在平台中

• 出站请求会被检查。 每个调用由你提供的 URL 的集成（自托管 Git 服务器、webhook、AI 端点）都有针对服务器端请求伪造（SSRF）的防护，因此该 URL 无法被用来让 Archyl 访问其自身的内部网络。
• 浏览器只运行我们发布的脚本。 严格的 Content-Security-Policy 通过哈希列出每一个内联脚本，从 CDN 加载的脚本带有 Subresource Integrity 哈希，因此被篡改的副本会被拒绝。
• 容器经过加固锁定。 它们以非 root 用户身份、在只读文件系统上运行，并移除了 Linux capabilities。
• 安全事件会被记录，包括登录失败、MFA 尝试失败和被拒绝的令牌。

渗透测试

2026 年 7 月至 9 月期间，我们进行了十轮内部渗透测试。每一项发现都已修复，并由回归测试覆盖，因此同样的问题如果再次出现就会被发现。

“内部”就是字面意思：这些测试由我们自己执行，没有任何独立公司参与。独立渗透测试计划作为 SOC 2 审计的一部分进行。

你在 GDPR 下的权利

• 导出。 你可以将数据导出为 JSON。
• 删除。 删除你的账户会删除属于它的一切，级联删除你的数据，包括上传到对象存储中的附件。
• 每位客户都有 DPA。 数据处理协议向所有客户提供。
• 72 小时内通知数据泄露。
• 对子处理方的任何变更提前 30 天通知，让你可以在变更发生前提出异议。

以下是目前的子处理方：

DPA 列出了每一方的所在地和法律保障措施。

我们尚不声称的内容

一个只列出优势的安全页面，等于让你自己去找差距。它们在这里：

• 没有认证。 Archyl 没有获得 SOC 2 认证，也没有获得 ISO 27001 认证。对于 SOC 2 Type I，就绪评估（readiness assessment）已完成，独立审计待进行。ISO 27001 已在计划中。当审计报告出来时，信任中心会说明；在此之前，我们发布的任何内容都不应暗示相反的情况。
• 尚无独立渗透测试。 上文所述的十轮测试都是内部测试。独立测试将随 SOC 2 审计一同进行。
• 并非每一列都加密。 如上所述，标识符、时间戳、图中的位置、邮箱和姓名保持明文。

如果你的流程要求一项 Archyl 尚未获得的认证，那就是一个真实的限制，我们宁愿你现在就知道，而不是在采购审查的第六周才发现。

下一步

• 信任中心把相关文档集中在一处。
• 安全白皮书对每项控制措施有更深入的说明，包括速率限制和我们记录的安全事件。
• 数据处理协议是上文 GDPR 部分的合同版本。
• 如有数据保护方面的问题，或本文没有回答的问卷条目，请写信至 privacy@archyl.com。
• 如需报告漏洞，请写信至 security@archyl.com。我们会在 24 小时内确认收到。

如果你就是需要为 Archyl 签字批准的人，我们宁愿你为每个问题找到一个精确的答案，也不愿你为大多数问题得到一个自信的答案。如果这里有任何内容对你的审查来说不够精确，请提出来，我们会把它说精确。