动态生成软件改变了什么安全前提？
- 过去: 应用业务代码经开发、审查、测试、部署后在一段时间内保持稳定，因此权限判断通常写在应用层——业务代码先判断“当前用户能否读写这条数据”，再向数据库发起操作;
- 现在: 接口、工作流乃至数据访问代码都由 Agent 随时生成或改写，这一层不再稳定;
- 失效路径一: 新生成的代码漏掉一项细微的权限检查;
- 失效路径二: 暴露原本不可见的字段;
- 失效路径三: 通过另一条调用路径绕开已有判断;
- 结果: 无论成因是普通生成错误还是提示注入后生成危险代码，原本期望由业务代码维持的权限边界都可能被悄然破坏;
为什么不能要求“每次都把权限写对”？
- 目标: 安全目标应是“即使 AI 写错了代码，权限约束仍无法被绕过”;
- 理由: 如果权限检查本身也放在动态生成的业务逻辑中，它就与被约束的代码处在同一个信任域里;
- 局限: 提示词可以要求 Agent 检查权限，测试与代码审查也能降低出错概率，但这些手段很难穷尽每一条新生成的执行路径，无法构成最终的安全边界;
- 对照: 对应三层护栏中最难被绕过的一层，见 护栏与安全;
数据层如何强制执行权限？
- 总原则: 把信任边界下移到数据层;
- 分工: 动态生成的应用层负责界面、流程与业务编排，真正决定“谁能对哪条数据做什么”的规则由稳定、经人类审查的机制强制执行;
- 手段一: 数据库行级安全策略限制用户只能访问所属租户的数据;
- 手段二: 约束与校验器拒绝非法状态;
- 手段三: 受控视图、存储过程或数据访问服务只暴露允许的操作;
- 访问上下文: 每次读写都应携带由受信任运行时绑定的访问上下文（用户、租户、角色或 Agent 身份）;
- 限制: 动态生成的代码只能以这个受限身份访问数据，不能自行伪造身份，也不能获得可绕过规则的高权限数据库凭证;
- 效果: 即使它完全漏写权限判断，数据层仍会拒绝越权操作;
权限下沉是否意味着业务逻辑都塞进数据库？
- 不是: 应用层仍可做权限预检查，以便尽早给用户反馈;
- 但: 数据层必须保留最终裁决权;
- 惯例: 同一条规则可以在上层用于改善体验，在下层用于提供保证;
- 必要条件: 所有数据访问路径都必须经过受信任的数据层，不能让生成代码绕过它直连数据库;
- 收益: 上层可以持续变化，不可违反的权限约束留在不会随每次生成而重写的数据层中;
动态生成软件还有哪些务实形态与验证结论？
- 边界形态: 完全实时生成整套应用（如“Imagine with Claude”）成本与延迟较高，更适合展示能力边界;
- 务实方向: 基于已有框架做半定制——保留基础软件稳定性，在特定维度开放控制权;
- 交互示例: 用户说“把按钮改成蓝色”“在侧边栏添加快捷菜单”“修改字体”，Agent 改前端代码后经热加载（HMR）即时生效;
- 效果: 把“一刀切”的标准产品转为“千人千面”的个性化体验;
- 验证结论: 在 PostgreSQL 之上提供对象存储中间层（数据类型声明权限规则、访问上下文、校验器、对象关系与后果反应），合法流程更新成功，而跳过状态转换、写入越界数据、跨租户读取均被数据层拒绝;
- 定位: 这是元能力中“生成式 UI”的延伸——生成范围从界面扩展到软件本身;