Havenlon 的底层设计哲学：分层不信任架构

很多安全系统在设计时都会先假设某一层是可信的。相信 SaaS 后台不会作恶。 相信管理员不会滥权。 相信程序员不会留下后门。 相信 App 不会被篡改。 相信 API 服务不会泄露密钥。 相信一个设备拿到权限之后就会按照规则执行。 相信一个 Owner 拥有最高权限是合理且安全的。这种设计在普通软件系统里很常见。因为普通系统处理的大多是数据、内容、配置和流程。即使出现错误很多时候还有撤销、回滚、冻结、人工处理和事后补救的空间。但在高风险执行场景里这种默认信任会变得非常危险。比如 Web3 资金转移、企业 API 调用、支付网关操作、生产系统运维、证书签发、设备控制、AI Agent 自动执行等场景一旦动作被真正执行结果往往很难简单回滚。所以 Havenlon 从一开始就不是按照“谁是最高权限”来设计系统而是按照另一个问题来设计如果这一层失效、作恶、被攻破或者被滥用它最多能造成多大伤害这就是 Havenlon 的核心设计哲学分层不信任架构。一、不是谁都不信而是不默认信任任何单点分层不信任不等于混乱的不信任。它不是说系统里没有信任也不是说所有人都是坏人而是说任何单一角色、单一软件、单一设备、单一后台、单一密钥、单一管理员都不应该天然拥有完成高风险执行的能力。信任不能只停留在人、流程和承诺上。信任必须被拆开被约束被验证并最终被硬件和系统结构强制执行。在 Havenlon 里一个动作从发起到最终执行不是简单地从 App 到服务器再由服务器调用密钥完成签名或提交。它会被拆成多个层级发起层 身份层 授权层 仲裁层 策略层 执行层 密钥层 硬件隔离层 安全芯片层每一层只负责自己被允许负责的部分。每一层都不能单独完成最终执行。二、从 SaaS 到 App先假设软件层不可信在传统系统里SaaS 往往是最高控制中心。SaaS 可以保存用户数据管理策略触发执行调用 API甚至直接持有密钥或间接控制密钥使用。但在 Havenlon 的设计里SaaS 不应该天然可信。SaaS 可以管理策略。 SaaS 可以展示状态。 SaaS 可以转发请求。 SaaS 可以协调审批流程。 SaaS 可以记录日志。但 SaaS 不应该直接拥有最终执行权。它不能直接拿到私钥。 不能直接拿到核心 Secret。 不能绕过硬件仲裁。 不能替用户单方面完成高风险动作。App 也是一样。App 可以作为用户入口可以发起 intent可以展示确认信息可以辅助交互但 App 本身不应该成为最终信任根。因为 App 可能被篡改手机可能被攻破前端可能被替换接口可能被滥用。所以 Havenlon 的第一层不信任就是对软件入口的不信任。软件可以表达意图但不能单独完成执行。三、API 不应该直接等于执行权在很多现代系统中API Key、Secret、Token、证书和私钥几乎就等于执行权。谁拿到它谁就能执行。这正是问题所在。API 原本只是系统之间通信的接口但在现实业务里它往往承载了真正的操作能力。调用支付接口。 调用云厂商接口。 调用交易接口。 调用设备控制接口。 调用数据库接口。 调用生产系统接口。如果 API 凭证直接暴露在服务器、脚本、SaaS 后台、CI/CD 系统、开发人员环境或 AI Agent 工具链里那么系统实际依赖的仍然是“相信拿到凭证的人不会乱用”。Havenlon 不接受这种设计。在 Havenlon 的逻辑里API Key 和 Secret 不应该被暴露为可复制的字符串而应该被封装成受控执行能力。外部系统不应该拿到 Secret。外部系统只能提交 intent。真正的密钥、证书、签名和加密动作应该发生在受控的执行边界内。这也是 Enigma Executor 的意义。四、Enigma Hub治理与仲裁核心Enigma Hub 是 Havenlon 硬件执行体系中的治理与仲裁核心。它负责策略、审批、路由、风控和执行前判断。但 Hub 本身也不是一个可以无限信任的超级管理员。Hub 的价值不是让它成为新的单点权力中心而是让它成为多个角色、多个设备、多个策略之间的仲裁节点。它要判断这次请求是谁发起的。 是否符合策略。 是否超过限额。 是否需要多人审批。 是否在允许的时间窗口内。 是否指向允许的地址、合约、API 或业务对象。 是否满足风险规则。 是否已经经过正确的授权路径。Hub 不直接代表某一个人。它代表的是规则本身。在 Havenlon 里Hub 的角色不是“我信任 Hub 所以它能做任何事”而是Hub 必须在规则范围内仲裁。 Hub 必须接受身份层、授权层和执行层的约束。 Hub 不能绕过最终执行边界。这就是分层不信任的核心。即使是治理核心也不能天然拥有无限执行权。五、Enigma Pass Key身份发起端Enigma Pass Key 负责证明“谁在发起请求”。它解决的是身份问题。一个高风险动作首先要知道是谁发起的。但 Pass Key 也不是最终执行器。它可以证明某个请求来自某个被授权身份可以参与 intent 的生成和签名可以作为用户或角色的身份入口。但它不能单独完成最终执行。因为身份不等于授权。某个人可以发起请求不代表他一定可以批准这次请求。 某个人可以登录系统不代表他可以转走资金。 某个 AI Agent 可以代表业务系统提交任务不代表它可以越过策略直接执行。所以 Pass Key 的边界很清楚它证明“谁在请求”。 但它不证明“这件事一定可以执行”。这就是身份层的不信任。身份只能回答 who。不能直接决定 execute。六、Enigma Auth Key授权确认端Enigma Auth Key 负责证明“谁批准这次执行”。它解决的是授权问题。在高风险场景里发起和批准不能混在一起。如果一个人既能发起又能批准又能执行那么系统本质上还是单点信任。Auth Key 的意义是把授权动作从发起动作里拆出来。某个请求可以由 Pass Key 发起但必须由对应的 Auth Key 或多个 Auth Key 完成确认。这对于 Web3 资金治理尤其重要。资金转移不应该只依赖一个人。 合约调用不应该只依赖一个后台。 项目金库不应该只依赖程序员手里的脚本。 Owner 也不应该天然拥有绕过所有人的最终执行权。但 Auth Key 本身也不是万能的。它可以批准但不能绕过 Hub 的策略。 它可以确认但不能直接接触最终密钥。 它可以参与授权但不能单独完成最终执行。授权层被拆出来同时也被限制在自己的边界内。这就是分层不信任。七、Enigma Executor现实世界执行端Enigma Executor 是 Havenlon 从 Web3 签名走向现实世界执行控制的重要设备形态。它面对的不只是链上私钥而是现实业务中的各种高风险凭证API Key Secret TLS 证书 商户密钥 支付通道密钥 设备控制密钥 云服务凭证 数据库密码 Webhook 签名密钥 运维密钥 机器到机器通信凭证在传统系统里这些凭证往往被保存在服务器、配置文件、环境变量、KMS、CI/CD、SaaS 后台或开发人员手里。但只要凭证可以被读取、复制、导出和滥用它就仍然是一个风险源。Enigma Executor 的目标是把这些凭证变成硬件封装的执行能力。外部系统不拿 Secret。 外部系统只提交 intent。 Hub 负责仲裁。 Auth Key 负责批准。 Executor 在硬件内部完成加密、签名、数据排序、API 调用、证书操作、设备指令或业务提交。也就是说Executor 不只是一个密钥保险箱。它是一个受控执行端。它把“凭证暴露”变成“受控执行”。这对 AI Agent、自动化运维、支付网关、企业 API、IoT 设备和机器执行系统都非常重要。因为未来真正危险的不是 AI 会不会回答问题而是 AI 一旦拿到现实系统的执行接口谁来定义它能做什么不能做什么。八、硬件内部也遵循分层不信任Havenlon 的分层不信任不只存在于产品和系统层面也进入硬件内部。硬件本身也不应该被看成一个整体黑盒。在 Enigma 体系里Linux、MCU、安全芯片、通信链路、存储模块、显示确认、按键输入、传感器、证书芯片、签名芯片都应该被拆成不同边界。Linux 不直接接触最终私钥。 应用层不直接访问 Security 模块。 Arbiter 负责仲裁但不等于最终密钥持有者。 Security 模块负责最终执行但不直接暴露给外部系统。 安全芯片负责密钥保护但它的调用也必须受到上层策略约束。 显示和按键用于本地确认但不能取代完整审批链。 通信链路需要加密和认证但不能因为链路安全就默认请求可信。甚至每一个 IC、每一条通信线、每一个固件模块都可以被放进这个问题里审视如果它失效了会发生什么 如果它被攻破了能不能直接完成高风险执行 如果它返回了错误数据系统有没有第二层校验 如果它被软件滥用硬件边界能不能阻止这不是为了复杂而复杂。这是为了避免任何一个单点成为系统的绝对信任源。九、Havenlon 的核心不是保存密钥而是限制执行权很多人第一次看到 Havenlon可能会把它理解成一种硬件钱包、密钥设备、多签系统或安全模块。但这些都只是表象。Havenlon 真正关注的不是“密钥在哪里保存”而是“执行权如何被约束”。密钥安全当然重要。但更重要的是谁能让密钥被使用 在什么条件下可以使用 谁批准这次使用 策略是否允许 执行对象是否正确 金额是否超限 API 调用是否越权 AI Agent 是否只是提出请求而不是直接执行 SaaS 是否只能协调而不能绕过 程序员是否无法通过代码后门直接完成执行所以 Havenlon 的本质不是密钥管理系统。它是执行控制系统。密钥只是执行权的一种载体。Secret、证书、API Key、支付通道密钥、设备控制密钥也都是执行权的载体。Havenlon 要做的是把这些执行权放进分层不信任的结构里。十、分层不信任是 AI 时代的执行安全基础AI 正在从信息工具走向执行工具。过去 AI 主要回答问题、生成内容、辅助分析。 未来 AI 会越来越多地调用 API、写代码、提交 PR、操作系统、管理工作流、控制设备、处理支付、执行交易和参与企业运营。当 AI 只是生成文本时风险主要在信息层。但当 AI 可以执行动作时风险就进入了执行层。执行层的风险不能只靠提示词、日志、检测和事后审计来解决。检测可以告诉我们风险可能发生了。 审计可以告诉我们风险已经发生了。 但执行控制要解决的是在风险真正造成后果之前系统能不能阻止它。这就是 Havenlon 所关注的问题。不是让 AI 更强。 而是让 AI 的执行变得可控。不是相信 AI 永远不会犯错。 而是假设 AI、SaaS、程序员、后台、设备、API、管理员都有可能出错或越界然后通过分层边界限制它们能造成的伤害。这就是分层不信任架构的意义。结语信任不是默认存在的而是被结构化出来的Havenlon 不先问谁值得信任。Havenlon 先问如果这一层不可信系统还能不能安全运行这就是它和传统安全系统最大的区别。传统系统经常寻找一个最高可信点。Havenlon 则尝试把最高可信点拆开让每一层只能在自己的边界内工作。SaaS 不能直接执行。 App 不能直接执行。 Pass Key 不能单独执行。 Auth Key 不能绕过策略执行。 Hub 不能越过最终执行边界。 Executor 不暴露密钥只执行被允许的动作。 Security 模块不直接暴露给外部。 安全芯片不等于完整系统安全。 Owner 也不天然拥有最终执行权。这不是简单的不信任。这是把不信任工程化。Havenlon 的核心设计哲学可以总结成一句话不要默认信任任何单点而是让每一层都只能造成有限影响。