约束工程Logic Firewall为 Agent 打造确定性安全层的完整实战指南【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit导读本文围绕 agent-governance-toolkit 仓库中agent-governance-python/agent-os/examples/self-evaluating示例的约束工程Constraint Engineering模块展开深入讲解逻辑防火墙Logic Firewall这一确定性安全层它如何拦截 LLM 生成的行动计划、在执行前完成 SQL 注入防护、文件系统保护、成本限额、邮箱域名白名单与速率限制等校验以及如何与自进化 AgentDoerAgent集成、编写自定义规则并通过测试验证。读完本文你将掌握一套不依赖提示词运气的、代码级可验证的 Agent 安全护栏实现方案。为什么纯提示词工程不够约束工程的问题背景原文档开篇直指一个尖锐的现实传统做法是试图找到完美的魔法咒语来告诉 AI 不要删除数据库——这被称为提示词工程Prompt Engineering。而实际运行中它面临四个致命缺陷提示词是脆弱的Prompting is fragile一次越狱jailbreak可以在几秒内绕过你精心撰写的礼貌指令我们无法依赖 AI 的自我控制来保证安全一个错误的 token 就可能让生产数据库灰飞烟灭。约束工程Constraint Engineering给出的答案是与其祈祷 AI 行为端正不如在 AI 与基础设施之间构建一层确定性的安全层。这层安全层在仓库中被实现为constraint_engine.py模块其文件头部注释直接记录了这条核心原则Never let the AI touch the infrastructure directly. The Human builds the walls; the AI plays inside them.架构Brain / Firewall / Hand 三段式 Agent 流程逻辑防火墙位于 AI Agent 流程的正中间原文档给出了如下架构1. Brain (LLM) → 生成 Plan例如 I will query the DB and email the user 2. Firewall (约束引擎) → 确定性 Python 代码逐项校验 ├─ Check: DROP TABLE in SQL? ├─ Check: User allowed to email this domain? ├─ Check: Cost of action $0.05? └─ Decision: APPROVE or BLOCK 3. Hand (Executor) → 仅在获批后执行这套三段式结构的每一层都有明确分工对应源码中的模块定位见 constraint_engine.py 模块 docstringBrainLLM创造性、高温度负责生成计划Firewall约束引擎确定性、严格负责校验计划——这是本文的主角Hand执行器机械执行只执行获批的计划。三条关键原则关注点分离Separation of ConcernsBrain 负责创造、Firewall 负责校验、Hand 负责执行三者互不混淆永不信任 AINever Trust the AIAI 绝不应直接接触数据库操作、文件系统操作、网络操作、支付系统与用户数据人筑高墙Human-Built Walls约束由人用代码定义AI 无法与if语句争辩。原文档用一句话总结The Human builds the walls; the AI plays inside them.人筑墙AI 在墙内玩耍。核心组件源码级剖析约束引擎的核心实现位于 constraint_engine.py约 440 行由以下关键类构成1. ViolationSeverity违规严重度枚举源码 constraint_engine.py#L26-L31 定义了四个等级级别含义典型示例处置策略CRITICAL即时危险DROP TABLE阻止执行HIGH严重风险删除系统文件阻止执行MEDIUM策略违规发送到错误邮箱域名记录违规原文档描述为 Block实现中不阻断LOW警告接近成本上限允许但告警注意一个实现细节在 ConstraintResult.get_blocking_violations() 中只有CRITICAL与HIGH会被视为阻断性违规blocking violationsMEDIUM/LOW仅记录但不阻断——这正是并非所有违规都同等重要这一设计哲学的代码体现。2. ConstraintViolation违规详情数据类constraint_engine.py#L34-L41 定义了违规的完整信息结构rule_name触发了哪条规则severity严重度等级message人类可读的描述blocked_action被阻止的具体动作suggested_fix修复建议可选。3. ConstraintRule规则基类所有规则继承自 ConstraintRule每个规则只负责校验安全的一个方面。子类必须实现validate(plan)方法接收包含action_type与action_data的字典返回违规列表空列表表示通过。4. ConstraintEngine防火墙本体ConstraintEngine 是编排所有规则的守门人默认规则集不传rules时自动装载SQLInjectionRule、FileOperationRule、CostLimitRule、EmailDomainRule、RateLimitRule五条内置规则动态管理add_rule()追加规则、remove_rule(rule_name)按名称移除规则validate_plan(plan, verbose)串行执行所有规则汇总违规verboseTrue时打印详细的校验过程与结论✅ FIREWALL: Plan APPROVED/ FIREWALL: Plan BLOCKEDintercept_and_validate(plan, execute_fn, verbose)拦截—校验—执行的完整链路获批后才调用execute_fn(plan)返回(executed, result, constraint_result)三元组。5. create_default_engine一键创建默认防火墙create_default_engine(max_cost0.05, allowed_domainsNone) 以合理默认值快速构建引擎默认单动作成本上限 0.05 美元、默认邮箱白名单[example.com, company.com, trusted-partner.com]、默认速率限制 10 次/分钟。内置安全规则详解规则一SQL 注入防护SQLInjectionRule源码 constraint_engine.py#L82-L121 使用正则对sql_query类型计划中的query做确定性匹配命中即产生CRITICAL违规。完整模式清单模式拦截目标\bDROP\sTABLE\b删表\bDROP\sDATABASE\b删库\bDELETE\sFROM\b.*\bWHERE\s1\s*\s*1\b无条件全表删除\bTRUNCATE\sTABLE\b清空表\bALTER\sTABLE\b.*\bDROP\b删列;\s*DROP\b/;\s*DELETE\b分号命令链注入/\*.*?\*/SQL 块注释绕过放行参数化SELECT查询如SELECT * FROM users WHERE id ?、带合理条件的INSERT/UPDATE。规则二文件操作安全FileOperationRule源码 constraint_engine.py#L124-L184 双通道防护危险命令模式命中即CRITICALrm -rf /、rm -rf *、Windows 的del /s /q *、format C:、dd if... of/dev/...受保护路径前缀命中即HIGH/etc、/sys、/boot、/bin、/sbin、C:\Windows、C:\System32。放行用户目录下的安全读写与常规操作如rm temp.txt且路径为/home/user/temp.txt。规则三成本限额CostLimitRule源码 constraint_engine.py#L187-L220 依据计划中的estimated_cost判定超过max_cost_per_action默认$0.05→HIGH阻断超过上限的 80%即$0.04但未超限 →LOW警告接近成本上限建议优化操作以降低成本。规则四邮箱域名限制EmailDomainRule源码 constraint_engine.py#L223-L261 解析收件人邮箱的后域名不在白名单中即产生MEDIUM违规并在suggested_fix中列出全部允许域名。规则五速率限制RateLimitRule源码 constraint_engine.py#L264-L290 默认限速 10 次/分钟。值得注意该 POC 版本通过计划中的current_rate字段演示概念源码注释明确说明真实实现应基于时间窗口追踪动作频率读者在生产落地时需要替换为基于时间窗的计数实现。实战用法基本用法拦截一个危险计划from constraint_engine import create_default_engine # 用合理默认值创建防火墙 engine create_default_engine( max_cost0.05, allowed_domains[example.com, company.com] ) # AI 生成计划可能是危险的 ai_plan { action_type: sql_query, action_data: { query: DROP TABLE users # 危险 } } # 防火墙拦截并校验 result engine.validate_plan(ai_plan, verboseTrue) if result.approved: execute_action(ai_plan) else: print( Blocked by firewall!) for violation in result.violations: print(f - {violation.message})verboseTrue时引擎会打印每次违规的规则名、严重度与消息并以FIREWALL: Plan BLOCKED结尾便于调试与审计。拦截并执行intercept_and_validate如果不希望自己写if/else分支可以直接使用引擎内置的完整链路方法def real_executor(plan): # 真正的执行逻辑仅在获批后被调用 return {status: ok, plan: plan} executed, result, constraint_result engine.intercept_and_validate( ai_plan, execute_fnreal_executor, verboseTrue ) # executedFalse 且 resultNone 表示被防火墙拦截与 DoerAgent 集成接入自进化 Agent约束引擎已经深度集成进框架的 agent.py构造函数新增enable_constraint_engine默认False与constraint_engine_config两个参数agent.py#L195-L196初始化时通过create_default_engine(**constraint_engine_config)构建防火墙并捕获导入异常做优雅降级agent.py#L275-L291新增validate_action_plan(plan, verbose)方法返回(approved, reason)二元组未开启时直接放行拦截时把所有阻断性违规的 message 用分号拼接为reasonagent.py#L306-L332。集成示例from agent import DoerAgent # 启用约束引擎 doer DoerAgent( enable_constraint_engineTrue, constraint_engine_config{ max_cost: 0.05, allowed_domains: [example.com, company.com] } ) # 执行前校验动作计划 plan { action_type: sql_query, action_data: {query: SELECT * FROM users WHERE id ?} } approved, reason doer.validate_action_plan(plan, verboseTrue) if approved: result execute(plan) # 安全执行 else: print(fBlocked: {reason})自定义规则为你的业务领域加一道闸框架的可扩展性让新领域规则的添加极其简单。以文档中的支付限额规则为例from constraint_engine import ConstraintRule, ConstraintViolation, ViolationSeverity class PaymentLimitRule(ConstraintRule): def __init__(self, max_amount: float 100.0): super().__init__(payment_limit, Limits payment amounts) self.max_amount max_amount def validate(self, plan): if plan.get(action_type) payment: amount plan.get(action_data, {}).get(amount, 0) if amount self.max_amount: return [ConstraintViolation( rule_nameself.name, severityViolationSeverity.HIGH, messagefPayment ${amount} exceeds limit ${self.max_amount}, blocked_actionfPayment of ${amount} )] return [] # 加入引擎 engine ConstraintEngine() engine.add_rule(PaymentLimitRule(max_amount100.0))测试套件中的 CustomAPIRule 是另一个完整范例它拦截forbidden_api调用并放行其他 API验证了自定义规则 独立引擎的完整工作流。关键收益1. 放心使用创造性 AI原文档给出的核心洞察是防火墙存在后温度参数不再是安全与否的赌注。# 旧世界低温度避免犯错无聊 model_temperature 0.1 # 新世界高温度激发创造力安全 model_temperature 0.9 # 防火墙用确定性逻辑兜底示例程序 example_constraint_engineering.py 的第 6 个演示demo_creative_ai_with_firewall专门展示了这一场景让有创意的 AI 生成多个计划含安全的SELECT * FROM users、危险的DROP TABLE old_logs、正常的邮件发送防火墙逐个裁决最终得出AI 负责创意、防火墙负责安全的结论。2. 纵深防御Defense in DepthSQL 注入模式、文件路径限制、成本限额、域名白名单、速率限制构成多层验证任何单层被绕过仍有其他层兜底。3. 可审计性Auditability每次被阻止的动作都可记录for violation in result.violations: logger.warning(fSecurity violation: {violation.message}) logger.warning(fBlocked action: {violation.blocked_action})4. 可扩展性Extensibility可扩展方向包括PII 检测、合规检查GDPR、HIPAA、业务逻辑校验、自定义安全策略等。测试验证8/8 全部通过完整测试套件位于 test_constraint_engineering.py原文档写法为tests/test_constraint_engineering.py仓库实际路径见链接运行方式python agent-governance-python/agent-os/examples/self-evaluating/tests/test_constraint_engineering.py8 组测试覆盖SQL 注入防护拦截DROP TABLE、分号注入、DELETE ... WHERE 11放行参数化SELECT文件操作安全拦截rm -rf /CRITICAL、保护/etcHIGH放行用户目录操作成本限额$0.10超限被 HIGH 阻断、$0.045触发 LOW 警告、$0.01放行邮箱域名限制untrusted.com被 MEDIUM 拦截example.com/company.com放行速率限制15 次/分超限被拦截5 次/分放行引擎集成多规则协同、一次检测出多条违规如DROP DATABASE同时超成本拦截执行链路安全计划被执行、危险计划不执行且不返回结果自定义规则CustomAPIRule拦截forbidden_api。验证实现总结文档 IMPLEMENTATION_SUMMARY_CONSTRAINT_ENGINEERING.md 记录了最终测试结果Total Tests: 8Passed: 8Failed: 0全部通过。运行演示python agent-governance-python/agent-os/examples/self-evaluating/examples/example_constraint_engineering.py该脚本按回车逐段演示 6 个场景危险 SQL 被拦截、危险文件操作被拦截、成本限额生效、邮箱域名受限、安全操作放行、创造性 AI 防火墙。架构哲学与未来增强原文档将这套方法论的哲学内核归结为两条格言Never let the AI touch the infrastructure directly.永远不要让 AI 直接触碰基础设施。 The Human builds the walls; the AI plays inside them.人筑墙AI 在墙内玩耍。它之所以重要原因在于提示词工程是脆弱的一次越狱就能绕过指令约束工程是确定性的Python 代码不会与人讨价还价信任但要验证大胆使用强大的 AI但用代码验证安全内建于架构把安全建进架构而非提示词。原文档列出的未来增强方向CONSTRAINT_ENGINEERING.md包括PII 检测、合规规则GDPR/HIPAA/SOC2、业务逻辑校验、基于 ML 的异常检测、策略即代码Policy as Code将策略写入配置文件、被阻止动作的实时监控看板、自适应阈值学习等。总结约束引擎Logic Firewall是一个确定性的安全层它✅ 在执行前阻止危险操作SQL、文件、成本、域名、速率✅ 让创造性/高温度的 AI 模型得以安全使用✅ 提供审计日志与完整记录✅ 支持自定义规则自由扩展✅ 把安全提升为一等架构关切而非提示词附属品。记住那句话The Human builds the walls; the AI plays inside them.人筑墙AI 在墙内玩耍。【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 约束工程（Logic Firewall）：为 Agent 打造确定性安全层的完整实战指南
约束工程Logic Firewall为 Agent 打造确定性安全层的完整实战指南【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit导读本文围绕 agent-governance-toolkit 仓库中agent-governance-python/agent-os/examples/self-evaluating示例的约束工程Constraint Engineering模块展开深入讲解逻辑防火墙Logic Firewall这一确定性安全层它如何拦截 LLM 生成的行动计划、在执行前完成 SQL 注入防护、文件系统保护、成本限额、邮箱域名白名单与速率限制等校验以及如何与自进化 AgentDoerAgent集成、编写自定义规则并通过测试验证。读完本文你将掌握一套不依赖提示词运气的、代码级可验证的 Agent 安全护栏实现方案。为什么纯提示词工程不够约束工程的问题背景原文档开篇直指一个尖锐的现实传统做法是试图找到完美的魔法咒语来告诉 AI 不要删除数据库——这被称为提示词工程Prompt Engineering。而实际运行中它面临四个致命缺陷提示词是脆弱的Prompting is fragile一次越狱jailbreak可以在几秒内绕过你精心撰写的礼貌指令我们无法依赖 AI 的自我控制来保证安全一个错误的 token 就可能让生产数据库灰飞烟灭。约束工程Constraint Engineering给出的答案是与其祈祷 AI 行为端正不如在 AI 与基础设施之间构建一层确定性的安全层。这层安全层在仓库中被实现为constraint_engine.py模块其文件头部注释直接记录了这条核心原则Never let the AI touch the infrastructure directly. The Human builds the walls; the AI plays inside them.架构Brain / Firewall / Hand 三段式 Agent 流程逻辑防火墙位于 AI Agent 流程的正中间原文档给出了如下架构1. Brain (LLM) → 生成 Plan例如 I will query the DB and email the user 2. Firewall (约束引擎) → 确定性 Python 代码逐项校验 ├─ Check: DROP TABLE in SQL? ├─ Check: User allowed to email this domain? ├─ Check: Cost of action $0.05? └─ Decision: APPROVE or BLOCK 3. Hand (Executor) → 仅在获批后执行这套三段式结构的每一层都有明确分工对应源码中的模块定位见 constraint_engine.py 模块 docstringBrainLLM创造性、高温度负责生成计划Firewall约束引擎确定性、严格负责校验计划——这是本文的主角Hand执行器机械执行只执行获批的计划。三条关键原则关注点分离Separation of ConcernsBrain 负责创造、Firewall 负责校验、Hand 负责执行三者互不混淆永不信任 AINever Trust the AIAI 绝不应直接接触数据库操作、文件系统操作、网络操作、支付系统与用户数据人筑高墙Human-Built Walls约束由人用代码定义AI 无法与if语句争辩。原文档用一句话总结The Human builds the walls; the AI plays inside them.人筑墙AI 在墙内玩耍。核心组件源码级剖析约束引擎的核心实现位于 constraint_engine.py约 440 行由以下关键类构成1. ViolationSeverity违规严重度枚举源码 constraint_engine.py#L26-L31 定义了四个等级级别含义典型示例处置策略CRITICAL即时危险DROP TABLE阻止执行HIGH严重风险删除系统文件阻止执行MEDIUM策略违规发送到错误邮箱域名记录违规原文档描述为 Block实现中不阻断LOW警告接近成本上限允许但告警注意一个实现细节在 ConstraintResult.get_blocking_violations() 中只有CRITICAL与HIGH会被视为阻断性违规blocking violationsMEDIUM/LOW仅记录但不阻断——这正是并非所有违规都同等重要这一设计哲学的代码体现。2. ConstraintViolation违规详情数据类constraint_engine.py#L34-L41 定义了违规的完整信息结构rule_name触发了哪条规则severity严重度等级message人类可读的描述blocked_action被阻止的具体动作suggested_fix修复建议可选。3. ConstraintRule规则基类所有规则继承自 ConstraintRule每个规则只负责校验安全的一个方面。子类必须实现validate(plan)方法接收包含action_type与action_data的字典返回违规列表空列表表示通过。4. ConstraintEngine防火墙本体ConstraintEngine 是编排所有规则的守门人默认规则集不传rules时自动装载SQLInjectionRule、FileOperationRule、CostLimitRule、EmailDomainRule、RateLimitRule五条内置规则动态管理add_rule()追加规则、remove_rule(rule_name)按名称移除规则validate_plan(plan, verbose)串行执行所有规则汇总违规verboseTrue时打印详细的校验过程与结论✅ FIREWALL: Plan APPROVED/ FIREWALL: Plan BLOCKEDintercept_and_validate(plan, execute_fn, verbose)拦截—校验—执行的完整链路获批后才调用execute_fn(plan)返回(executed, result, constraint_result)三元组。5. create_default_engine一键创建默认防火墙create_default_engine(max_cost0.05, allowed_domainsNone) 以合理默认值快速构建引擎默认单动作成本上限 0.05 美元、默认邮箱白名单[example.com, company.com, trusted-partner.com]、默认速率限制 10 次/分钟。内置安全规则详解规则一SQL 注入防护SQLInjectionRule源码 constraint_engine.py#L82-L121 使用正则对sql_query类型计划中的query做确定性匹配命中即产生CRITICAL违规。完整模式清单模式拦截目标\bDROP\sTABLE\b删表\bDROP\sDATABASE\b删库\bDELETE\sFROM\b.*\bWHERE\s1\s*\s*1\b无条件全表删除\bTRUNCATE\sTABLE\b清空表\bALTER\sTABLE\b.*\bDROP\b删列;\s*DROP\b/;\s*DELETE\b分号命令链注入/\*.*?\*/SQL 块注释绕过放行参数化SELECT查询如SELECT * FROM users WHERE id ?、带合理条件的INSERT/UPDATE。规则二文件操作安全FileOperationRule源码 constraint_engine.py#L124-L184 双通道防护危险命令模式命中即CRITICALrm -rf /、rm -rf *、Windows 的del /s /q *、format C:、dd if... of/dev/...受保护路径前缀命中即HIGH/etc、/sys、/boot、/bin、/sbin、C:\Windows、C:\System32。放行用户目录下的安全读写与常规操作如rm temp.txt且路径为/home/user/temp.txt。规则三成本限额CostLimitRule源码 constraint_engine.py#L187-L220 依据计划中的estimated_cost判定超过max_cost_per_action默认$0.05→HIGH阻断超过上限的 80%即$0.04但未超限 →LOW警告接近成本上限建议优化操作以降低成本。规则四邮箱域名限制EmailDomainRule源码 constraint_engine.py#L223-L261 解析收件人邮箱的后域名不在白名单中即产生MEDIUM违规并在suggested_fix中列出全部允许域名。规则五速率限制RateLimitRule源码 constraint_engine.py#L264-L290 默认限速 10 次/分钟。值得注意该 POC 版本通过计划中的current_rate字段演示概念源码注释明确说明真实实现应基于时间窗口追踪动作频率读者在生产落地时需要替换为基于时间窗的计数实现。实战用法基本用法拦截一个危险计划from constraint_engine import create_default_engine # 用合理默认值创建防火墙 engine create_default_engine( max_cost0.05, allowed_domains[example.com, company.com] ) # AI 生成计划可能是危险的 ai_plan { action_type: sql_query, action_data: { query: DROP TABLE users # 危险 } } # 防火墙拦截并校验 result engine.validate_plan(ai_plan, verboseTrue) if result.approved: execute_action(ai_plan) else: print( Blocked by firewall!) for violation in result.violations: print(f - {violation.message})verboseTrue时引擎会打印每次违规的规则名、严重度与消息并以FIREWALL: Plan BLOCKED结尾便于调试与审计。拦截并执行intercept_and_validate如果不希望自己写if/else分支可以直接使用引擎内置的完整链路方法def real_executor(plan): # 真正的执行逻辑仅在获批后被调用 return {status: ok, plan: plan} executed, result, constraint_result engine.intercept_and_validate( ai_plan, execute_fnreal_executor, verboseTrue ) # executedFalse 且 resultNone 表示被防火墙拦截与 DoerAgent 集成接入自进化 Agent约束引擎已经深度集成进框架的 agent.py构造函数新增enable_constraint_engine默认False与constraint_engine_config两个参数agent.py#L195-L196初始化时通过create_default_engine(**constraint_engine_config)构建防火墙并捕获导入异常做优雅降级agent.py#L275-L291新增validate_action_plan(plan, verbose)方法返回(approved, reason)二元组未开启时直接放行拦截时把所有阻断性违规的 message 用分号拼接为reasonagent.py#L306-L332。集成示例from agent import DoerAgent # 启用约束引擎 doer DoerAgent( enable_constraint_engineTrue, constraint_engine_config{ max_cost: 0.05, allowed_domains: [example.com, company.com] } ) # 执行前校验动作计划 plan { action_type: sql_query, action_data: {query: SELECT * FROM users WHERE id ?} } approved, reason doer.validate_action_plan(plan, verboseTrue) if approved: result execute(plan) # 安全执行 else: print(fBlocked: {reason})自定义规则为你的业务领域加一道闸框架的可扩展性让新领域规则的添加极其简单。以文档中的支付限额规则为例from constraint_engine import ConstraintRule, ConstraintViolation, ViolationSeverity class PaymentLimitRule(ConstraintRule): def __init__(self, max_amount: float 100.0): super().__init__(payment_limit, Limits payment amounts) self.max_amount max_amount def validate(self, plan): if plan.get(action_type) payment: amount plan.get(action_data, {}).get(amount, 0) if amount self.max_amount: return [ConstraintViolation( rule_nameself.name, severityViolationSeverity.HIGH, messagefPayment ${amount} exceeds limit ${self.max_amount}, blocked_actionfPayment of ${amount} )] return [] # 加入引擎 engine ConstraintEngine() engine.add_rule(PaymentLimitRule(max_amount100.0))测试套件中的 CustomAPIRule 是另一个完整范例它拦截forbidden_api调用并放行其他 API验证了自定义规则 独立引擎的完整工作流。关键收益1. 放心使用创造性 AI原文档给出的核心洞察是防火墙存在后温度参数不再是安全与否的赌注。# 旧世界低温度避免犯错无聊 model_temperature 0.1 # 新世界高温度激发创造力安全 model_temperature 0.9 # 防火墙用确定性逻辑兜底示例程序 example_constraint_engineering.py 的第 6 个演示demo_creative_ai_with_firewall专门展示了这一场景让有创意的 AI 生成多个计划含安全的SELECT * FROM users、危险的DROP TABLE old_logs、正常的邮件发送防火墙逐个裁决最终得出AI 负责创意、防火墙负责安全的结论。2. 纵深防御Defense in DepthSQL 注入模式、文件路径限制、成本限额、域名白名单、速率限制构成多层验证任何单层被绕过仍有其他层兜底。3. 可审计性Auditability每次被阻止的动作都可记录for violation in result.violations: logger.warning(fSecurity violation: {violation.message}) logger.warning(fBlocked action: {violation.blocked_action})4. 可扩展性Extensibility可扩展方向包括PII 检测、合规检查GDPR、HIPAA、业务逻辑校验、自定义安全策略等。测试验证8/8 全部通过完整测试套件位于 test_constraint_engineering.py原文档写法为tests/test_constraint_engineering.py仓库实际路径见链接运行方式python agent-governance-python/agent-os/examples/self-evaluating/tests/test_constraint_engineering.py8 组测试覆盖SQL 注入防护拦截DROP TABLE、分号注入、DELETE ... WHERE 11放行参数化SELECT文件操作安全拦截rm -rf /CRITICAL、保护/etcHIGH放行用户目录操作成本限额$0.10超限被 HIGH 阻断、$0.045触发 LOW 警告、$0.01放行邮箱域名限制untrusted.com被 MEDIUM 拦截example.com/company.com放行速率限制15 次/分超限被拦截5 次/分放行引擎集成多规则协同、一次检测出多条违规如DROP DATABASE同时超成本拦截执行链路安全计划被执行、危险计划不执行且不返回结果自定义规则CustomAPIRule拦截forbidden_api。验证实现总结文档 IMPLEMENTATION_SUMMARY_CONSTRAINT_ENGINEERING.md 记录了最终测试结果Total Tests: 8Passed: 8Failed: 0全部通过。运行演示python agent-governance-python/agent-os/examples/self-evaluating/examples/example_constraint_engineering.py该脚本按回车逐段演示 6 个场景危险 SQL 被拦截、危险文件操作被拦截、成本限额生效、邮箱域名受限、安全操作放行、创造性 AI 防火墙。架构哲学与未来增强原文档将这套方法论的哲学内核归结为两条格言Never let the AI touch the infrastructure directly.永远不要让 AI 直接触碰基础设施。 The Human builds the walls; the AI plays inside them.人筑墙AI 在墙内玩耍。它之所以重要原因在于提示词工程是脆弱的一次越狱就能绕过指令约束工程是确定性的Python 代码不会与人讨价还价信任但要验证大胆使用强大的 AI但用代码验证安全内建于架构把安全建进架构而非提示词。原文档列出的未来增强方向CONSTRAINT_ENGINEERING.md包括PII 检测、合规规则GDPR/HIPAA/SOC2、业务逻辑校验、基于 ML 的异常检测、策略即代码Policy as Code将策略写入配置文件、被阻止动作的实时监控看板、自适应阈值学习等。总结约束引擎Logic Firewall是一个确定性的安全层它✅ 在执行前阻止危险操作SQL、文件、成本、域名、速率✅ 让创造性/高温度的 AI 模型得以安全使用✅ 提供审计日志与完整记录✅ 支持自定义规则自由扩展✅ 把安全提升为一等架构关切而非提示词附属品。记住那句话The Human builds the walls; the AI plays inside them.人筑墙AI 在墙内玩耍。【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考