Agent OS 与 OWASP Agentic Top 10原生 ACS 策略与宿主安全控制的治理映射实战【免费下载链接】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 OS 的 OWASP Agentic Top 10 映射文档 展开完整讲解 Agent OS 如何通过原生 ACSAgent Control Specification策略评估与宿主生命周期控制逐项覆盖 OWASP Agentic Top 10 的十大风险面。读完本文你将掌握 ASI01ASI10 每项风险对应的控制面、AgentControl/HostSession原生策略示例的用法、SandboxConfig等宿主控制的职责边界以及策略评估不能替代宿主安全的 fail-closed 设计原则与验证手段。一、映射总览一份风险一张控制表OWASP Agentic Top 10 是面向智能体应用Agentic Application的十大安全风险清单。Agent OS 的治理思路是将 ACS 原生策略评估与宿主生命周期控制组合使用——前者在每一次 agent 动作输入、模型调用、工具调用、输出发生前做确定性裁决后者负责身份、沙箱、可靠性等执行环境层面的兜底。下面这张表就是官方映射的核心它标出了每项风险对应的主控制面Primary controlsRiskPrimary controlsASI01 Agent Goal HijackInput and output policies, prompt-injection detection, auditASI02 Tool MisuseManifest tool catalog,pre_tool_call, sandbox controlsASI03 Identity and Privilege AbuseAgentMesh identity, capability checks, approvalASI04 Agentic Supply ChainTool identity, signatures, provenance, package controlsASI05 Unexpected Code ExecutionSandbox providers, code scanning, tool policyASI06 Memory and Context PoisoningContext validation, memory integrity, input policyASI07 Insecure Inter-Agent CommunicationAgentMesh trust and encrypted transportASI08 Cascading FailuresCircuit breakers, SLOs, rate limits, session budgetsASI09 Human-Agent Trust ExploitationApproval binding, evidence, restricted auditASI10 Rogue AgentsIdentity, runtime mediation, sandbox isolation, kill controls在 Agent OS README 的覆盖矩阵 中这 10 项风险被标注为全部覆盖例如 ASI01 对应AgentControl.blocked_patterns、ASI02 对应MCPGateway的工具过滤/限流/审计、ASI03 对应require_human_approval与 RBAC、ASI06 对应MemoryGuard的哈希完整性与注入检测、ASI10 对应运行时 kill switch 与环形隔离。注意映射文档明确声明这是架构性指引architectural guidance而非认证声明部署方必须根据自己的威胁模型验证所需控制项。二、原生 ACS 策略示例拦截一次工具调用映射文档给出了最核心的代码骨架——使用 ACSAgent Control Specification运行时直接对一次工具调用做策略评估from agent_control_specification import AgentControl, HostSession runtime AgentControl.from_path(policies/owasp-manifest.yaml) session HostSession( runtime, agent_idowasp-agent, session_idowasp-session, ) evaluation session.pre_tool_call( tool_nameexecute_code, args{code: untrusted input}, )这段代码的含义AgentControl.from_path(...)从policies/owasp-manifest.yaml加载 ACS 清单manifest构建策略运行时HostSession(runtime, agent_id..., session_id...)在宿主会话中绑定该运行时与一次 agent 会话的标识session.pre_tool_call(tool_nameexecute_code, args{code: untrusted input})在工具真正执行前发起评估返回evaluation供宿主读取裁决结果。agent_control_specification是仓库中真实存在的契约模块在 原生适配器运行时测试 中可见其导出Verdict、Decision、InterventionPoint、InterventionPointResult、Transform、AgentControlBlocked等类型在 agt-policies 的迁移桥接 中也被直接调用from agent_control_specification import validate_manifest。干预点Intervention Points清单可以绑定的位置映射文档强调清单可以把策略绑定到输入input、模型model、工具tool与输出output干预点上。 从迁移桥接实现可见干预点的真实命名pre_model_call与pre_tool_call是策略表达式里input.intervention_point的取值。测试进一步证明了干预点的生效顺序test_adapter_enforcement.py 验证被拒绝的工具调用在pre_tool_call干预点就被拦截不会进入执行同一文件还验证每次工具调用在快照之后才计费因此第一次调用看到零计数——即预算扣减发生在策略评估之后test_adapter_mediation_contract.py 以契约测试的形式逐一列出各框架适配器必须实现的_bridge.evaluate_input(、_bridge.evaluate_pre_tool_call(、_bridge.evaluate_output(调用确保不同框架Anthropic、AutoGen、CrewAI、Gemini、Google ADK 等在相同的干预点上做中介mediation从而保证副作用顺序一致。原生 ACS 契约不止于 allow/deny映射文档指出工具目录tool catalogs、预算budgets、转换transforms、证据evidence与审批approval都是原生 ACS 契约。这意味着策略评估结果不是简单的布尔值而是一份结构化裁决。测试中的Verdict(decisionDecision.DENY, reasonneeds_sign_off, approval{required: True, resolver: human})表明一次需要审批的拒绝在裁决里表现为携带 approval 块的 deny适配层据此把操作路由到人类审批流程而非直接报错见 test_native_adapter_runtime.py 中对可提升 deny 路由到审批消息的断言。三、宿主控制策略评估不替代宿主安全映射文档用一节专门强调边界策略评估不替代宿主安全四类宿主控制各有其主SandboxConfig拥有网络network、文件系统filesystem、资源resource与提供者provider控制AgentMesh 拥有身份identity、信任trust与传输transportAgent SRE 拥有熔断器circuit breakers、SLO、混沌测试与事故响应incident responseAgent OS 适配器拥有框架生命周期排序framework lifecycle ordering与脱敏错误sanitized errors。SandboxConfig可配置的沙箱边界在 sandbox.py 的 SandboxConfig 定义 中可以看到这些控制项的真实字段blocked_modules导入时被拒绝、执行期间在sys.modules中被遮蔽的顶层模块名列表默认含subprocess等危险模块测试check_import(subprocess) is False可验证blocked_builtins在受限全局作用域中被替换为抛错桩的内置函数名allowed_pathscheck_file_access允许访问的文件系统根路径max_memory_mb/max_cpu_seconds资源上限提示——注意文档与注释都明确说明进程内沙箱不强制资源限制硬性保证需要 cgroups、Job Objects 或 rlimit 等 OS 级隔离shadow_sys_modules默认 True用陷阱代理替换sys.modules中的被禁条目封堵sys.modules[os].system(...)逃逸enforce_ast_validation默认 Trueexecute_code_sandboxed先跑validate_code做 AST 静态检查任何违规都拒绝执行fail-closed。这条设计对应 ASI05Unexpected Code Execution与 ASI10Rogue Agents的沙箱隔离控制面也是映射文档所说沙箱提供者测试用于隔离验证的实现底座。四、Fail-closed 行为意外的错误也必须拒绝操作映射文档的 fail-closed 原则可以概括为三句话意外的策略policy、分发器dispatcher或审批approval错误一律拒绝该操作面向外部的公开异常只暴露稳定的文本stable text受信任的审计代码则保留完整的结构化PolicyEvaluation。这一原则在异常体系与测试中都有直接对应。异常层级定义于 exceptions.pyPolicyError→PolicyViolationError/PolicyDeniedError/PolicyTimeoutError。测试断言了稳定文本与结构化信息的分离# test_native_adapter_runtime.py 中的行为验证 assert str(error) Request blocked by policy. # 对外稳定文本 assert error.evaluation_result is result.evaluation # 对内结构化结果 assert error.details[message] restricted detail # 细节进入审计 details也就是说同一个PolicyViolationError同时携带给外部看的脱敏文本与给审计代码看的结构化评估正好实现映射文档所说的公共异常暴露稳定文本受信任审计代码保留结构化PolicyEvaluation。这也对应 ASI09Human-Agent Trust Exploitation的restricted audit控制敏感细节不向调用方泄露但完整证据进入审计通道。五、验证手段四类测试各司其职映射文档给出了四条验证路径每一类都能在仓库中找到落点策略回放policy replay使用agt test做策略回放。该命令定义于 agent-compliance 的 policy_test.py用法为agt test policies/ fixtures/把预置 fixture 逐条回放到策略引擎比对期望裁决 vs 实际裁决并输出 mismatch 摘要——适合验证 OWASP 清单对已知攻击样例的拦截效果。适配器中介测试adapter mediation tests验证副作用顺序side-effect ordering。即上文提到的 test_adapter_mediation_contract.py以契约形式锁定每个框架适配器在 input / pre_tool_call / output 干预点上的中介行为。沙箱提供者测试sandbox provider tests验证隔离isolation。Agent OS 生态内的 agent-sandbox 测试目录 覆盖 Azure、Docker、Hyperlight、Nonosandbox、MXC 等提供者进程内沙箱的 test_sandbox.py 则验证导入拦截等静态与运行时防护。红队套件red-team suites覆盖跨层攻击场景cross-layer attack scenarios。仓库根目录的 tests/redteam 目录即为跨层红队测试的落点可用于模拟策略层 沙箱层 身份层联合攻击。六、使用前提与边界本文映射是架构性指引覆盖某项风险不等于已通过 XX 认证。部署时应以自身威胁模型为准逐项验证所依赖的控制项确实开启并生效。策略评估拦截的是经由适配器/内核通道的动作映射文档与 Agent OS README 的已知限制都提示应用层中间件无法拦截绕过它的直接 stdlib 调用如subprocess、open生产环境应叠加容器级隔离作为纵深防御。进程内沙箱的max_memory_mb/max_cpu_seconds是提示性字段硬性资源限制依赖 OS 级机制对不可信负载应改用沙箱提供者。掌握了映射表、ACS 原生示例、宿主控制边界与 fail-closed 语义你就可以对照 OWASP Agentic Top 10 逐项审查自己的 Agent 部署并用agt test与各类测试套件持续验证治理有效性。想继续深入可阅读 Agent OS 安全规格.agents/security.md的 schema 与严格/宽松/审计三种模板、策略模式文档 与 Agent OS 快速开始。【免费下载链接】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），仅供参考 Agent OS 与 OWASP Agentic Top 10：原生 ACS 策略与宿主安全控制的治理映射实战
Agent OS 与 OWASP Agentic Top 10原生 ACS 策略与宿主安全控制的治理映射实战【免费下载链接】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 OS 的 OWASP Agentic Top 10 映射文档 展开完整讲解 Agent OS 如何通过原生 ACSAgent Control Specification策略评估与宿主生命周期控制逐项覆盖 OWASP Agentic Top 10 的十大风险面。读完本文你将掌握 ASI01ASI10 每项风险对应的控制面、AgentControl/HostSession原生策略示例的用法、SandboxConfig等宿主控制的职责边界以及策略评估不能替代宿主安全的 fail-closed 设计原则与验证手段。一、映射总览一份风险一张控制表OWASP Agentic Top 10 是面向智能体应用Agentic Application的十大安全风险清单。Agent OS 的治理思路是将 ACS 原生策略评估与宿主生命周期控制组合使用——前者在每一次 agent 动作输入、模型调用、工具调用、输出发生前做确定性裁决后者负责身份、沙箱、可靠性等执行环境层面的兜底。下面这张表就是官方映射的核心它标出了每项风险对应的主控制面Primary controlsRiskPrimary controlsASI01 Agent Goal HijackInput and output policies, prompt-injection detection, auditASI02 Tool MisuseManifest tool catalog,pre_tool_call, sandbox controlsASI03 Identity and Privilege AbuseAgentMesh identity, capability checks, approvalASI04 Agentic Supply ChainTool identity, signatures, provenance, package controlsASI05 Unexpected Code ExecutionSandbox providers, code scanning, tool policyASI06 Memory and Context PoisoningContext validation, memory integrity, input policyASI07 Insecure Inter-Agent CommunicationAgentMesh trust and encrypted transportASI08 Cascading FailuresCircuit breakers, SLOs, rate limits, session budgetsASI09 Human-Agent Trust ExploitationApproval binding, evidence, restricted auditASI10 Rogue AgentsIdentity, runtime mediation, sandbox isolation, kill controls在 Agent OS README 的覆盖矩阵 中这 10 项风险被标注为全部覆盖例如 ASI01 对应AgentControl.blocked_patterns、ASI02 对应MCPGateway的工具过滤/限流/审计、ASI03 对应require_human_approval与 RBAC、ASI06 对应MemoryGuard的哈希完整性与注入检测、ASI10 对应运行时 kill switch 与环形隔离。注意映射文档明确声明这是架构性指引architectural guidance而非认证声明部署方必须根据自己的威胁模型验证所需控制项。二、原生 ACS 策略示例拦截一次工具调用映射文档给出了最核心的代码骨架——使用 ACSAgent Control Specification运行时直接对一次工具调用做策略评估from agent_control_specification import AgentControl, HostSession runtime AgentControl.from_path(policies/owasp-manifest.yaml) session HostSession( runtime, agent_idowasp-agent, session_idowasp-session, ) evaluation session.pre_tool_call( tool_nameexecute_code, args{code: untrusted input}, )这段代码的含义AgentControl.from_path(...)从policies/owasp-manifest.yaml加载 ACS 清单manifest构建策略运行时HostSession(runtime, agent_id..., session_id...)在宿主会话中绑定该运行时与一次 agent 会话的标识session.pre_tool_call(tool_nameexecute_code, args{code: untrusted input})在工具真正执行前发起评估返回evaluation供宿主读取裁决结果。agent_control_specification是仓库中真实存在的契约模块在 原生适配器运行时测试 中可见其导出Verdict、Decision、InterventionPoint、InterventionPointResult、Transform、AgentControlBlocked等类型在 agt-policies 的迁移桥接 中也被直接调用from agent_control_specification import validate_manifest。干预点Intervention Points清单可以绑定的位置映射文档强调清单可以把策略绑定到输入input、模型model、工具tool与输出output干预点上。 从迁移桥接实现可见干预点的真实命名pre_model_call与pre_tool_call是策略表达式里input.intervention_point的取值。测试进一步证明了干预点的生效顺序test_adapter_enforcement.py 验证被拒绝的工具调用在pre_tool_call干预点就被拦截不会进入执行同一文件还验证每次工具调用在快照之后才计费因此第一次调用看到零计数——即预算扣减发生在策略评估之后test_adapter_mediation_contract.py 以契约测试的形式逐一列出各框架适配器必须实现的_bridge.evaluate_input(、_bridge.evaluate_pre_tool_call(、_bridge.evaluate_output(调用确保不同框架Anthropic、AutoGen、CrewAI、Gemini、Google ADK 等在相同的干预点上做中介mediation从而保证副作用顺序一致。原生 ACS 契约不止于 allow/deny映射文档指出工具目录tool catalogs、预算budgets、转换transforms、证据evidence与审批approval都是原生 ACS 契约。这意味着策略评估结果不是简单的布尔值而是一份结构化裁决。测试中的Verdict(decisionDecision.DENY, reasonneeds_sign_off, approval{required: True, resolver: human})表明一次需要审批的拒绝在裁决里表现为携带 approval 块的 deny适配层据此把操作路由到人类审批流程而非直接报错见 test_native_adapter_runtime.py 中对可提升 deny 路由到审批消息的断言。三、宿主控制策略评估不替代宿主安全映射文档用一节专门强调边界策略评估不替代宿主安全四类宿主控制各有其主SandboxConfig拥有网络network、文件系统filesystem、资源resource与提供者provider控制AgentMesh 拥有身份identity、信任trust与传输transportAgent SRE 拥有熔断器circuit breakers、SLO、混沌测试与事故响应incident responseAgent OS 适配器拥有框架生命周期排序framework lifecycle ordering与脱敏错误sanitized errors。SandboxConfig可配置的沙箱边界在 sandbox.py 的 SandboxConfig 定义 中可以看到这些控制项的真实字段blocked_modules导入时被拒绝、执行期间在sys.modules中被遮蔽的顶层模块名列表默认含subprocess等危险模块测试check_import(subprocess) is False可验证blocked_builtins在受限全局作用域中被替换为抛错桩的内置函数名allowed_pathscheck_file_access允许访问的文件系统根路径max_memory_mb/max_cpu_seconds资源上限提示——注意文档与注释都明确说明进程内沙箱不强制资源限制硬性保证需要 cgroups、Job Objects 或 rlimit 等 OS 级隔离shadow_sys_modules默认 True用陷阱代理替换sys.modules中的被禁条目封堵sys.modules[os].system(...)逃逸enforce_ast_validation默认 Trueexecute_code_sandboxed先跑validate_code做 AST 静态检查任何违规都拒绝执行fail-closed。这条设计对应 ASI05Unexpected Code Execution与 ASI10Rogue Agents的沙箱隔离控制面也是映射文档所说沙箱提供者测试用于隔离验证的实现底座。四、Fail-closed 行为意外的错误也必须拒绝操作映射文档的 fail-closed 原则可以概括为三句话意外的策略policy、分发器dispatcher或审批approval错误一律拒绝该操作面向外部的公开异常只暴露稳定的文本stable text受信任的审计代码则保留完整的结构化PolicyEvaluation。这一原则在异常体系与测试中都有直接对应。异常层级定义于 exceptions.pyPolicyError→PolicyViolationError/PolicyDeniedError/PolicyTimeoutError。测试断言了稳定文本与结构化信息的分离# test_native_adapter_runtime.py 中的行为验证 assert str(error) Request blocked by policy. # 对外稳定文本 assert error.evaluation_result is result.evaluation # 对内结构化结果 assert error.details[message] restricted detail # 细节进入审计 details也就是说同一个PolicyViolationError同时携带给外部看的脱敏文本与给审计代码看的结构化评估正好实现映射文档所说的公共异常暴露稳定文本受信任审计代码保留结构化PolicyEvaluation。这也对应 ASI09Human-Agent Trust Exploitation的restricted audit控制敏感细节不向调用方泄露但完整证据进入审计通道。五、验证手段四类测试各司其职映射文档给出了四条验证路径每一类都能在仓库中找到落点策略回放policy replay使用agt test做策略回放。该命令定义于 agent-compliance 的 policy_test.py用法为agt test policies/ fixtures/把预置 fixture 逐条回放到策略引擎比对期望裁决 vs 实际裁决并输出 mismatch 摘要——适合验证 OWASP 清单对已知攻击样例的拦截效果。适配器中介测试adapter mediation tests验证副作用顺序side-effect ordering。即上文提到的 test_adapter_mediation_contract.py以契约形式锁定每个框架适配器在 input / pre_tool_call / output 干预点上的中介行为。沙箱提供者测试sandbox provider tests验证隔离isolation。Agent OS 生态内的 agent-sandbox 测试目录 覆盖 Azure、Docker、Hyperlight、Nonosandbox、MXC 等提供者进程内沙箱的 test_sandbox.py 则验证导入拦截等静态与运行时防护。红队套件red-team suites覆盖跨层攻击场景cross-layer attack scenarios。仓库根目录的 tests/redteam 目录即为跨层红队测试的落点可用于模拟策略层 沙箱层 身份层联合攻击。六、使用前提与边界本文映射是架构性指引覆盖某项风险不等于已通过 XX 认证。部署时应以自身威胁模型为准逐项验证所依赖的控制项确实开启并生效。策略评估拦截的是经由适配器/内核通道的动作映射文档与 Agent OS README 的已知限制都提示应用层中间件无法拦截绕过它的直接 stdlib 调用如subprocess、open生产环境应叠加容器级隔离作为纵深防御。进程内沙箱的max_memory_mb/max_cpu_seconds是提示性字段硬性资源限制依赖 OS 级机制对不可信负载应改用沙箱提供者。掌握了映射表、ACS 原生示例、宿主控制边界与 fail-closed 语义你就可以对照 OWASP Agentic Top 10 逐项审查自己的 Agent 部署并用agt test与各类测试套件持续验证治理有效性。想继续深入可阅读 Agent OS 安全规格.agents/security.md的 schema 与严格/宽松/审计三种模板、策略模式文档 与 Agent OS 快速开始。【免费下载链接】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），仅供参考