多数访问控制系统并不是为产品的真实运行方式而设计的。传统的 Web2 云端身份与访问管理（IAM）工具是围绕基础设施构建的，控制的是“谁能调用哪个 API”，而不是聚焦于产品和用户——后者的访问权限往往取决于数据、上下文和时间。

为了弥补这一缺口，团队通常会通过第三方产品或自定义层叠加基于角色（Role-Based Access Control ，RBAC）或基于属性（Attribute-Based Access Control，ABAC）的访问控制层，这反而让架构变得更复杂、更脆弱。

Seal 采用了完全不同的方式：它让加密成为闸门，策略成为钥匙。数据默认保持加密状态，只有当可编程的访问策略明确允许时才会解密。由于规则与数据本身共存，你可以在应用层清晰地表达访问规则，甚至能为同一应用的不同部分设定不同的规则，而无需拼接多个外部系统。

Seal：https://seal.mystenlabs.com/

优于外挂式 IAM

云端 IAM 解决的是基础设施层面的问题，比如“这个身份是否可以调用这个端点？”但大多数产品需要的是业务层面的规则：谁能在什么条件下、在什么时间访问哪个对象。

借助 Seal，你可以将这些逻辑写成随数据一起移动的策略代码。密文可以在不同的服务、云平台或存储后端之间流转，但只有当策略允许时才会解密，从而实现默认的选择性披露。

这种模式减少了系统的蔓延。你无需在网关、微服务和数据库中重复创建角色、范围和权限列表，只需在数据边界定义一次规则即可。

由于策略状态锚定在 Sui 上，并可选择在 Walrus 中存储访问日志，你能获得比零散服务器日志更持久、可审计的记录。结果是更简化的运维、更少的密钥泄露风险，以及策略直接映射到实际功能（如订阅、封禁、许可条款），而非网络或 API 配置。

可直接使用的策略

Seal 自带可复用的策略模板，可在同一产品中自由组合。

策略模板：https://seal-docs.wal.app/ExamplePatterns/

以下示例展示了如何在 Sui 智能合约中编码这些规则：白名单或会员访问：与特定用户或 AI 代理共享加密内容。

Sui 策略示例：“Gold 等级会员可访问标签为 gold/* 的文档。”时间锁访问：协调资产发售或拍卖的揭示时间。

Sui 策略示例：“除非存在法律冻结，否则在 2025-11-01T00:00Z 后解密。”订阅与授权：对高级内容或 API 结果进行限时、付费访问。

Sui 策略示例：“必须具备有效订阅，且地区为 EU，并且许可范围包含 model.infer。”所有者私有数据：仅当前持有人可打开的可移植加密对象。

Sui 策略示例：“仅当前 NFT 持有者可解密附加权益。”安全投票或计票：在满足条件前保持选票加密，达成后链上公开可验证结果。

Sui 策略示例：“当投票率 ≥ 60% 且投票窗口关闭时解密结果。”预签名式访问窗口：对特定 Walrus 数据片段的限时访问。

Sui 策略示例：“允许在 link.expiry 到期前解密该数据片段。”

现实世界的应用示例

这些策略模式可广泛应用于不同领域：企业数据室： “如果对方已签署保密协议（NDA）且交易阶段 ≥ DD，则解锁 /dataroom/acme/* 下的数据集；监管方仅可查看审计日志。”AI 与数据授权： “若客户拥有 SKU X 的 dataset.read 权限，则允许在 09:00-17:00 UTC 间使用模型 Y 进行推理；禁止导出原始训练数据。”媒体与创作者平台： “订阅用户可播放视频 30 天；非订阅用户仅能解密 30 秒预览片段。”数字营销： “活动分析师默认可解密汇总群组数据；个体级数据保持加密，除非存在有效且未过期的用户授权。”金融科技（Fintech）： “审计员角色可在审核期内解密已脱敏的报告案例数据；PII（个人身份信息）字段在风险管理批准前保持隐藏。”

在同一应用中，你可以为不同功能应用不同策略，如会员专属内容、时间锁定预览、用户私密笔记等——无需混乱的访问控制列表。

这比传统 IAM 更简单

大多数团队从云端 IAM（用于 API）开始，整合身份提供商（IdP），再叠加第三方 RBAC 系统，最后还要自建规则引擎来匹配产品逻辑。每一层都有不同的语言（角色、作用域、条件），却都未直接附着在数据上。最终结果是：规则重复、微服务之间可能泄露密钥，并且还要依赖日志来证明访问行为。

使用 Seal 后，执行点位于数据边界。数据保持加密，除非策略另有声明；策略是你可控制与审计的代码；批准记录可存于 Walrus。

这样，你不再需要在网关、服务和存储系统中分散授权逻辑。你只需在靠近产品逻辑的地方定义一次业务规则，让加密承担核心安全职责。这减少了系统复杂度，缩小了错误影响范围，并为所有利益相关方提供了一个清晰的规则： “如果策略未批准，数据就不会被解密。”

实际运作方式

从整体上看，你使用 Seal 加密数据，使明文默认不可见，然后将业务规则编写成一个可审计的小型策略程序。解密过程需要来自独立密钥服务器（未来将支持多方计算委员会）的阈值批准，这些服务器会评估策略，只有在条件满足时，客户端或授权后端才会收到解密密钥。

开发者可以使用 SDK 和基于 Sui 的可复用策略模板，快速实现该功能。无论是在新应用中结合 Walrus（及可选的 Nautilus），还是在现有架构中替换分散的授权逻辑，都能轻松通过简洁、可验证的策略代码实现统一的访问控制。

亲自体验

选择一个敏感流程，比如涉及高级内容、数据集或消息附件的部分，用 Seal 加上一条简单策略来保护它（例如会员访问或时间锁定是很好的起点）。将密文存储在你原本放置内容的位置，例如 Walrus。

随着使用信心的提升，可以逐步扩展到订阅、授权和不同功能模块的策略，在同一产品的不同部分应用不同的访问规则，循序渐进地增强控制能力。你可以查看“快速上手指南”了解如何开始。

快速上手指南：https://seal-docs.wal.app/GettingStarted/

Seal 将业务层级的访问控制放回该在的位置——数据本身。这样，你就能构建出默认私密、逻辑清晰、符合现实合规要求的产品。