架构与安全¶

基于 ASILO 0.1 的现行应用指南。它不规定技术、环的数量，也不保证安全。

记录一项操作在哪里被提出、在哪里被授权、在哪里产生影响。Markdown 中的规则只起指导作用；有效的控制需要在实际运行的系统中有证据。

先画边界，再画环¶

识别不可信的输入、内部逻辑、权限、数据和作用点。声明哪个模块依赖哪个模块，以及谁拥有每一条边界。然后选择合适的分层模型，并注明其来源配置。

ASILO-R-002 要求声明该模型及其依赖方向；它不要求固定的数量或通用的编号。依据 ASILO-R-002，当应用配置允许时，对依赖规则的自动检查属于建议。面向 TypeScript 的 ASILO 应用配置仍在准备中，其环的编号仍未确定。不要把它当作唯一的架构模型。

区分四个问题¶

问题	检查什么	规则
提议的形式有效吗？	带版本的输入／输出契约。	ASILO-R-001。
这项操作被允许吗？	在作用点的授权。	ASILO-R-001 和 ASILO-R-004。
谁能够停止它，或撤销智能体？	范围、撤销以及经过测试的停止机制。	ASILO-R-004 和 ASILO-R-007。
是否需要事先的人工决定？	关键影响清单与专门的批准。	ASILO-R-005。

有效的输出并不能证明其真实性，也不能证明已获授权。标识符并不能证明身份已经过验证。图表并不能证明所画的控制措施真实存在。

声明每个智能体的范围¶

在运行之前，记录身份、允许的操作和数据、操作次数上限以及委派深度。其范围不超过调用者的范围，也不会在运行中扩大。ASILO-R-004 要求必须能够撤销，并建议在每次操作之前检查撤销状态。在合法范围之内，损害仍可能发生。

人的身份、其在应用中的权限和智能体的身份，三者并不相同。本方法论不规定账户、目录、签名协议或加密算法。记录哪个人对具体对象拥有权威；验证机制属于被评估的应用配置和实现。

关键之处的人工审查¶

ASILO-R-005 的最小清单包括付款、删除、权限变更、向第三方发布或发送，以及影响个人的决定。审查在产生影响之前展示确切的对象，并记录身份、日期和不可复用的批准。这并不意味着对每次读取或每条响应都要求确认。紧急情况下的例外，需要负责人事先作出定义，并在事后进行有记录的审查。

当规则无法作出决定时，ASILO-R-005 建议将该情形交由人工审查，而不是用默认值来解决。它并不是把一切不确定性都变成一种与要求范围无关的通用暂停。

上限与连续性¶

ASILO-R-007 要求设定成本或令牌、操作次数和时间的上限，并要求有一套停止机制，有明确的责任人，且在声称其有效的环境中经过测试。测试针对的是机制，而不是人。上限耗尽应导致停止或审查，而不是悄无声息地继续。依据 ASILO-R-007，停止时要保留已执行内容的记录；允许在不重复已生效影响的前提下恢复执行，属于建议。

更换供应商、重启或重试，既不会消除上限，也不能证明某项操作没有发生。本版本不规定自动回退（fallback），也不规定 kill switch 的格式。存在这些机制时请加以描述并评估其故障；不要把它们的实现归于本方法。

下一步：评估与审查 · 控制工件

图纸与锁具¶

图纸说明各区域之间如何关联；锁具控制出入。在软件中，架构与授权同样需要分别检查。分层安全指南对这一区别作了展开。

术语表。