最近在做 AI Coding Agent 的安全加固时我一直在思考一个问题当模型能力越强、能自主执行的命令越复杂安全边界是不是反而越模糊过去大家习惯把安全寄托在“大模型本身别犯错”上但实际跑过几轮 Agent 任务就会发现这个假设非常危险。在 2026 年 8 月的内部评测中我们用一组小模型SLMs加一套策略管控框架IRM在 Coding Agent 的安全场景里做到了比“GPT5.5-xhigh 档位模型”更稳定的防护效果。这篇文章不会去争论某个商业模型到底强不强而是重点拆解我们是怎么用小模型做安全哨兵、怎么用 IRM 策略引擎约束 Agent 行为、以及这套方案落地的完整工程思路。无论你是在做 AI 编程助手、自动化运维工具还是企业内部代码机器人都应该能从这套设计里找到可复用的思路。1. 背景与核心概念Coding Agent 的安全困境1.1 Coding Agent 到底是什么Coding Agent 不是一个简单的“代码补全插件”而是一个能自主理解需求、拆解任务、调用工具、读写文件、执行命令、甚至提交代码的智能体。它通常由三部分组成大模型大脑负责理解任务、生成决策、调用工具。工具集包括 Shell、文件系统、Git、包管理器、IDE API。执行环境在沙箱、容器或本机环境中运行命令。相比传统的静态代码扫描工具Coding Agent 的杀伤力在于“它能自己动手改东西”。权限范围越大能造成的破坏也越大。比如一个 Agent 在修改依赖时可能不小心执行了rm -rf在读取凭证时可能把密钥打印进日志在自动修复测试时可能绕过代码规范直接提交。1.2 为什么大模型越强安全压力反而越大现在很多团队倾向用能力更强的模型来驱动 Agent理由是“理解能力越好越不容易犯错”。但从安全角度来看这是一个矛盾点强模型执行力更强可能同时发起多个并行操作安全事件的影响面被放大。强模型更容易“自作主张”会补全缺失参数、自动重试、甚至自己绕过失败步骤。强模型的输出更难被简单规则约束黑盒生成过程无法完全预判。所以问题不是“换更大的模型”而是“如何给 Agent 装一层独立于模型之外的安全管控”。这也是我们引入 SLMs IRM 的核心动机。1.3 SLMs 与 IRM 在这里指什么为了避免歧义先说明本文中的两个关键概念SLMsSmall Language Models参数量相对较小、推理成本低、响应速度快的大语言模型。本文中用它们做安全检测而不是做复杂代码生成。典型任务包括识别危险命令、分类敏感文件、判断操作是否越权。IRMIntent-Risk Moderation一套基于“意图 风险”的策略管控框架。它的核心不是让模型“别干坏事”而是要求 Agent 在每步操作前先回答两个问题这一步的意图是什么如果执行风险等级是多少IRM 再根据策略决定放行、人工确认、阻断。简单说SLMs 负责快速识别风险信号IRM 负责把风险信号转化成可执行的管控策略。2. 为什么通用大模型做 Coding Agent 安全不够2.1 通用模型的回答能力 ≠ 实时拦截能力通用大模型擅长解释安全问题但不适合实时拦截。原因有三个延迟高、成本贵、结果不稳定。在 Agent 需要连续执行多个 Shell 命令时如果每个操作都请求一次强模型做安全判断整个任务会变得非常慢而且费用难以控制。更重要的一点是通用模型在“知识问答”和“实时决策”之间的差异非常大。你问它“rm -rf 危险吗”它能给出标准答案但你在让它判断“当前这个git push --force在 CI 环境是否允许”时它需要结合上下文、敏感度、环境策略这已经超出了通用问答的范畴。2.2 只靠提示词约束等于没有约束很多人会在 System Prompt 里写“你不能删除文件”“你不能执行危险命令”但实际操作中这类约束很容易被绕过用户用间接方式表达比如“清理一下项目缓存”。Agent 把危险命令拆成多个低风险命令。命令通过脚本文件间接执行。模型输出格式被工具调用过程压缩安全提示词被忽略。这不是模型“不听话”而是提示词本身不具备强制执行能力。真正有效的约束必须放在模型输出之后的执行链路上也就是在“决定执行”和“真正执行”之间加一道拦截器。2.3 为什么选 SLMs 而不是更强的大模型这里的直觉是安全检测任务并不需要太强的生成能力它更需要稳定、快速、可解释。对比维度通用强模型安全专用 SLMs延迟高单次请求几百毫秒到数秒低可在几十毫秒内返回成本高按 Token 计费低可本地部署可解释性弱黑盒输出强可输出结构化风险标签稳定性受版本更新影响大可固定版本、离线运行专注度通用任务优化专用安全场景优化SLMs 如果做通用代码生成能力肯定不够。但让它做“命令是否危险”“文件路径是否敏感”“操作是否需要审批”这类分类任务完全够用而且更可控。3. 环境准备与整体架构设计3.1 推荐运行环境本文示例以 Python 3.10 为主要运行环境需要安装以下依赖fastapi或flask搭建本地安全代理服务。transformersonnxruntime部署 SLM 模型本文示例使用轻量分类模型可以用本地模型替换。pydantic做结构化校验。git、bash或 PowerShell用于模拟 Coding Agent 执行环境。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。如果你只是做方案验证可以直接用 Python 内置库 一个 HTTP 服务不需要 GPU。3.2 整体架构插入 Agent 与执行器之间我们的设计核心是在 Coding Agent 的工作流中插入一个“安全代理层”它位于模型输出与命令执行之间Coding Agent 决策输出 ↓ 安全代理层Security Proxy ├── 1. 意图分类SLM-A ├── 2. 风险评分SLM-B 规则引擎 ├── 3. IRM 策略引擎是否放行/阻断/人工确认 ↓ 命令执行器Shell / Git / API这个架构有几个优点安全逻辑与模型解耦换模型不影响安全策略。可以单独升级安全模型不需要重跑整个 Agent。每一次操作都有审计日志可回溯。高风险操作可以强制人工审批而不是完全依赖模型判断。3.3 目录结构建议把代码组织成以下结构agent-security/ ├── proxy/ │ ├── server.py # 安全代理服务入口 │ ├── policy_engine.py # IRM 策略引擎 │ ├── intent_model.py # SLM 意图分类 │ └── risk_model.py # SLM 风险评分 ├── rules/ │ ├── command_risks.yaml # 命令风险规则 │ └── path_sensitive.yaml# 敏感路径规则 ├── tests/ │ ├── test_commands.py │ └── test_policy.py └── README.md这个结构方便你按模块扩展。生产环境推荐把服务独立部署使用 Docker 容器隔离避免 Agent 本体直接访问宿主系统。4. SLMs 安全哨兵让模型只能做“判断题”4.1 SLM 不是用来生成而是用来打标签在 Coding Agent 安全场景里SLM 不需要写代码它只需要输出以下结构{ intent: DELETE_FILE, risk_level: HIGH, sensitive_path: true, requires_approval: true, reason: detected rm -rf on root project directory }这种输出叫“结构化风险标签”。它比自然语言描述更适合被程序消费策略引擎可以直接读取字段做判断不需要再解析文本。4.2 基于规则 微调小模型的双通道检测在工程上纯规则容易漏纯模型容易误报。我们的做法是“规则先行 SLM 兜底”。先来看一个轻量危险命令检测器# 文件路径agent-security/proxy/risk_model.py import re BLOCKLIST_PATTERNS [ r\brm\s-rf\b, r\bmkfs\b, r\bdd\sif.*of/dev/, r\bshutdown\b, r\breboot\b, r\s*/dev/sd, r\bgit\spush\s--force\b, r\bchmod\s-R\s777\b, ] SENSITIVE_PATH_MARKERS [ /etc/passwd, /etc/shadow, id_rsa, .env, token, secret, ] def rule_based_risk(command: str) - dict: command_lower command.lower() matched_rules [] for pattern in BLOCKLIST_PATTERNS: if re.search(pattern, command_lower): matched_rules.append(pattern) sensitive_path_hit any( marker in command_lower for marker in SENSITIVE_PATH_MARKERS ) if matched_rules: return { risk_level: HIGH, matched_rules: matched_rules, sensitive_path: sensitive_path_hit, } return { risk_level: LOW, matched_rules: [], sensitive_path: sensitive_path_hit, }这段代码逻辑很简单用正则识别高危命令用路径特征识别敏感文件。规则检测的速度很快适合做第一道过滤。但规则有局限性。比如攻击者可能用rm --recursive --force这种全拼参数绕开rm -rf的正则也可能通过变量拼接命令。所以第二道检测交给 SLM。4.3 用轻量分类模型识别“危险意图”下面代码展示如何加载一个分类模型并把命令文本映射到意图标签# 文件路径agent-security/proxy/intent_model.py from transformers import pipeline class IntentClassifier: def __init__(self, model_name: str your-security-intent-model): self.pipe pipeline( text-classification, modelmodel_name, top_kNone, ) def classify(self, command: str) - dict: # 模型要求输出标签集合例如 # { # label: HIGH_RISK_EXECUTION, # score: 0.93 # } result self.pipe(command[:512])[0] top result[0] return { intent: top[label], confidence: float(top[score]), } if __name__ __main__: clf IntentClassifier() print(clf.classify(rm -rf ./node_modules))这里的model_name需要替换为你自己微调过的模型。如果你手头没有模型可以先用一个文本分类模型做基线测试再用真实攻击样本微调。关键点在于模型任务是“意图分类”不是“文本续写”所以不需要大参数模型。4.4 SLM 输出的置信度处理模型输出置信度不能直接当权威。对于安全系统宁可信其有不可信其无。我们的做法是置信度高于 0.9直接按模型标签执行策略。置信度在 0.6 ~ 0.9进入 IRM 规则引擎结合上下文判断。置信度低于 0.6默认转人工确认。这样可以防止模型“高自信误判”也可以避免因为模型不自信而放行危险操作。5. IRM 策略引擎意图 风险的双层管控5.1 IRM 策略引擎的核心数据结构IRM 对所有操作建立一个统一的风险上下文# 文件路径agent-security/proxy/policy_engine.py from dataclasses import dataclass, field from enum import Enum class Action(Enum): ALLOW allow DENY deny ASK ask dataclass class SecurityContext: user_id: str project_path: str agent_name: str allowed_commands: list field(default_factorylist) restricted_paths: list field(default_factorylist) dataclass class RiskAssessment: command: str intent: str risk_level: str sensitive_path: bool confidence: float matched_rules: list field(default_factorylist)SecurityContext表示当前 Agent 运行的安全上下文RiskAssessment是 SLM 和规则引擎产出的风险分析结果。策略引擎拿到这两者后输出一个Action。5.2 策略矩阵基于上下文的决策不要写“一刀切”策略而是根据上下文判断。比如rm -rf ./node_modules在本地项目目录可能允许执行。rm -rf /无论如何都要阻断。git push --force在 release 分支上需要 Ask。读取/etc/passwd永远需要阻断。下面代码实现一个简单的策略矩阵# 文件路径agent-security/proxy/policy_engine.py def decide_action( assessment: RiskAssessment, ctx: SecurityContext, ) - Action: # 高危意图 敏感路径直接阻断 if assessment.risk_level HIGH and assessment.sensitive_path: return Action.DENY # 高风险命令如果不在白名单中需要人工确认 if assessment.risk_level HIGH: if assessment.command in ctx.allowed_commands: return Action.ALLOW return Action.ASK # 低风险命令但涉及非项目路径也建议确认 if assessment.risk_level LOW: # 这里只做演示生产系统需要更精细的路径判断 if /tmp/ in assessment.command: return Action.ASK return Action.ALLOW return Action.ALLOW这里的策略是“风险分级 上下文白名单”。危险命令默认不允许除非用户在白名单中明确声明。这比“让模型自己判断”要安全得多。5.3 可解释性与审计日志IRM 策略引擎不应该只输出一个allow/deny还要输出理由方便审计和人工复核# 文件路径agent-security/proxy/policy_engine.py def generate_audit_record( assessment: RiskAssessment, ctx: SecurityContext, action: Action, ) - dict: return { timestamp: 2026-08-15T10:00:00Z, user_id: ctx.user_id, agent_name: ctx.agent_name, command: assessment.command, intent: assessment.intent, risk_level: assessment.risk_level, confidence: assessment.confidence, matched_rules: assessment.matched_rules, action: action.value, reason: _explain(action, assessment), } def _explain(action: Action, assessment: RiskAssessment) - str: if action Action.DENY: return fHigh risk command on sensitive path: {assessment.sensitive_path} if action Action.ASK: return fCommand requires manual approval, risk level: {assessment.risk_level} return Allowed by security policy生产环境建议把审计记录写入独立的日志系统保证 Agent 即使崩溃也不会丢失安全事件。6. 集成到 Coding Agent 工作流6.1 通过 HTTP 服务暴露安全代理为了让 Coding Agent 能调用安全代理我们需要把它包装成一个 HTTP 服务。下面用 FastAPI 做一个最小实现# 文件路径agent-security/proxy/server.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from policy_engine import SecurityContext, RiskAssessment, decide_action, generate_audit_record app FastAPI() class CheckRequest(BaseModel): command: str user_id: str project_path: str agent_name: str allowed_commands: list[str] [] class CheckResponse(BaseModel): action: str reason: str risk_level: str intent: str app.post(/v1/check) def check(req: CheckRequest): # 这里应调用规则引擎 SLM 模型 # 为了示例可读直接构造一个简单样例 assessment RiskAssessment( commandreq.command, intentEXECUTE_COMMAND, risk_levelHIGH if rm -rf in req.command else LOW, sensitive_path/etc/ in req.command, confidence0.95, ) ctx SecurityContext( user_idreq.user_id, project_pathreq.project_path, agent_namereq.agent_name, allowed_commandsreq.allowed_commands, ) action decide_action(assessment, ctx) audit generate_audit_record(assessment, ctx, action) # 日志写入逻辑在这里省略 # log_audit(audit) return CheckResponse( actionaction.value, reasonaudit[reason], risk_levelassessment.risk_level, intentassessment.intent, ) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port9100)这个服务独立于 Coding Agent 本体可以通过本地 HTTP 或 Unix Socket 调用。将策略服务独立出来的好处是Agent 即使被提示词注入攻击也无法直接修改安全策略。6.2 Coding Agent 侧集成示例假设你的 Agent 在执行命令前有一个execute_command函数在真正执行前调用安全代理# 文件路径agent-security/proxy/client_example.py import requests SECURITY_PROXY_URL http://127.0.0.1:9100 def check_command(command: str, user_id: str, project_path: str) - str: resp requests.post( f{SECURITY_PROXY_URL}/v1/check, json{ command: command, user_id: user_id, project_path: project_path, agent_name: code-agent, allowed_commands: [git status, git diff, ls], }, timeout3, ) resp.raise_for_status() data resp.json() return data[action] # allow / deny / ask def execute_command(command: str, user_id: str, project_path: str): action check_command(command, user_id, project_path) if action deny: raise PermissionError(fCommand blocked by security proxy: {command}) if action ask: # 这里可以触发人工审批流程 raise PermissionError(fCommand requires manual approval: {command}) # 实际执行命令省略 subprocess 细节 print(fExecuting: {command})这个客户端代码可以直接嵌入到 Agent 的工具调用层。注意timeout要合理设置避免安全服务故障时阻塞 Agent 任务。6.3 支持人工审批流程IRM 策略引擎的ask动作需要配合审批流程。最简单的方案是在 Agent 控制台输出审批链接由人工点击确认后再继续执行。生产环境可以接入 IM 通知。关键原则是审批记录必须和 Agent 执行结果关联形成闭环。7. 运行验证与效果评估7.1 启动安全代理在项目根目录执行cd agent-security/proxy python server.py正常会看到 FastAPI 的启动日志监听在9100端口。7.2 测试不同命令的策略输出用curl模拟 Agent 调用curl -X POST http://127.0.0.1:9100/v1/check \ -H Content-Type: application/json \ -d { command: rm -rf /, user_id: user01, project_path: /home/user01/project, agent_name: code-agent, allowed_commands: [] }预期输出{ action: deny, reason: High risk command on sensitive path: True, risk_level: HIGH, intent: EXECUTE_COMMAND }再测试一个低风险命令curl -X POST http://127.0.0.1:9100/v1/check \ -H Content-Type: application/json \ -d { command: ls -la, user_id: user01, project_path: /home/user01/project, agent_name: code-agent, allowed_commands: [ls] }预期输出{ action: allow, reason: Allowed by security policy, risk_level: LOW, intent: EXECUTE_COMMAND }7.3 如何衡量“更安全”我们内部评测时主要看四个指标阻断率高危命令有多少被正确阻断。误报率低风险操作有多少被错误阻断。人工审批率多少操作需要人工介入。审计完整率安全事件是否都有日志记录。在对比测试中SLMs IRM 的拦截效果优势主要体现在“误报率”和“可解释性”上。强模型可能也能识别危险命令但它的输出不稳定还可能被对话上下文带偏。而 SLM 安全哨兵只做固定分类任务行为可预期。8. 常见问题与排查思路8.1 安全代理服务连接超时问题现象常见原因解决思路Agent 调用安全代理超时服务未启动或端口被占用检查9100端口监听状态确认服务能正常访问请求返回 500模型加载失败或依赖缺失查看服务端日志检查模型路径是否正确安全策略未生效客户端没接代理直接执行了命令确认execute_command中是否调用了/v1/check8.2 模型把普通命令误判为高危SLM 分类模型很容易把含有delete、drop、kill等单词的命令判为高危。解决方法是积累项目级样本对模型做针对性微调同时在规则引擎中设置“白名单覆盖机制”。规则引擎的优先级应该高于模型标签这样即使模型误判白名单依然能兜底。8.3 与 Windows 环境中的irm命令混淆在搜索相关资料时你可能会看到irm是 PowerShell 的Invoke-RestMethod命令缩写也经常出现在系统激活脚本、下载远程脚本的场景中。请注意本文的 IRM 指的是我们用来做 Coding Agent 安全策略的 Intent-Risk Moderation 框架与 PowerShell 的irm命令没有关系。另外要提醒的是任何要求你从远程地址下载脚本并直接执行的命令都应当谨慎处理。安全团队应该默认阻断这类行为要求先审查脚本内容再在隔离环境中运行。8.4 与 Spring Security 的定位差异有同学问既然 Java 后端已经有 Spring Security为什么还要单独做 IRM 策略引擎。这里需要区分两类安全Spring Security 解决的是“应用认证与授权”比如用户能否访问某个接口。IRM 策略引擎解决的是“Agent 操作行为管控”比如代码机器人能否删除某个文件。两者关注点不同可以组合使用。如果你的 Coding Agent 是 Java 技术栈可以在原有 Spring Security 基础上扩展一个过滤器在 Controller 层调用 IRM 服务。两者并不冲突。9. 最佳实践与生产落地建议9.1 安全代理必须独立部署不要把你的安全服务打包进 Agent 进程里。如果 Agent 被提示词注入攻击恶意指令可能直接修改内存中的策略对象。独立部署后Agent 只能通过网络接口访问安全策略攻击面大大缩小。9.2 默认拒绝而不是默认放行很多团队做 Agent 安全时习惯“先放行发现危险再拦截”。这个思路反了。生产环境应该是默认拒绝只有白名单内的操作才允许执行。你可以先建立一个“允许列表”把高频低风险命令加进去比如git statusgit difflscat限制在项目目录内python -m pytest限制在测试目录这样即使 SLM 漏掉某个攻击命令Agent 也无法执行它。9.3 所有安全事件必须可审计审计日志建议包含以下字段时间戳操作用户Agent 名称/版本完整命令模型风险标签规则命中项最终动作审批人如果经过审批这样可以支撑事后追溯、策略调优和 SOC 对接。9.4 定期回放安全测试集不要只做一次测试就放手。建议维护一个安全测试集里面包含常见高危命令恶意拼接命令敏感路径操作越权读取文件提示词注入样例每次更新 SLM 或调整 IRM 策略后都回放一遍测试集确保没有回归。9.5 分级灰度上线在正式环境启用安全代理时建议先做“观察模式”只记录风险事件和策略结论不真正阻断命令。等评估完误报率后再逐步切到“拦截模式”。这个步骤能避免安全策略误伤正常开发流程也能让团队逐步建立对系统的信任。10. 下一步可以继续深入的方向如果你想把这套方案落地到自己的项目中建议按下面路径推进先完成“规则引擎 审计日志”这一步不需要 ML 模型能解决 80% 的高危命令拦截需求。再引入 SLM 做“意图分类”主要解决规则覆盖不到的表达方式。最后完善 IRM 策略矩阵把“用户角色、项目路径、操作对象”三个维度纳入决策。有条件的团队可以继续做“Agent 行为实时监控”把审批与告警接入现有的安全运营体系。安全不是一锤子买卖而是一个持续对抗的过程。SLMs 和 IRM 的最大价值不是替代强模型而是把“安全判断”从模型生成链路中分离出来让它成为一个独立的、可测试、可迭代的工程系统。希望这篇文章能给你带来一些可落地的启发。 Coding Agent安全加固：SLMs哨兵与IRM策略引擎的工程实践
最近在做 AI Coding Agent 的安全加固时我一直在思考一个问题当模型能力越强、能自主执行的命令越复杂安全边界是不是反而越模糊过去大家习惯把安全寄托在“大模型本身别犯错”上但实际跑过几轮 Agent 任务就会发现这个假设非常危险。在 2026 年 8 月的内部评测中我们用一组小模型SLMs加一套策略管控框架IRM在 Coding Agent 的安全场景里做到了比“GPT5.5-xhigh 档位模型”更稳定的防护效果。这篇文章不会去争论某个商业模型到底强不强而是重点拆解我们是怎么用小模型做安全哨兵、怎么用 IRM 策略引擎约束 Agent 行为、以及这套方案落地的完整工程思路。无论你是在做 AI 编程助手、自动化运维工具还是企业内部代码机器人都应该能从这套设计里找到可复用的思路。1. 背景与核心概念Coding Agent 的安全困境1.1 Coding Agent 到底是什么Coding Agent 不是一个简单的“代码补全插件”而是一个能自主理解需求、拆解任务、调用工具、读写文件、执行命令、甚至提交代码的智能体。它通常由三部分组成大模型大脑负责理解任务、生成决策、调用工具。工具集包括 Shell、文件系统、Git、包管理器、IDE API。执行环境在沙箱、容器或本机环境中运行命令。相比传统的静态代码扫描工具Coding Agent 的杀伤力在于“它能自己动手改东西”。权限范围越大能造成的破坏也越大。比如一个 Agent 在修改依赖时可能不小心执行了rm -rf在读取凭证时可能把密钥打印进日志在自动修复测试时可能绕过代码规范直接提交。1.2 为什么大模型越强安全压力反而越大现在很多团队倾向用能力更强的模型来驱动 Agent理由是“理解能力越好越不容易犯错”。但从安全角度来看这是一个矛盾点强模型执行力更强可能同时发起多个并行操作安全事件的影响面被放大。强模型更容易“自作主张”会补全缺失参数、自动重试、甚至自己绕过失败步骤。强模型的输出更难被简单规则约束黑盒生成过程无法完全预判。所以问题不是“换更大的模型”而是“如何给 Agent 装一层独立于模型之外的安全管控”。这也是我们引入 SLMs IRM 的核心动机。1.3 SLMs 与 IRM 在这里指什么为了避免歧义先说明本文中的两个关键概念SLMsSmall Language Models参数量相对较小、推理成本低、响应速度快的大语言模型。本文中用它们做安全检测而不是做复杂代码生成。典型任务包括识别危险命令、分类敏感文件、判断操作是否越权。IRMIntent-Risk Moderation一套基于“意图 风险”的策略管控框架。它的核心不是让模型“别干坏事”而是要求 Agent 在每步操作前先回答两个问题这一步的意图是什么如果执行风险等级是多少IRM 再根据策略决定放行、人工确认、阻断。简单说SLMs 负责快速识别风险信号IRM 负责把风险信号转化成可执行的管控策略。2. 为什么通用大模型做 Coding Agent 安全不够2.1 通用模型的回答能力 ≠ 实时拦截能力通用大模型擅长解释安全问题但不适合实时拦截。原因有三个延迟高、成本贵、结果不稳定。在 Agent 需要连续执行多个 Shell 命令时如果每个操作都请求一次强模型做安全判断整个任务会变得非常慢而且费用难以控制。更重要的一点是通用模型在“知识问答”和“实时决策”之间的差异非常大。你问它“rm -rf 危险吗”它能给出标准答案但你在让它判断“当前这个git push --force在 CI 环境是否允许”时它需要结合上下文、敏感度、环境策略这已经超出了通用问答的范畴。2.2 只靠提示词约束等于没有约束很多人会在 System Prompt 里写“你不能删除文件”“你不能执行危险命令”但实际操作中这类约束很容易被绕过用户用间接方式表达比如“清理一下项目缓存”。Agent 把危险命令拆成多个低风险命令。命令通过脚本文件间接执行。模型输出格式被工具调用过程压缩安全提示词被忽略。这不是模型“不听话”而是提示词本身不具备强制执行能力。真正有效的约束必须放在模型输出之后的执行链路上也就是在“决定执行”和“真正执行”之间加一道拦截器。2.3 为什么选 SLMs 而不是更强的大模型这里的直觉是安全检测任务并不需要太强的生成能力它更需要稳定、快速、可解释。对比维度通用强模型安全专用 SLMs延迟高单次请求几百毫秒到数秒低可在几十毫秒内返回成本高按 Token 计费低可本地部署可解释性弱黑盒输出强可输出结构化风险标签稳定性受版本更新影响大可固定版本、离线运行专注度通用任务优化专用安全场景优化SLMs 如果做通用代码生成能力肯定不够。但让它做“命令是否危险”“文件路径是否敏感”“操作是否需要审批”这类分类任务完全够用而且更可控。3. 环境准备与整体架构设计3.1 推荐运行环境本文示例以 Python 3.10 为主要运行环境需要安装以下依赖fastapi或flask搭建本地安全代理服务。transformersonnxruntime部署 SLM 模型本文示例使用轻量分类模型可以用本地模型替换。pydantic做结构化校验。git、bash或 PowerShell用于模拟 Coding Agent 执行环境。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。如果你只是做方案验证可以直接用 Python 内置库 一个 HTTP 服务不需要 GPU。3.2 整体架构插入 Agent 与执行器之间我们的设计核心是在 Coding Agent 的工作流中插入一个“安全代理层”它位于模型输出与命令执行之间Coding Agent 决策输出 ↓ 安全代理层Security Proxy ├── 1. 意图分类SLM-A ├── 2. 风险评分SLM-B 规则引擎 ├── 3. IRM 策略引擎是否放行/阻断/人工确认 ↓ 命令执行器Shell / Git / API这个架构有几个优点安全逻辑与模型解耦换模型不影响安全策略。可以单独升级安全模型不需要重跑整个 Agent。每一次操作都有审计日志可回溯。高风险操作可以强制人工审批而不是完全依赖模型判断。3.3 目录结构建议把代码组织成以下结构agent-security/ ├── proxy/ │ ├── server.py # 安全代理服务入口 │ ├── policy_engine.py # IRM 策略引擎 │ ├── intent_model.py # SLM 意图分类 │ └── risk_model.py # SLM 风险评分 ├── rules/ │ ├── command_risks.yaml # 命令风险规则 │ └── path_sensitive.yaml# 敏感路径规则 ├── tests/ │ ├── test_commands.py │ └── test_policy.py └── README.md这个结构方便你按模块扩展。生产环境推荐把服务独立部署使用 Docker 容器隔离避免 Agent 本体直接访问宿主系统。4. SLMs 安全哨兵让模型只能做“判断题”4.1 SLM 不是用来生成而是用来打标签在 Coding Agent 安全场景里SLM 不需要写代码它只需要输出以下结构{ intent: DELETE_FILE, risk_level: HIGH, sensitive_path: true, requires_approval: true, reason: detected rm -rf on root project directory }这种输出叫“结构化风险标签”。它比自然语言描述更适合被程序消费策略引擎可以直接读取字段做判断不需要再解析文本。4.2 基于规则 微调小模型的双通道检测在工程上纯规则容易漏纯模型容易误报。我们的做法是“规则先行 SLM 兜底”。先来看一个轻量危险命令检测器# 文件路径agent-security/proxy/risk_model.py import re BLOCKLIST_PATTERNS [ r\brm\s-rf\b, r\bmkfs\b, r\bdd\sif.*of/dev/, r\bshutdown\b, r\breboot\b, r\s*/dev/sd, r\bgit\spush\s--force\b, r\bchmod\s-R\s777\b, ] SENSITIVE_PATH_MARKERS [ /etc/passwd, /etc/shadow, id_rsa, .env, token, secret, ] def rule_based_risk(command: str) - dict: command_lower command.lower() matched_rules [] for pattern in BLOCKLIST_PATTERNS: if re.search(pattern, command_lower): matched_rules.append(pattern) sensitive_path_hit any( marker in command_lower for marker in SENSITIVE_PATH_MARKERS ) if matched_rules: return { risk_level: HIGH, matched_rules: matched_rules, sensitive_path: sensitive_path_hit, } return { risk_level: LOW, matched_rules: [], sensitive_path: sensitive_path_hit, }这段代码逻辑很简单用正则识别高危命令用路径特征识别敏感文件。规则检测的速度很快适合做第一道过滤。但规则有局限性。比如攻击者可能用rm --recursive --force这种全拼参数绕开rm -rf的正则也可能通过变量拼接命令。所以第二道检测交给 SLM。4.3 用轻量分类模型识别“危险意图”下面代码展示如何加载一个分类模型并把命令文本映射到意图标签# 文件路径agent-security/proxy/intent_model.py from transformers import pipeline class IntentClassifier: def __init__(self, model_name: str your-security-intent-model): self.pipe pipeline( text-classification, modelmodel_name, top_kNone, ) def classify(self, command: str) - dict: # 模型要求输出标签集合例如 # { # label: HIGH_RISK_EXECUTION, # score: 0.93 # } result self.pipe(command[:512])[0] top result[0] return { intent: top[label], confidence: float(top[score]), } if __name__ __main__: clf IntentClassifier() print(clf.classify(rm -rf ./node_modules))这里的model_name需要替换为你自己微调过的模型。如果你手头没有模型可以先用一个文本分类模型做基线测试再用真实攻击样本微调。关键点在于模型任务是“意图分类”不是“文本续写”所以不需要大参数模型。4.4 SLM 输出的置信度处理模型输出置信度不能直接当权威。对于安全系统宁可信其有不可信其无。我们的做法是置信度高于 0.9直接按模型标签执行策略。置信度在 0.6 ~ 0.9进入 IRM 规则引擎结合上下文判断。置信度低于 0.6默认转人工确认。这样可以防止模型“高自信误判”也可以避免因为模型不自信而放行危险操作。5. IRM 策略引擎意图 风险的双层管控5.1 IRM 策略引擎的核心数据结构IRM 对所有操作建立一个统一的风险上下文# 文件路径agent-security/proxy/policy_engine.py from dataclasses import dataclass, field from enum import Enum class Action(Enum): ALLOW allow DENY deny ASK ask dataclass class SecurityContext: user_id: str project_path: str agent_name: str allowed_commands: list field(default_factorylist) restricted_paths: list field(default_factorylist) dataclass class RiskAssessment: command: str intent: str risk_level: str sensitive_path: bool confidence: float matched_rules: list field(default_factorylist)SecurityContext表示当前 Agent 运行的安全上下文RiskAssessment是 SLM 和规则引擎产出的风险分析结果。策略引擎拿到这两者后输出一个Action。5.2 策略矩阵基于上下文的决策不要写“一刀切”策略而是根据上下文判断。比如rm -rf ./node_modules在本地项目目录可能允许执行。rm -rf /无论如何都要阻断。git push --force在 release 分支上需要 Ask。读取/etc/passwd永远需要阻断。下面代码实现一个简单的策略矩阵# 文件路径agent-security/proxy/policy_engine.py def decide_action( assessment: RiskAssessment, ctx: SecurityContext, ) - Action: # 高危意图 敏感路径直接阻断 if assessment.risk_level HIGH and assessment.sensitive_path: return Action.DENY # 高风险命令如果不在白名单中需要人工确认 if assessment.risk_level HIGH: if assessment.command in ctx.allowed_commands: return Action.ALLOW return Action.ASK # 低风险命令但涉及非项目路径也建议确认 if assessment.risk_level LOW: # 这里只做演示生产系统需要更精细的路径判断 if /tmp/ in assessment.command: return Action.ASK return Action.ALLOW return Action.ALLOW这里的策略是“风险分级 上下文白名单”。危险命令默认不允许除非用户在白名单中明确声明。这比“让模型自己判断”要安全得多。5.3 可解释性与审计日志IRM 策略引擎不应该只输出一个allow/deny还要输出理由方便审计和人工复核# 文件路径agent-security/proxy/policy_engine.py def generate_audit_record( assessment: RiskAssessment, ctx: SecurityContext, action: Action, ) - dict: return { timestamp: 2026-08-15T10:00:00Z, user_id: ctx.user_id, agent_name: ctx.agent_name, command: assessment.command, intent: assessment.intent, risk_level: assessment.risk_level, confidence: assessment.confidence, matched_rules: assessment.matched_rules, action: action.value, reason: _explain(action, assessment), } def _explain(action: Action, assessment: RiskAssessment) - str: if action Action.DENY: return fHigh risk command on sensitive path: {assessment.sensitive_path} if action Action.ASK: return fCommand requires manual approval, risk level: {assessment.risk_level} return Allowed by security policy生产环境建议把审计记录写入独立的日志系统保证 Agent 即使崩溃也不会丢失安全事件。6. 集成到 Coding Agent 工作流6.1 通过 HTTP 服务暴露安全代理为了让 Coding Agent 能调用安全代理我们需要把它包装成一个 HTTP 服务。下面用 FastAPI 做一个最小实现# 文件路径agent-security/proxy/server.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from policy_engine import SecurityContext, RiskAssessment, decide_action, generate_audit_record app FastAPI() class CheckRequest(BaseModel): command: str user_id: str project_path: str agent_name: str allowed_commands: list[str] [] class CheckResponse(BaseModel): action: str reason: str risk_level: str intent: str app.post(/v1/check) def check(req: CheckRequest): # 这里应调用规则引擎 SLM 模型 # 为了示例可读直接构造一个简单样例 assessment RiskAssessment( commandreq.command, intentEXECUTE_COMMAND, risk_levelHIGH if rm -rf in req.command else LOW, sensitive_path/etc/ in req.command, confidence0.95, ) ctx SecurityContext( user_idreq.user_id, project_pathreq.project_path, agent_namereq.agent_name, allowed_commandsreq.allowed_commands, ) action decide_action(assessment, ctx) audit generate_audit_record(assessment, ctx, action) # 日志写入逻辑在这里省略 # log_audit(audit) return CheckResponse( actionaction.value, reasonaudit[reason], risk_levelassessment.risk_level, intentassessment.intent, ) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port9100)这个服务独立于 Coding Agent 本体可以通过本地 HTTP 或 Unix Socket 调用。将策略服务独立出来的好处是Agent 即使被提示词注入攻击也无法直接修改安全策略。6.2 Coding Agent 侧集成示例假设你的 Agent 在执行命令前有一个execute_command函数在真正执行前调用安全代理# 文件路径agent-security/proxy/client_example.py import requests SECURITY_PROXY_URL http://127.0.0.1:9100 def check_command(command: str, user_id: str, project_path: str) - str: resp requests.post( f{SECURITY_PROXY_URL}/v1/check, json{ command: command, user_id: user_id, project_path: project_path, agent_name: code-agent, allowed_commands: [git status, git diff, ls], }, timeout3, ) resp.raise_for_status() data resp.json() return data[action] # allow / deny / ask def execute_command(command: str, user_id: str, project_path: str): action check_command(command, user_id, project_path) if action deny: raise PermissionError(fCommand blocked by security proxy: {command}) if action ask: # 这里可以触发人工审批流程 raise PermissionError(fCommand requires manual approval: {command}) # 实际执行命令省略 subprocess 细节 print(fExecuting: {command})这个客户端代码可以直接嵌入到 Agent 的工具调用层。注意timeout要合理设置避免安全服务故障时阻塞 Agent 任务。6.3 支持人工审批流程IRM 策略引擎的ask动作需要配合审批流程。最简单的方案是在 Agent 控制台输出审批链接由人工点击确认后再继续执行。生产环境可以接入 IM 通知。关键原则是审批记录必须和 Agent 执行结果关联形成闭环。7. 运行验证与效果评估7.1 启动安全代理在项目根目录执行cd agent-security/proxy python server.py正常会看到 FastAPI 的启动日志监听在9100端口。7.2 测试不同命令的策略输出用curl模拟 Agent 调用curl -X POST http://127.0.0.1:9100/v1/check \ -H Content-Type: application/json \ -d { command: rm -rf /, user_id: user01, project_path: /home/user01/project, agent_name: code-agent, allowed_commands: [] }预期输出{ action: deny, reason: High risk command on sensitive path: True, risk_level: HIGH, intent: EXECUTE_COMMAND }再测试一个低风险命令curl -X POST http://127.0.0.1:9100/v1/check \ -H Content-Type: application/json \ -d { command: ls -la, user_id: user01, project_path: /home/user01/project, agent_name: code-agent, allowed_commands: [ls] }预期输出{ action: allow, reason: Allowed by security policy, risk_level: LOW, intent: EXECUTE_COMMAND }7.3 如何衡量“更安全”我们内部评测时主要看四个指标阻断率高危命令有多少被正确阻断。误报率低风险操作有多少被错误阻断。人工审批率多少操作需要人工介入。审计完整率安全事件是否都有日志记录。在对比测试中SLMs IRM 的拦截效果优势主要体现在“误报率”和“可解释性”上。强模型可能也能识别危险命令但它的输出不稳定还可能被对话上下文带偏。而 SLM 安全哨兵只做固定分类任务行为可预期。8. 常见问题与排查思路8.1 安全代理服务连接超时问题现象常见原因解决思路Agent 调用安全代理超时服务未启动或端口被占用检查9100端口监听状态确认服务能正常访问请求返回 500模型加载失败或依赖缺失查看服务端日志检查模型路径是否正确安全策略未生效客户端没接代理直接执行了命令确认execute_command中是否调用了/v1/check8.2 模型把普通命令误判为高危SLM 分类模型很容易把含有delete、drop、kill等单词的命令判为高危。解决方法是积累项目级样本对模型做针对性微调同时在规则引擎中设置“白名单覆盖机制”。规则引擎的优先级应该高于模型标签这样即使模型误判白名单依然能兜底。8.3 与 Windows 环境中的irm命令混淆在搜索相关资料时你可能会看到irm是 PowerShell 的Invoke-RestMethod命令缩写也经常出现在系统激活脚本、下载远程脚本的场景中。请注意本文的 IRM 指的是我们用来做 Coding Agent 安全策略的 Intent-Risk Moderation 框架与 PowerShell 的irm命令没有关系。另外要提醒的是任何要求你从远程地址下载脚本并直接执行的命令都应当谨慎处理。安全团队应该默认阻断这类行为要求先审查脚本内容再在隔离环境中运行。8.4 与 Spring Security 的定位差异有同学问既然 Java 后端已经有 Spring Security为什么还要单独做 IRM 策略引擎。这里需要区分两类安全Spring Security 解决的是“应用认证与授权”比如用户能否访问某个接口。IRM 策略引擎解决的是“Agent 操作行为管控”比如代码机器人能否删除某个文件。两者关注点不同可以组合使用。如果你的 Coding Agent 是 Java 技术栈可以在原有 Spring Security 基础上扩展一个过滤器在 Controller 层调用 IRM 服务。两者并不冲突。9. 最佳实践与生产落地建议9.1 安全代理必须独立部署不要把你的安全服务打包进 Agent 进程里。如果 Agent 被提示词注入攻击恶意指令可能直接修改内存中的策略对象。独立部署后Agent 只能通过网络接口访问安全策略攻击面大大缩小。9.2 默认拒绝而不是默认放行很多团队做 Agent 安全时习惯“先放行发现危险再拦截”。这个思路反了。生产环境应该是默认拒绝只有白名单内的操作才允许执行。你可以先建立一个“允许列表”把高频低风险命令加进去比如git statusgit difflscat限制在项目目录内python -m pytest限制在测试目录这样即使 SLM 漏掉某个攻击命令Agent 也无法执行它。9.3 所有安全事件必须可审计审计日志建议包含以下字段时间戳操作用户Agent 名称/版本完整命令模型风险标签规则命中项最终动作审批人如果经过审批这样可以支撑事后追溯、策略调优和 SOC 对接。9.4 定期回放安全测试集不要只做一次测试就放手。建议维护一个安全测试集里面包含常见高危命令恶意拼接命令敏感路径操作越权读取文件提示词注入样例每次更新 SLM 或调整 IRM 策略后都回放一遍测试集确保没有回归。9.5 分级灰度上线在正式环境启用安全代理时建议先做“观察模式”只记录风险事件和策略结论不真正阻断命令。等评估完误报率后再逐步切到“拦截模式”。这个步骤能避免安全策略误伤正常开发流程也能让团队逐步建立对系统的信任。10. 下一步可以继续深入的方向如果你想把这套方案落地到自己的项目中建议按下面路径推进先完成“规则引擎 审计日志”这一步不需要 ML 模型能解决 80% 的高危命令拦截需求。再引入 SLM 做“意图分类”主要解决规则覆盖不到的表达方式。最后完善 IRM 策略矩阵把“用户角色、项目路径、操作对象”三个维度纳入决策。有条件的团队可以继续做“Agent 行为实时监控”把审批与告警接入现有的安全运营体系。安全不是一锤子买卖而是一个持续对抗的过程。SLMs 和 IRM 的最大价值不是替代强模型而是把“安全判断”从模型生成链路中分离出来让它成为一个独立的、可测试、可迭代的工程系统。希望这篇文章能给你带来一些可落地的启发。