把 AI 配置当成攻击面：对 Agent 运行环境做安全扫描
我们习惯对应用代码做安全审查——检查 SQL 注入、鉴权漏洞、密钥硬编码。但当一个 AI Agent 开始拥有执行 shell 命令、读写本地文件、调用外部 API 的能力，有一块地方几乎没人审查：Agent 的运行环境配置本身。
权限清单、指令文件、MCP 服务器配置、Hooks 脚本——这些文件控制着 Agent 能做什么、不能做什么。一旦写错，轻则 Agent 行为失控，重则成为提示注入或供应链攻击的入口。
配置文件是一类新的攻击面
传统应用的攻击面大致分两层：运行时代码（逻辑漏洞）和基础设施配置（权限设置、网络规则）。AI Agent 引入了第三层：指令层。
这一层的特殊性在于，它以自然语言和半结构化文本为主，传统静态分析工具对它几乎无感。但危险是实实在在的：
- 权限过宽：允许列表里写了
Bash(*)，等于对 Agent 开放了无限制的 shell 访问，任何一条被注入的指令都可以执行 - 密钥硬编码：把 API key 直接写进配置文件而非环境变量，这一条和普通应用代码的老问题一模一样，只是发生的地方换了
- Hooks 命令注入：Hooks 脚本里用
${file}这类插值构造命令，如果输入来自外部（比如文件名），就是一个经典的命令注入向量 - 提示注入入口：指令文件里包含「自动执行」类的指令，攻击者通过构造特定内容就可以劫持 Agent 的行为
这些问题不需要黑客入侵服务器，只需要一个能影响 Agent 读到的内容的人，就可以触发。
像扫代码一样扫配置
好的做法是把 Agent 配置纳入和代码同等的安全审查流程：每次修改配置后扫一次，上线前扫一次，挂进 CI 自动扫。
AgentShield 是专门针对 AI Agent 配置做静态分析的工具，覆盖：权限清单里的通配符滥用、密钥硬编码、MCP 服务器的供应链风险（比如 npx -y 自动安装未固定版本）、Hooks 里的命令注入、以及 Agent 定义文件里的工具访问范围。
它输出一个 A～F 的安全评分，并给出分级别的修复建议。关键的一点是它区分了「可以自动修复的」和「需要人工判断的」——前者包括把硬编码密钥替换为环境变量引用、把通配符权限收窄到具体范围；后者则是那些需要根据业务逻辑判断取舍的地方，工具只给出建议，不擅自改动。
安全检查最大的陷阱是依赖人的记忆和自觉性。把 npx ecc-agentshield scan --min-severity medium 加进 CI 流水线，每次提交配置变更时自动触发，才是真正的基线保障。单靠「我记得检查一下」，在项目快速迭代时几乎必然会有遗漏。
最小权限是 Agent 配置的第一原则
扫描工具能帮你发现问题，但更根本的是在设计 Agent 配置时就遵循最小权限原则：
权限只给刚好够用的范围，而不是「先给宽再慢慢收」——因为在实际项目里，「慢慢收」几乎不会发生。Bash(git status) 比 Bash(git *) 更安全，后者比 Bash(*) 更安全，差异不是形式上的，是真实的攻击面大小。
拒绝列表和允许列表要同时维护。只有允许列表，等于假设自己列举完了所有需要控制的操作；加上拒绝列表，至少能兜住那些「我没想到但明显不该做」的操作。
外部来源的内容不能直接进指令。MCP 服务器、Hooks 里的变量插值、从外部读入的文件名——凡是来自「外部」的数据流入指令执行路径，都需要额外审查。这和 Web 安全里「不信任用户输入」是同一条原则，只是场景换了。
一句话心法
AI Agent 的配置文件是指令层的代码，最小权限、密钥不硬编码、外部输入不直接进执行路径——这三条老原则，在新场景里仍然成立。