KiloClaw 安全
安全架构、租户隔离与面向托管式AI智能体算力的数据保护
2026年2月 v1.0；Andrew Storms 独立安全评估
KiloClaw 是一个托管式计算平台，在每个专用虚拟机中运行每个用户的 AI 智能体实例。每位客户都会获得一个隔离的环境，其 AI 智能体可以在其中执行代码、访问文件系统、浏览网页以及连接到聊天频道（如 Telegram、Discord 和 Slack）。
对于代表客户执行任意代码的 AI 智能体托管式计算这类产品，其安全风险本身就很高。租户隔离的失误可能会将一个客户的秘密、对话和已连接账户暴露给另一个客户。机密管理的失误可能会危及客户托付给该平台的 API 密钥。
本白皮书介绍了 KiloClaw 的安全架构、保护客户数据的控制措施，以及 2026 年 2 月进行的独立安全评估的结果。它面向评估 KiloClaw 是否适合其组织的安全团队、合规官和技术决策者。
评估摘要
一项为期10天的独立安全评估通过威胁建模（采用 PASTA 框架，涵盖13项资产中的30个威胁）、代码审查、60多项对抗性测试以及实时基础设施测试，验证了 KiloClaw 的架构。总体结论是：KiloClaw 的安全架构是健全的，并在多个独立层实施了租户隔离。
KiloClaw 的工作原理
理解安全模型需要先理解其架构。当客户配置一个 KiloClaw 实例时，该平台会通过多层基础设施创建一个专用的计算环境。
请求流程
客户的浏览器连接到一个 Cloudflare Worker，该 Worker 通过签名的 JWT cookie 对请求进行身份验证。该 Worker 通过一个 Durable Object（一个每用户状态存储）查找客户的专用虚拟机，然后将请求代理到客户在 Fly.io 上的机器。在机器内部，一个控制器进程将流量路由到 OpenClaw AI 智能体运行时。
此链中的每一跳都强制执行身份验证。没有用户可控的值会影响接收流量的机器——机器路由始终源于服务器端存储的已认证用户身份。
计算模型
每位客户在 Fly.io 上的一个专用 Firecracker 微型虚拟机内运行。Firecracker 与 AWS Lambda 和 AWS Fargate 使用的虚拟机监视器相同，提供硬件级别的租户间隔离。每位客户还会获得一个专用的 Fly 应用程序（具有其自己的隔离网络）和一个用于持久存储的专用 NVMe 支持卷。
这不是基于容器的隔离。每个客户的工作负载都在其自己的虚拟机中运行，拥有自己的内核，并且在虚拟机监控程序级别与其他所有客户隔离开。
租户隔离
租户隔离是任何多租户平台最关键的安全属性。KiloClaw 在五个独立层强制执行隔离，要发生跨租户入侵，这些层必须同时失效。
第1层：基于身份的路由
每个请求都通过一个 JWT cookie 进行身份验证，该 cookie 根据签名密钥和存储在数据库中的每个用户的 pepper 进行验证。该 pepper 支持服务器端会话撤销——如果 pepper 被轮换，该用户的所有现有会话将立即失效。系统采用“故障闭合”设计：如果数据库无法访问，身份验证将失败，而不是回退到不太安全的模式。
经过身份验证的用户身份用于派生一个确定性的 Durable Object 键，该键映射到恰好一个每用户状态存储。此状态存储保存该用户实例的 Fly 机器和卷标识符。没有用户提供的值可以影响哪个机器接收代理请求。
第2层：每用户 Fly 应用程序
每位客户的虚拟机在一个专用的 Fly 应用程序内运行。应用程序名称源自用户身份的 SHA-256 哈希值，并截断至 80 位熵。这提供了极低的碰撞概率，并且所有权验证检查可以防范几乎不可能发生的哈希碰撞情况。
每用户应用程序意义重大，因为 Fly.io 将资源（机器、卷、网络）限定在应用程序级别。一个应用程序中的卷无法被另一个应用程序中的机器挂载。一个应用程序中的机器无法通过内部 DNS 被另一个应用程序寻址。
第3层：网络隔离
每个每用户 Fly 应用程序都配置有一个隔离的 WireGuard 网络网格。这意味着客户在网络层（而不仅仅是应用程序层）就被隔离开。实时跨租户测试确认：
跨应用程序的内部 DNS 解析失败，应用程序之间的直接 IPv6 连接被阻断，并且只有自引用网络操作成功。
在安全评估期间，通过跨两个独立的每用户 Fly 应用程序进行的八项实时测试验证了这一点。
第4层：Firecracker 虚拟机边界
每个客户的工作负载都在一个 Firecracker 微型虚拟机内执行。Firecracker 使用 KVM 提供基于硬件虚拟化的隔离，具有最小的设备模型和在主机级别应用的限制性 seccomp 过滤器。这与支撑 AWS Lambda（处理了数十亿次调用）的隔离技术相同。
虚拟机边界意味着，即使客户的 AI 智能体因提示注入或恶意工具使用而受损，其影响范围也被限制在该客户自己的虚拟机内。租户之间没有共享的内核、共享的文件系统或共享的进程命名空间。
第5层：卷隔离
每位客户的持久存储是一个专用的 Fly Volume（NVMe 支持的块存储），只能在其自己的 Fly 应用程序内挂载。卷使用 LUKS (AES-XTS) 进行静态加密。卷绑定链已经过审计并确认是健全的——不存在一个客户的卷能被另一个客户的机器挂载的路径。
对抗性测试结果
安全评估对租户隔离链进行了 35 次对抗性输入测试，包括 Unicode 字符（CJK、表情符号、阿拉伯语、混合脚本）、零宽字符、空字节、控制字符、注入负载（路径遍历、SQL、XSS、模板注入）和边界长度输入。所有这些都被正确处理，没有产生跨租户影响。
数据保护
传输中加密
所有外部通信都使用 TLS。浏览器到平台的流量终止于 Cloudflare 的边缘。平台到 Fly.io 的流量使用指向 Fly 代理的 TLS。AI 提供商的 API 调用（Anthropic、OpenAI 等）使用客户自己的 API 密钥通过 HTTPS 进行。
静态加密
Fly Volumes 使用带有 AES-XTS 的 LUKS 进行静态加密。这种加密由 Fly.io 在基础设施级别管理，并且对应用程序是透明的。存储在平台数据库中的客户秘密使用 RSA-OAEP 与 AES-256-GCM（一种现代认证加密方案）进行加密。
数据分类
| 数据类型 | 保护措施 | 存储位置 |
|---|---|---|
| API 密钥（客户提供） | 数据库中使用 RSA-OAEP + AES-256-GCM 加密；仅在机器运行时解密 | 在 Postgres 中加密；在虚拟机环境中解密 |
| 聊天频道令牌 | 与 API 密钥相同的加密方案 | 在 Postgres 中加密；在虚拟机环境中解密 |
| 会话记录 | 静态 LUKS 卷加密；每用户虚拟机隔离 | 客户虚拟机内的 Fly Volume |
| 智能体工作区文件 | 静态 LUKS 卷加密；每用户虚拟机隔离 | 客户虚拟机内的 Fly Volume |
| 身份验证令牌 | 基于 HMAC 派生；存储在每用户 Durable Object 中 | Cloudflare Durable Object 状态 |
数据生命周期与删除
当客户销毁其 KiloClaw 实例时，该平台会执行一个两阶段删除，该过程具有崩溃安全性和基于告警的重试机制。Fly 机器被停止并销毁，Fly 卷被删除（触发 LUKS 密钥销毁），并且所有运行时机密被移除。此过程经过审查，并被确认即使在部分故障的情况下也能可靠地清理所有敏感数据。
一项数据驻留审查确定了九个不同的数据存储，并确认在实例销毁后没有秘密残留。非敏感的元数据（用户标识符、时间戳）可能保留在软删除的数据库记录和操作日志中，这符合标准的可审计性实践。
身份验证与访问控制
用户身份验证
KiloClaw 通过具有以下属性的 JWT cookie 对用户进行身份验证：
- 算法固定为 HS256，防止算法混淆攻击。
- 每用户 pepper 支持服务器端会话撤销，而无需轮换密钥。
- 故障闭合设计：如果数据库无法访问，身份验证将拒绝所有请求。
- Cookie 设置为 HttpOnly、Secure 和 SameSite=Lax。
- 所有秘密验证都使用常数时间比较，防止时序攻击。
内部 API 安全
KiloClaw 内部服务之间的通信使用带有常数时间比较的共享秘密进行身份验证。平台 API 路由与面向用户的路由分离，并且无法从外部访问。安全评估确认，任何 API 端点均不存在 SQL 注入、XSS、命令注入或路径遍历漏洞。
网关身份验证
每个客户的 AI 智能体实例都由一个通过 HMAC 从每实例秘密派生的网关令牌保护。必须出示此令牌才能建立 WebSocket 连接或向智能体发出 API 调用。即使客户的机器可以被直接寻址（绕过 Cloudflare 代理），网关令牌也提供了一个独立的身份验证屏障。
输入验证与注入防御
该平台在用户控制的数据进入系统的每一层都实施了全面的输入验证。
| 攻击向量 | 缓解措施 | 验证结果 |
|---|---|---|
| SQL 注入 | 在所有数据库操作中使用带有类型强制占位符的参数化查询 | 无发现 |
| 跨站脚本 (XSS) | 对全部五个关键字符进行 HTML 实体转义；对 JavaScript 上下文使用 JSON.stringify | 无发现 |
| 命令注入 | 环境变量名根据严格的正则表达式进行验证；使用 POSIX 引用对值进行转义；进程生成使用数组参数（无 shell 插值） | 无发现（测试了 55 个对抗性负载） |
| 路径遍历 | 平台层中没有用户控制的文件路径 | 无发现 |
| 开放重定向 | 所有重定向 URL 均源自服务器，绝非来自用户输入 | 无发现 |
| 模式验证 | 所有 API 请求体在处理前都通过 Zod 模式进行验证 | 无发现 |
命令注入表面受到了特别关注，因为 KiloClaw 会构造 shell 命令来配置客户环境。针对值和变量名称分别进行的 17 次对抗性测试（包含 55 个注入负载）和 30 次测试（针对变量名）证实了转义链是健全的。
虚拟机安全
Firecracker 隔离
每个客户的工作负载都在一个 Firecracker 微型虚拟机中运行。Firecracker 提供了强大的隔离保证，这些保证已在 AWS 大规模验证过。与 KiloClaw 相关的关键属性：
- 使用 KVM 的基于硬件虚拟化的隔离（非容器）
- 最小虚拟设备模型减少了虚拟机监控程序的攻击面
- 主机级别的 seccomp 过滤器限制了 VMM 进程可用的系统调用
- 客户虚拟机内部不存在 Fly.io API 令牌，限制了虚拟机受损时的影响范围
- Fly.io 元数据 API 端点已从客户虚拟机内部被阻止
资源控制
客户虚拟机配置了明确的 CPU 和内存限制。该平台强制执行机器大小限制（CPU 核心数和内存分配），并为每位客户分配恰好一台机器和一个卷。卷大小是固定的。这些控制措施可防止资源滥用，并确保租户之间可预测的隔离。
智能体安全控制
在每台虚拟机内运行的 AI 智能体具有可配置的安全控制。默认情况下，exec 工具（允许智能体运行 shell 命令）需要明确的用户批准才能执行。这些设置在平台的启动脚本中被锁定，不能被智能体本身或通过聊天频道的提示注入所覆盖。
构建与供应链安全
KiloClaw 的机器镜像通过受控的 CI/CD 管道构建，并具有以下安全保障措施：
- Docker 镜像使用 git commit SHA 作为标签，提供从部署镜像到源代码的完全可追溯性。
- OpenClaw AI 运行时的版本在 Dockerfile 中被固定（未设置为“latest”），以防止意外的版本更改。
- 部署管道中的镜像引用使用 SHA 固定，确保部署的是经过审查的确切镜像。
- 所有客户机器都从一个共享镜像仓库拉取；每用户仓库是惰性的，无法影响镜像选择。
安全评估指出了在供应链强化方面需要进一步投入的领域，包括将基础镜像固定到 SHA-256 摘要、使用 Sigstore/cosign 进行镜像签名、生成 SBOM，以及在 CI 中进行自动漏洞扫描。这些计划在下一阶段的安全工作中实施。
网络安全
边界
所有客户流量都经过 Cloudflare，后者在边缘提供 DDoS 缓解、WAF 规则和速率限制。Cloudflare Worker 在将任何请求代理到后端基础设施之前执行 JWT 身份验证。
内部网络
每个用户的 Fly 应用程序都会创建隔离的 WireGuard 网络网格。这种隔离通过实时测试得到了验证：
- 跨应用程序的内部 DNS (.internal) 解析失败——一个客户无法发现另一客户的机器。
- 每用户网络之间的直接 IPv6 连接被阻止。
- 只有自引用操作才能在客户自己的网络内成功。
跨两个独立的每用户 Fly 应用程序进行了八次实时跨租户网络测试。所有测试均确认网络级隔离得到强制执行。
出站流量
客户 AI 智能体需要出站互联网访问才能执行其工作，例如调用 API、获取网页和使用工具。对于此用例，静态出站过滤并不实用，因为智能体的行为本质上是不可预测的。出站访问不受限制，这是在威胁模型中记录的一个已接受风险。出站监控和交互式批准控制已列入产品路线图。
安全评估方法
这项安全评估由一名独立评估员在 2026 年 2 月进行了为期 10 天的评估，使用了 PASTA（攻击模拟与威胁分析过程）框架。评估范围包括：
| 阶段 | 范围 | 结果 |
|---|---|---|
| 威胁建模 | PASTA 框架：跨 13 项资产（6 项客户资产、7 项平台资产）分类了 30 个威胁 | 已完成 |
| 租户隔离 | 路由链代码审查、35 次对抗性输入测试、8 次实时网络隔离测试 | 健全，未发现跨租户路径 |
| 身份验证与访问控制 | JWT 验证、cookie 安全、内部 API 认证、代理链认证、控制器认证 | 健全，故障闭合，时序安全 |
| 输入验证 | SQL 注入、XSS、命令注入（72 个对抗性负载）、路径遍历、开放重定向 | 全面，无发现 |
| 虚拟机与机器安全 | Dockerfile 审查、Firecracker 分析、运行时评估、资源限制、销毁生命周期 | 加固良好，镜像加固进行中 |
| 供应链 | CI/CD 管道、镜像仓库、版本固定、依赖分析 | 部分完成——签名和扫描计划中 |
该评估产生了 12 份审查文档，撰写并合并了 17 个拉取请求（10 个安全修复、7 个加固改进），并审查了另外 18 个拉取请求的安全影响。
常见问题
Kilo 能看到我的 API 密钥吗？
您提供的 API 密钥在平台数据库中使用 RSA-OAEP 与 AES-256-GCM 进行加密。它们仅在您的虚拟机启动时被解密，届时它们会存在于您虚拟机的环境中。Kilo 的平台基础设施处理的是加密的密钥；解密的密钥仅存在于您隔离的虚拟机内部。未来的增强功能包括短期令牌交换和内存中的机密存储，以进一步缩短暴露窗口。
其他租户能访问我的数据吗？
不能。您的数据受到五个独立隔离层的保护：基于身份的路由、一个专用的 Fly 应用程序、一个隔离的 WireGuard 网络、一个专用的 Firecracker 虚拟机以及一个专用的加密卷。安全评估通过代码审查、35 次对抗性输入测试和 8 次实时跨租户网络测试验证了这一点。未发现任何跨租户访问路径。
AI 智能体能逃离其虚拟机吗？
Firecracker 提供基于硬件虚拟化的隔离，这与 AWS Lambda 和 Fargate 大规模使用的技术相同。虚拟机逃逸需要 Firecracker 虚拟机监控程序本身存在漏洞。此外，即使虚拟机受损，每用户网络隔离也会阻止向其他客户机器的横向移动，并且客户虚拟机内部不存在 Fly.io API 令牌。
当我删除实例时，我的数据会发生什么？
实例删除会触发一个两阶段、崩溃安全的数据清理。您的 Fly 机器被销毁，您的 Fly 卷被删除（这会触发 LUKS 加密密钥销毁），并且所有运行时机密被移除。数据驻留审查确认，删除后没有秘密残留。非敏感的元数据可能为了操作可审计性而保留在软删除的数据库记录中。
有人能通过提示注入劫持我的智能体吗？
AI 智能体的 exec 工具在执行任何 shell 命令之前都需要明确的用户批准。此设置由平台强制执行，不能被智能体、提示注入或通过聊天频道消息覆盖。即使提示注入成功改变了智能体的行为，其影响范围也仅限于您自己的虚拟机——它无法访问其他租户的资源或逃逸 Firecracker 边界。
如果 Kilo 自己的基础设施被攻破怎么办？
威胁模型包含了针对每个平台秘密的受损场景。最敏感的凭证（Fly.io API 令牌）不存在于任何客户虚拟机内部。平台秘密存储在 Cloudflare Worker 的秘密中，并且只能被编排层访问。安全评估建议使用限定范围的凭证和每服务身份验证，以进一步减少影响范围，这些已在架构路线图中。
结论
KiloClaw 的安全架构反映了一种认知：面向 AI 智能体的托管式计算是一个固有高风险的产品类别，需要纵深防御。该平台在五个独立层强制执行租户隔离，实施具有服务器端撤销功能的故障闭合身份验证，针对注入攻击验证所有输入，并利用久经考验的 Firecracker 虚拟化技术进行工作负载隔离。
一项独立安全评估通过威胁建模、代码审查、对抗性测试和实时基础设施测试验证了这些控制措施。该评估发现该架构从根本上是健全的，同时在镜像加固、供应链安全性和运营成熟度方面明确了需要持续投入的领域。
如需了解有关 KiloClaw 安全架构的更多信息或请求其他文档，请联系 Kilo 安全团队 (security@kilocode.ai)。