如何在生产环境中保障AI智能体、MCP服务器与LLM应用安全

AI时代传统AppSec为何失灵

传统应用安全体系建立在一个核心假设之上：应用程序的行为严格由其源代码决定。而AI智能体（Agent）彻底打破了这一前提——其行为是模型、系统提示词（system prompt）、检索上下文、用户输入及调用工具共同涌现的结果。即便两个部署完全相同的智能体，也可能因输入或上下文差异产生截然不同的行为。更严峻的是，新型故障模式难以被现有安全机制捕获：提示注入通过数据而非代码传播；权限过宽的智能体可在无漏洞利用情况下执行有害操作；已停止维护的基础模型仍在持续输出风险预测；MCP服务器上被篡改的工具描述，无需修改应用本身即可劫持智能体行为——这些风险均不会出现在CVE漏洞数据库中。

三步法：看见、修复、防护

Mend.io提出的框架围绕三大行动展开：看见什么重要、更快修复重要问题、在生产环境中保护AI，并配套交付7个可复用的安全工件。

看见：绘制五层攻击面地图与主动发现机制

框架首先定义AI系统的五大攻击面：交互层（用户输入、检索文档、智能体间消息）、智能体层（系统提示词、配置、记忆、自主性设置）、集成层（MCP服务器、工具定义、插件、API）、模型层（基础模型与微调模型、嵌入向量）以及代码层（AI生成代码、AI框架、SDK）。每一层均对应独特风险，如上下文投毒、越权工具调用、工具描述污染、EOL模型服役、恶意第三方包等。

为应对“影子智能体”“未注册MCP服务器”和“嵌入式AI框架”三类隐蔽资产，指南提出五种发现方法：扫描代码库中的智能体特征签名；监控出站网络流量中对大模型API端点的调用；审计服务账号与API密钥；推行轻量级注册机制降低申报门槛；最后通过自动化实现持续发现——因AI资产变化极快，一次性盘点极易过时。

工件1.1（五层攻击面地图）与工件2.1（AI-BOM扩展模板，含9项字段）和2.2（12项错误配置检查清单）即服务于该阶段。

修复：基于AI特性的优先级判定与闭环处置

AI不仅扩大了攻击面，更显著扩展了“发现面”。指南建议采用“丰富→优先级排序→分诊”三阶段流程。其中，可达性、可利用性上下文、业务影响、智能体放大效应、修复可行性构成五级优先级信号，按价值降序排列。

工件3.1明确自动化边界：对可达性/数据流清晰、类别明确的低风险问题，自动判定真/假阳性并留痕；对三级及以上高风险应用或新型AI行为，则必须由人工决策；对尚无证据支撑的新类别风险，仅允许人工评估并书面记录风险接受或延期修复决定。所有自动化关闭动作必须附带可验证证据；错误率抽样审查结果若超阈值，将触发模型重训练。

防护：运行时安全的闭环实践

运行时防护聚焦于四大支柱：护栏（guardrails）、提示词加固、策略强制执行与持续监控，并与AI红队形成反馈闭环——红队发现驱动护栏升级，护栏日志则指导下一轮红队测试。

护栏支持两种部署方式：集成式Python SDK（支持在线或离线模式），或开箱即用的Docker API Server（零代码侵入、无Python依赖）。最小可行防护配置包括：入站护栏拦截提示注入、越策请求与越狱尝试；出站护栏阻断凭证、PII、源码、有害内容及策略违规数据外泄。

系统提示词加固遵循五大模式：默认假设信息可能泄露、指令与数据物理分离、限制潜在影响范围、版本化管理与定期评审、开展对抗性测试。指南强调：严格的工具权限控制比提示词约束更有效——直接禁止访问高危工具，远胜于反复告诫模型‘不要这么做’。

工件4.1包含7项运行时验证检查，而整体成熟度路线图则划分为四个阶段：新兴（Emerging）、发展（Developing）、可控（Controlling）、引领（Leading），并与NIST网络安全框架对齐。

编者观点

面向AI原生应用的安全治理，正从‘代码为中心’转向‘行为与上下文为中心’；中国企业亟需构建覆盖AI资产发现、动态风险评估与运行时策略执行的新型安全能力栈，而非简单沿用传统WAF或SAST工具链。