Agent Governance Toolkit 面向韩国《AI 框架法》的合规映射以清单、干预点策略与 agt CLI 落地技术义务【免费下载链接】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 框架法》合规映射文档 south-korea-ai-framework-act.md系统讲解如何将 Agent Governance Toolkit下称 AGT的管控能力逐条对齐韩国 AI 框架法下的常见技术义务风险分级如何写入 ACS 清单、透明度与审计记录如何构成、安全与韧性各控制项落在哪一层实现、数据治理与人工监督如何绑定干预点以及如何用agt lint-policy与agt test两条命令把验证流程固化到 CI。读完本文你可以为面向韩国市场部署的 AI Agent 建立一套可审计、可回归的治理落地路径。文档定位实施指南而非法律意见原文明确声明其性质This document maps Agent Governance Toolkit controls to common technical obligations under South Koreas AI Framework Act. It is implementation guidance, not a legal opinion or certification.将 AGT 控制项映射到韩国 AI 框架法下的常见技术义务属于实施指南不构成法律意见或认证。这一点决定了使用方式文档给出的是监管需求 → 工程控制的映射与操作建议最终是否满足法律要求取决于你实际配置的控制系统与运行环境并且需要韩国当地的法务与合规负责人参与确认原文 Validation 一节末尾同样强调审计保留、事件报告、用户告知与人工监督程序必须与韩国法务合规方共同评审。风险分级把部署风险写进清单元数据原文 Risk classification 一节的核心要求是把部署风险等级、业务领域domain、司法管辖区jurisdiction、责任人owner以及适用的控制项记录到清单manifest元数据和该部署的治理清单governance inventory中并且清单本身必须把策略绑定到真正执行该分级的干预点intervention points上。原文给出的最小示例from agent_control_specification import AgentControl runtime AgentControl.from_path(policies/korea-high-impact-manifest.yaml)需要注意policies/korea-high-impact-manifest.yaml是原文示意路径仓库中并不存在这个具体文件你需要在自己的工程中按此结构创建韩国高影响场景的清单。可以参照仓库中真实的 ACS 清单示例来组织元数据与干预点绑定例如 support_agent 清单 与 bank_agent 清单——它们演示了清单如何声明policies段策略包路径、Rego 规则路径与干预点定义。清单字段的可信结构由 manifest.schema.json 约束这正是后续agt lint-policy做模式校验的依据。AgentControl.from_path位于 Python 包 agent_control_specification 中负责加载清单、构建策略引擎并把策略装配到清单声明的各干预点上。从源码结构看宿主host逻辑集中在 _host.py运行时通过evaluate_intervention_point对每个干预点执行策略评估——这正是清单把策略绑定到干预点这句话的实现落点。在分级实践中high-impact 这类清单命名本身就是一种治理手段不同风险等级的部署使用不同清单文件例如韩国高影响场景单独维护一份使风险分级与策略强度一一对应便于审计时按清单回溯控制项。透明度与记录谁执行了什么、评估了什么、裁决是什么原文 Transparency and records 一节要求用四类材料保留完整证据链版本化的清单、受限访问的策略审计记录、AgentMesh 身份、以及部署日志四者共同回答四个问题——谁执行了who acted、评估了什么what was evaluated、裁决结果如何the verdict、最终绑定了哪个身份the enforced identity。同时要求对外public的错误信息必须保持脱敏sanitized。落到仓库能力上可以这样拆解版本化清单清单以 YAML/JSON 文件入库如 support_agent/manifest.yaml天然可进入版本控制与发布流程任何一次策略变更都有 diff 可查。身份与信任AgentMesh 提供零信任身份与传输层能力是enforced identity的证据来源相关架构文档见 mcp-trust-guide.md。审计记录仓库的审计与合规教程 04-audit-and-compliance.md 展示了审计链路的记录方式。受限访问是部署侧的权限控制要求原文强调记录本身应是restricted的避免审计数据成为新的数据泄露面。错误脱敏这是一个常被忽略的透明度边界——内部裁决详情含策略上下文与面向用户的错误信息必须分离防止策略细节或内部状态经由错误响应外泄。安全与韧性六类义务到 AGT 控制项的对照原文 Safety and resilience 一节给出了一张完整的对照表这是本文的核心映射完整继承如下需求NeedAGT 控制项AGT control输入与输出安全Input and output safetyACS 干预点策略ACS intervention-point policies工具限制Tool restrictions清单工具目录与适配器中介Manifest tool catalog and adapter mediation人工监督Human oversight原生审批解析器与身份绑定Native approval resolver and identity binding隔离Isolation沙箱提供者与 fail-closed 的SandboxConfig可靠性ReliabilityAgent SRE 的 SLO、熔断器、混沌工程与事件管理多智能体信任Multi-agent trustAgentMesh 身份与传输结合仓库源码可以逐项理解这些控制项的实现位置输入/输出安全 → 干预点策略ACS 的干预点input、tool、output 等是策略评估的挂载位置。清单中intervention_points为空时lint 会直接告警 Manifest defines no intervention points见 lint_policy.py。这等于把是否配置了输入输出防护变成了一条可机检的合规项。工具限制 → 工具目录与适配器中介适配器adapters负责在框架调用与策略引擎之间中介例如 Python SDK 的 _adapters 目录覆盖了 OpenAI、Anthropic、LangChain、MCP 等框架清单中的工具目录声明哪些工具对 Agent 可见未列入目录的工具即被投影掉。隔离 → 沙箱提供者agent-sandbox 提供多个沙箱提供者Docker、ACo、Hyperlight、Nono 等其测试如 test_docker_sandbox.py 验证隔离行为fail-closed 意味着沙箱不可用时默认拒绝执行而非放行这与仓库 ADR 0013-fail-closed-on-policy-evaluation-errors.md 体现的 fail-closed 设计取向一致。可靠性 → Agent SREagent-sre 包承载 SLO 跟踪、熔断与事件管理能力。多智能体信任 → AgentMeshAgentMesh 的 Python 实现入口见 agent_mesh 目录其身份与传输是跨 Agent 信任的基础。数据治理策略绑干预点边界配主机原文 Data governance 一节的三句话信息量很大逐句落地把数据驻留data-residency、PII 与披露策略绑定到 input、tool、output 三类干预点——即 PII 检测、数据驻留判断、对外披露约束这类策略不是全局一次性检查而是按数据流经的位置分点拦截输入处拦敏感数据进入上下文工具处拦敏感数据进入外部调用输出处拦敏感数据流向用户。文件系统、网络与资源边界配置在沙箱的主机配置中——这些是执行环境属性应由沙箱主机配置管理。不要把主机资源设置放进策略对象——这是一条明确的职责分离约束策略对象policy object只承载治理语义允许/拒绝/升级不承载资源限额等运行时资源参数。从源码结构看清单 lint 时逐条检查策略引用的bundle、policy_path、entities_path、schema_path、data_paths等相对路径是否存在见 lint_file保证策略对象只引用其语义相关的资源引用关系可机检、可追溯。人工监督审批必须可测试、不可伪造原文 Human oversight 一节提出两条硬性要求五类审批路径必须全部被测试成功success、拒绝denial、超时timeout、挂起suspension、以及动作-身份不匹配action-identity mismatch。调用方自行提供的布尔值不构成可信审批A caller-provided boolean is not trusted approval——即审批状态不能由被治理的 Agent 或客户端代码自己置一个true就放行必须由治理层原生审批解析器在身份绑定校验后产生。这条要求与原文安全对照表中Human oversight → Native approval resolver and identity binding一脉相承审批解析器需要核对发起审批的动作与最终执行的动作身份一致action-identity不匹配即视为审批失效。在实现层面审批相关逻辑可见 Python 宿主 _host.py 与 Rust SDK 的 approval.rs仓库测试语料中也存在审批场景的确定性用例如 spec-17-approval.case-01.json可用于验证超时即不默认放行这类语义。验证流程agt lint-policy与agt test的 CI 门禁原文 Validation 一节列出五项动作用agt lint-policy对清单做 lint用agt test重放确定性 fixture测试框架的副作用顺序side-effect ordering测试沙箱隔离与网络默认值fail-closed 默认拒绝出站与韩国法务合规负责人评审审计保留、事件报告、用户告知与人工监督程序。前四项均可工程化为自动化门禁。结合源码两条核心命令的实际能力如下。agt lint-policy清单的静态体检命令定义见 agt.py 的 lint-policy 子命令用法为agt lint-policy path [--strict]支持--strict将警告升级为错误并支持全局--json输出。其底层实现 lint_path / lint_file 对单个清单或整个目录递归匹配*.yaml、*.yml、*.json执行以下检查文件必须是 YAML 或 JSON否则直接报错调用agent_control_specification的validate_manifest做 schema 校验、parse_manifest做解析任何解析异常都会转为 error 级发现逐条策略检查其引用的相对路径bundle、policy_path、entities_path、schema_path、data_paths是否真实存在缺失即报 Policy references missing path清单未定义任何干预点时给出 warning——这正是韩国场景下输入/输出安全控制是否挂载的快速检查。结果以file:line: severity: message形式输出passed由是否存在 error 决定。对应测试用例见 test_lint_policy.py。agt test策略行为的确定性回归命令定义见 agt.py 的 test 子命令用法为agt test POLICY_PATH FIXTURE_PATH全部 fixture 通过时退出码 0任一不匹配退出码 1原文明确说它Designed for CI gating on policy changes。回放引擎实现于 policy_test.py其replay函数L193-L283的工作方式用AgentControl.from_path加载清单与原文风险分级一节使用同一入口从 fixture 目录加载*.json/*.yaml/*.yml文件每个 fixture 形如{ id: korean-pii-in-input, intervention_point: input, input: { action: email_send, body: ... }, expected_verdict: deny }fixture 支持expected_verdictallow/deny 等裁决值、expected_action或expected_allowed布尔三种断言字段缺少全部三者会被 校验函数 直接拒绝——保证每条用例都能产生可判定的通过/失败结论。仓库根目录的 fixture_schema.json 提供了完整 JSON Schema。对每个 fixture 调用runtime.evaluate_intervention_point(intervention_point, snapshot)并同步等待裁决将evaluation.verdict.decision与期望值比对生成ReplayReport逐条打印ok/FAIL及期望/实际裁决的差异摘要--json模式输出可被 CI 消费的 JSONprint_report。对于韩国场景值得把 PII 拦截、数据驻留限制、审批超时行为等监管敏感路径都写成 fixture使策略是否真的在执行成为每次 CI 可复验的事实而不是文档承诺。回放行为对应测试见 test_policy_replay_metadata.py。其余两项工程化验证框架副作用顺序验证策略裁决deny/escalate是否先于框架产生不可逆副作用如工具已发出请求被拦截。可参考 e2e Python 测试中的场景组织方式 tests/e2e_python。沙箱隔离与网络默认值验证默认无出站网络、文件系统边界生效可复用 agent-sandbox 测试 的同类断言思路在自己的部署清单上复跑。合规边界声明必须重申原文的收尾声明Compliance depends on the configured controls and operating environment. The toolkit does not by itself establish conformity with the Act.合规取决于所配置的控制与运行环境工具包本身不会自动确立对法律的符合性。即本文所映射的控制项提供了韩国 AI 框架法技术义务的工程落点——风险分级进清单、透明度靠审计与身份、安全韧性靠干预点策略/沙箱/AgentMesh、数据治理靠分点策略、人工监督靠原生审批解析器、验证靠agt lint-policy与agt test的 CI 门禁——但满足法律要求最终是配置 环境 人的评审共同作用的结果清单中的jurisdiction、owner等元数据与法务合规负责人的定期评审环节缺一不可。【免费下载链接】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 Governance Toolkit 面向韩国《AI 框架法》的合规映射：以清单、干预点策略与 agt CLI 落地技术义务
Agent Governance Toolkit 面向韩国《AI 框架法》的合规映射以清单、干预点策略与 agt CLI 落地技术义务【免费下载链接】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 框架法》合规映射文档 south-korea-ai-framework-act.md系统讲解如何将 Agent Governance Toolkit下称 AGT的管控能力逐条对齐韩国 AI 框架法下的常见技术义务风险分级如何写入 ACS 清单、透明度与审计记录如何构成、安全与韧性各控制项落在哪一层实现、数据治理与人工监督如何绑定干预点以及如何用agt lint-policy与agt test两条命令把验证流程固化到 CI。读完本文你可以为面向韩国市场部署的 AI Agent 建立一套可审计、可回归的治理落地路径。文档定位实施指南而非法律意见原文明确声明其性质This document maps Agent Governance Toolkit controls to common technical obligations under South Koreas AI Framework Act. It is implementation guidance, not a legal opinion or certification.将 AGT 控制项映射到韩国 AI 框架法下的常见技术义务属于实施指南不构成法律意见或认证。这一点决定了使用方式文档给出的是监管需求 → 工程控制的映射与操作建议最终是否满足法律要求取决于你实际配置的控制系统与运行环境并且需要韩国当地的法务与合规负责人参与确认原文 Validation 一节末尾同样强调审计保留、事件报告、用户告知与人工监督程序必须与韩国法务合规方共同评审。风险分级把部署风险写进清单元数据原文 Risk classification 一节的核心要求是把部署风险等级、业务领域domain、司法管辖区jurisdiction、责任人owner以及适用的控制项记录到清单manifest元数据和该部署的治理清单governance inventory中并且清单本身必须把策略绑定到真正执行该分级的干预点intervention points上。原文给出的最小示例from agent_control_specification import AgentControl runtime AgentControl.from_path(policies/korea-high-impact-manifest.yaml)需要注意policies/korea-high-impact-manifest.yaml是原文示意路径仓库中并不存在这个具体文件你需要在自己的工程中按此结构创建韩国高影响场景的清单。可以参照仓库中真实的 ACS 清单示例来组织元数据与干预点绑定例如 support_agent 清单 与 bank_agent 清单——它们演示了清单如何声明policies段策略包路径、Rego 规则路径与干预点定义。清单字段的可信结构由 manifest.schema.json 约束这正是后续agt lint-policy做模式校验的依据。AgentControl.from_path位于 Python 包 agent_control_specification 中负责加载清单、构建策略引擎并把策略装配到清单声明的各干预点上。从源码结构看宿主host逻辑集中在 _host.py运行时通过evaluate_intervention_point对每个干预点执行策略评估——这正是清单把策略绑定到干预点这句话的实现落点。在分级实践中high-impact 这类清单命名本身就是一种治理手段不同风险等级的部署使用不同清单文件例如韩国高影响场景单独维护一份使风险分级与策略强度一一对应便于审计时按清单回溯控制项。透明度与记录谁执行了什么、评估了什么、裁决是什么原文 Transparency and records 一节要求用四类材料保留完整证据链版本化的清单、受限访问的策略审计记录、AgentMesh 身份、以及部署日志四者共同回答四个问题——谁执行了who acted、评估了什么what was evaluated、裁决结果如何the verdict、最终绑定了哪个身份the enforced identity。同时要求对外public的错误信息必须保持脱敏sanitized。落到仓库能力上可以这样拆解版本化清单清单以 YAML/JSON 文件入库如 support_agent/manifest.yaml天然可进入版本控制与发布流程任何一次策略变更都有 diff 可查。身份与信任AgentMesh 提供零信任身份与传输层能力是enforced identity的证据来源相关架构文档见 mcp-trust-guide.md。审计记录仓库的审计与合规教程 04-audit-and-compliance.md 展示了审计链路的记录方式。受限访问是部署侧的权限控制要求原文强调记录本身应是restricted的避免审计数据成为新的数据泄露面。错误脱敏这是一个常被忽略的透明度边界——内部裁决详情含策略上下文与面向用户的错误信息必须分离防止策略细节或内部状态经由错误响应外泄。安全与韧性六类义务到 AGT 控制项的对照原文 Safety and resilience 一节给出了一张完整的对照表这是本文的核心映射完整继承如下需求NeedAGT 控制项AGT control输入与输出安全Input and output safetyACS 干预点策略ACS intervention-point policies工具限制Tool restrictions清单工具目录与适配器中介Manifest tool catalog and adapter mediation人工监督Human oversight原生审批解析器与身份绑定Native approval resolver and identity binding隔离Isolation沙箱提供者与 fail-closed 的SandboxConfig可靠性ReliabilityAgent SRE 的 SLO、熔断器、混沌工程与事件管理多智能体信任Multi-agent trustAgentMesh 身份与传输结合仓库源码可以逐项理解这些控制项的实现位置输入/输出安全 → 干预点策略ACS 的干预点input、tool、output 等是策略评估的挂载位置。清单中intervention_points为空时lint 会直接告警 Manifest defines no intervention points见 lint_policy.py。这等于把是否配置了输入输出防护变成了一条可机检的合规项。工具限制 → 工具目录与适配器中介适配器adapters负责在框架调用与策略引擎之间中介例如 Python SDK 的 _adapters 目录覆盖了 OpenAI、Anthropic、LangChain、MCP 等框架清单中的工具目录声明哪些工具对 Agent 可见未列入目录的工具即被投影掉。隔离 → 沙箱提供者agent-sandbox 提供多个沙箱提供者Docker、ACo、Hyperlight、Nono 等其测试如 test_docker_sandbox.py 验证隔离行为fail-closed 意味着沙箱不可用时默认拒绝执行而非放行这与仓库 ADR 0013-fail-closed-on-policy-evaluation-errors.md 体现的 fail-closed 设计取向一致。可靠性 → Agent SREagent-sre 包承载 SLO 跟踪、熔断与事件管理能力。多智能体信任 → AgentMeshAgentMesh 的 Python 实现入口见 agent_mesh 目录其身份与传输是跨 Agent 信任的基础。数据治理策略绑干预点边界配主机原文 Data governance 一节的三句话信息量很大逐句落地把数据驻留data-residency、PII 与披露策略绑定到 input、tool、output 三类干预点——即 PII 检测、数据驻留判断、对外披露约束这类策略不是全局一次性检查而是按数据流经的位置分点拦截输入处拦敏感数据进入上下文工具处拦敏感数据进入外部调用输出处拦敏感数据流向用户。文件系统、网络与资源边界配置在沙箱的主机配置中——这些是执行环境属性应由沙箱主机配置管理。不要把主机资源设置放进策略对象——这是一条明确的职责分离约束策略对象policy object只承载治理语义允许/拒绝/升级不承载资源限额等运行时资源参数。从源码结构看清单 lint 时逐条检查策略引用的bundle、policy_path、entities_path、schema_path、data_paths等相对路径是否存在见 lint_file保证策略对象只引用其语义相关的资源引用关系可机检、可追溯。人工监督审批必须可测试、不可伪造原文 Human oversight 一节提出两条硬性要求五类审批路径必须全部被测试成功success、拒绝denial、超时timeout、挂起suspension、以及动作-身份不匹配action-identity mismatch。调用方自行提供的布尔值不构成可信审批A caller-provided boolean is not trusted approval——即审批状态不能由被治理的 Agent 或客户端代码自己置一个true就放行必须由治理层原生审批解析器在身份绑定校验后产生。这条要求与原文安全对照表中Human oversight → Native approval resolver and identity binding一脉相承审批解析器需要核对发起审批的动作与最终执行的动作身份一致action-identity不匹配即视为审批失效。在实现层面审批相关逻辑可见 Python 宿主 _host.py 与 Rust SDK 的 approval.rs仓库测试语料中也存在审批场景的确定性用例如 spec-17-approval.case-01.json可用于验证超时即不默认放行这类语义。验证流程agt lint-policy与agt test的 CI 门禁原文 Validation 一节列出五项动作用agt lint-policy对清单做 lint用agt test重放确定性 fixture测试框架的副作用顺序side-effect ordering测试沙箱隔离与网络默认值fail-closed 默认拒绝出站与韩国法务合规负责人评审审计保留、事件报告、用户告知与人工监督程序。前四项均可工程化为自动化门禁。结合源码两条核心命令的实际能力如下。agt lint-policy清单的静态体检命令定义见 agt.py 的 lint-policy 子命令用法为agt lint-policy path [--strict]支持--strict将警告升级为错误并支持全局--json输出。其底层实现 lint_path / lint_file 对单个清单或整个目录递归匹配*.yaml、*.yml、*.json执行以下检查文件必须是 YAML 或 JSON否则直接报错调用agent_control_specification的validate_manifest做 schema 校验、parse_manifest做解析任何解析异常都会转为 error 级发现逐条策略检查其引用的相对路径bundle、policy_path、entities_path、schema_path、data_paths是否真实存在缺失即报 Policy references missing path清单未定义任何干预点时给出 warning——这正是韩国场景下输入/输出安全控制是否挂载的快速检查。结果以file:line: severity: message形式输出passed由是否存在 error 决定。对应测试用例见 test_lint_policy.py。agt test策略行为的确定性回归命令定义见 agt.py 的 test 子命令用法为agt test POLICY_PATH FIXTURE_PATH全部 fixture 通过时退出码 0任一不匹配退出码 1原文明确说它Designed for CI gating on policy changes。回放引擎实现于 policy_test.py其replay函数L193-L283的工作方式用AgentControl.from_path加载清单与原文风险分级一节使用同一入口从 fixture 目录加载*.json/*.yaml/*.yml文件每个 fixture 形如{ id: korean-pii-in-input, intervention_point: input, input: { action: email_send, body: ... }, expected_verdict: deny }fixture 支持expected_verdictallow/deny 等裁决值、expected_action或expected_allowed布尔三种断言字段缺少全部三者会被 校验函数 直接拒绝——保证每条用例都能产生可判定的通过/失败结论。仓库根目录的 fixture_schema.json 提供了完整 JSON Schema。对每个 fixture 调用runtime.evaluate_intervention_point(intervention_point, snapshot)并同步等待裁决将evaluation.verdict.decision与期望值比对生成ReplayReport逐条打印ok/FAIL及期望/实际裁决的差异摘要--json模式输出可被 CI 消费的 JSONprint_report。对于韩国场景值得把 PII 拦截、数据驻留限制、审批超时行为等监管敏感路径都写成 fixture使策略是否真的在执行成为每次 CI 可复验的事实而不是文档承诺。回放行为对应测试见 test_policy_replay_metadata.py。其余两项工程化验证框架副作用顺序验证策略裁决deny/escalate是否先于框架产生不可逆副作用如工具已发出请求被拦截。可参考 e2e Python 测试中的场景组织方式 tests/e2e_python。沙箱隔离与网络默认值验证默认无出站网络、文件系统边界生效可复用 agent-sandbox 测试 的同类断言思路在自己的部署清单上复跑。合规边界声明必须重申原文的收尾声明Compliance depends on the configured controls and operating environment. The toolkit does not by itself establish conformity with the Act.合规取决于所配置的控制与运行环境工具包本身不会自动确立对法律的符合性。即本文所映射的控制项提供了韩国 AI 框架法技术义务的工程落点——风险分级进清单、透明度靠审计与身份、安全韧性靠干预点策略/沙箱/AgentMesh、数据治理靠分点策略、人工监督靠原生审批解析器、验证靠agt lint-policy与agt test的 CI 门禁——但满足法律要求最终是配置 环境 人的评审共同作用的结果清单中的jurisdiction、owner等元数据与法务合规负责人的定期评审环节缺一不可。【免费下载链接】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），仅供参考