- 博客(18)
- 资源 (15)
- 收藏
- 关注
RSS订阅原创 AI 审计证据之六：没人读过的记录，只能算存着
一条AI审计记录闲置一年，暴露出“记录被写”不等于“被人读”的核心问题。本文提出可验证复核的三条判据：指名复核人与频度、回执上链可验、未复核区间标为unknown。唯有三者俱全，才能确保“已复核”真实可证。否则，复核仅是空壳，审计证据便形同虚设。
2026-11-09 08:30:56
194
原创 AI 执行治理之十：撤权能不能中止一个已经在跑的调用
工具调用一旦通过门控开始执行，即使角色被撤权，仍会跑完。因为撤权仅影响下一次调用，不中断当前执行。门控在调用前四次复查中生效，但执行后不再检查。当前系统无取消信号、无超时机制，缺乏中止能力。若需真正中止，须补取消契约或设置执行窗口上限。结论：撤权≠取消，系统只能记录“已执行”，无法强制停止。
2026-11-04 08:33:13
220
原创 AI 执行治理之九：撤销完成是一个结论，不是一个状态位
“撤销完成”是三个断言的合成结论：补偿发生、目标回滚、外部确认。将其简化为布尔值会掩盖“未知”状态，导致系统在超时或失败时误判。正确做法是采用三值判定（compensating/unknown, restored, not_restored），保留“未知”以避免谎言。通过“声明vs持有”差集机制，可反推结论是否成立，确保“已撤销”徽章仅在证据充分时显示。该设计源自KeelBase，强调结论需可验证、可推翻，而非仅依赖字段对齐。
2026-11-02 08:53:57
157
原创 AI 审计证据之五：五个来源打进一个文件，不等于它们互相印证
本文探讨了“交叉验证”的真正含义：同一结论需由两条互不依赖的路径独立得出，且系统能在运行期自动检测不一致。作者指出，将多个来源打包并签名仅保证完整性，不等于交叉验证。实践中，仅有“撤销”一处满足完整交叉条件，其余或仅为半验证或无验证。文中强调，真正的交叉验证需在运行时比对、自动识别冲突，并以独立数据源为基础。最后反思自身模型缺陷——曾遗漏“无记录”情形，后经外部质疑补入L0层，印证了“不同问法带来不同答案”的重要性。
2026-10-30 08:53:56
19
原创 AI 执行治理之八：工具注册表里没有的动作，谁来负责？
治理的核心不是“注册表里有什么”，而是“哪些入口路径经过验证”。同一张events表的两条记录，因入口不同而命运迥异：前者受门控与副作用账约束，后者绕过所有治理。关键在于区分“动作目录”（我们想管什么）与“执行入口”（动作从哪来）。注册表是静态集合，入口清单才是动态边界。真正的治理应交付一张未验证入口清单，而非虚高的覆盖率。代码中可选执行器、双份目录、缺失机制等漏洞，暴露了“已声明”不等于“已覆盖”的风险。结论：必须分清入口、执行、证据、范围四件事，以清单替代覆盖率，才能实现可信治理。
2026-10-28 08:37:14
221
原创 AI 审计证据之四：一条 AI 审计记录，究竟能证明什么？
一份审计记录仅能证明部分事实：哈希链校验通过，仅确保记录未被篡改（第二层），但无法自动推导出执行内容、覆盖范围或外部结果。真实记录可能缺失关键字段（如工具名、变更前状态），导致语义不可解释。五层证据模型揭示：事件发生、来源完整、执行关联、覆盖验证与结果核实需独立证明，缺一不可。加签名不等于有覆盖，有快照不等于结果已核实。真正的可信，源于对每一层的明确界定与可反驳的验证，而非表面完整。
2026-10-26 08:55:22
154
原创 AI 审计证据之三：审计员不是管理员
本文阐述如何构建一个安全的只读审计角色，避免赋予管理员权限带来的风险。通过五条显式read规则定义可达面，字段从白名单重建确保新列默认不可见，行范围基于账号而非请求，聚合与缓存携带范围信息，签名证据保持完整不可投影。审计读者可读日志、策略等，但不可写、不可审批、不可成为被复核者。强调“可达面可逐项列出”才是真只读，避免“弱化admin”的误区，实现可验证、可审计、可信赖的治理闭环。
2026-10-23 08:56:34
123
原创 AI 审计证据之二：沉默会被读成完整
本文提出，哈希链仅能证明证据包内部一致性，无法保证完整性。为此，建议为每份证据包附带可机读的“覆盖声明”，明确说明其读取范围与未覆盖的缺口，且该声明需与证据包一同签名。声明基于稳定登记表，由系统自动计算，确保不漂移；结论依规则算出，避免“unknown”被降级为“partial”。关键在于：沉默即完整，而诚实的审计应主动揭示局限——只声明已核实的缺口，不添加未经验证的推测。最终，覆盖声明是审计可信性的基石，而非装饰。
2026-10-21 09:17:50
156
原创 AI 执行治理之七：一个超时回答不了两个问题
本文剖析了AI请求确认机制中“过期”逻辑的双重误用：对话等待与数据裁决的超时被混为一谈，导致界面显示与实际状态不一致。作者提出两大改进：拆分两个独立窗口（60秒对话等待、24小时离线待办），每窗口仅由单一函数计算边界；所有裁决入口通过数据库条件更新实现原子仲裁，确保“至多一次裁决”。 同时强调：落库失败必须拒绝放行，避免将“未知”误解为“同意”。最终，系统只承诺“至多一次裁决”，而非“至多一次执行”，并以清晰设计保障一致性与安全性。
2026-10-19 08:42:35
247
原创 AI 执行治理之六：唯一约束护的是账，不是动作
本文探讨如何实现接口调用的幂等性，核心是避免重复写入。关键在于“执行前占位”而非“查后执行”，通过原子占位确保并发下仅一次执行。幂等键由“谁、对话、工具、排序参数”构成，确保同一调用唯一。失败时分本地与外部处理：本地可重试，外部则保留占位以防双写。重复请求返回历史结果，实现“回放”。但需明确：系统仅保证自身不重复，无法控制目标系统是否去重；且前提是参数能完整表达操作语义。
2026-10-15 09:23:54
318
原创 AI 执行治理之五：人工确认不能只是一个布尔值
用户点击「同意」后，系统应记录的不仅是布尔值，而是一份包含精确参数、目的地、可写字段域、有效窗口及操作者与决策时刻的完整凭证。若仅存布尔值，将导致请求可复用、执行时参数漂移、权限模糊、时效不可查等问题。通过绑定五要素，确保“同意”真正成为可审计、可撤销、不可漂移的信任锚点。任何“签发时算一次、执行时再算一次”的字段，皆为风险点。最终，信任不靠复杂凭据堆叠，而靠精准绑定与合理取舍。
2026-10-12 08:48:56
254
原创 AI 审计证据之一：记录里没有「不知道」，空值就会替你说「一切正常」
本文讲述系统设计中“没有”与“不知道”混用的隐性缺陷：当空值、空集合或默认值被统一解读为“正常”，实则掩盖了“未查”“未知”等不同含义，导致信息误读。作者以两次修复为例，揭示同一类问题在看似已解决处反复出现——因“空”同时承载多种语义，读作最强断言。关键在于为“未知”留格子，避免静默误导。建议自查所有“空”字段，判断其是否可明确解释“为何为空”。此类问题不报错，却最易在修复后重现，需持续警惕。
2026-10-08 09:00:10
152
原创 AI 执行治理之四：边界生效之前，先问它圈住了哪些动作
本文核心在于澄清AI安全边界的本质：边界并非靠强化规则构建，而是基于可枚举的动作清单。只有具备“名字、参数、风险级”的离散动作（如工具调用）才能被有效监控与管控；而无名、无结构的非离散动作（如屏幕点击、命令行操作）因缺乏挂载点，无法纳入治理范围。因此，真正的安全起点是能否穷尽列出agent的所有动作——清单之外，边界即不存在。
2026-10-02 21:35:59
160
原创 AI 执行治理之三：撤销不是一个按钮
本文探讨AI操作撤销机制的可信设计，强调撤销不仅是按钮，更是契约。指出当前系统在异步副作用、外部补偿、批量撤销与分页等方面存在局限，核心问题在于“假撤销”——看似成功实则数据残留，比完全不撤销更危险。提出按档位分类撤销能力（如none、local_compensate、governed_external），确保状态诚实：外部系统仅能标记为“已请求”，不可宣称“已撤销”。通过补偿组机制保证原子性，避免部分撤销；撤销动作全程留痕，支持审计追溯。最终强调：可撤销≠可恢复，信任源于对“撤不干净”与“撤不回来”的诚实
2026-09-24 08:49:52
339
原创 AI 执行治理之二：AI 写数据先分级，R0–R5 工具风险模型
本文提出AI工具风险分级机制（R0-R5），将“写”操作与“读”操作区别对待，通过执行前策略门控实现安全边界下放。低风险自动执行，敏感操作需确认，高风险直接阻断，未声明工具按保守规则处理。结合KeelBase开源实现，验证了分级在运行时的强制力：权限检查、策略门控、人工确认、审计留痕、可撤销副作用，确保不可逆操作无法绕过。强调真正的安全边界不在Prompt层，而在执行路径上，唯有可验证的规则才能让企业放心将AI从“助手”升级为“执行者”。
2026-09-20 08:59:22
341
原创 AI 执行治理之一：System Prompt 不是安全边界
本文指出，仅依赖System Prompt无法构成真正安全边界。AI Agent调用API时，Prompt仅为指令，易受注入攻击或理解偏差影响。真正的安全应置于执行路径的Runtime Gate——在API调用前独立校验身份、权限、范围与确认状态，实现“能不能做”而非“模型说不做”。作者开源工具KeelBase验证了越权请求能否被拦截，强调安全需可复现、可攻破测试。Prompt指导行为，Runtime控制执行，二者分层协作。安全边界必须落在真实执行前，否则规则形同虚设。
2026-09-17 10:05:20
222
原创 P55a双机热备ＨＡ切换后建立在ｒａｗ设备上的数据库表空间不可用问题。
基金代销系统硬件使用的是ＩＢＭp55a 阵列用的是IBM DS4700 双击热备 近日对系统的例行检查中，进行HA切换测试时发现：当系统切换至备机时，与数据库相关应用不能启动，数据库启动正常，但是建立在ｒａｗ设备上的数据库表空间不可用。切换回主机也是同样问题。经过多方请教发现问题原因如下： 应用系统安装时为应用新增的数据库表空间新建了LV，但是只修改
2008-05-22 11:35:00
992
原创 使用DB2中需要注意的一个问题。
随着年初新基金代销系统的上线，系统使用的数据库也变更为DB2。在使用和维护DB2的过程中发现了一个问题需要注意. 在DB2实例用户的系统空间满了的情况下，DB2无法写入日志，导致的结果是，你不得不restore一份最近的备份，然后根据系统日志找回备份到DB2停止工作前的数据，这一点很危险。不像以前用Oracle，系统空间满了清理一下空间，然后重启数据库就OK了。
2008-05-20 10:20:00
500
XenCenter7.3.zip
2020-02-11
aptoide-latest.zip
2020-02-11
jBPM4中文开发指南
2009-12-24
信息系统规划方法和案例分析
2009-12-24
mootools1.11中文文档
2007-09-24
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人