二、企业级 AI 系统的常见运行模式 在安全分析中，一个常被忽略的事实是：
对话式 AI 的推理过程虽然是无状态的，但企业级系统通常会在模型之外维护会话状态、上下文与长期记忆，从而形成连续行为。 在实际部署中，AI 系统通常具备以下特征： ●同一模型实例服务多个请求 ●依赖历史上下文进行连续推理 ●通过配置与策略统一约束行为 ●借助云算力与平台资源运行 这意味着，AI 的行为并非完全由“当前输入”决定，而是受到长期状态、配置与上下文的共同影响。 在此基础上，企业级 AI 系统往往包含以下几个关键层次： ●模型与系统配置层 ●任务编排与决策控制层（Orchestrator） ●外部工具与服务接口 ●状态存储与知识体系 安全风险，往往并不直接来自模型本身，而是产生于这些层次之间的信任关系设计。 需要思考的几个基础点如下： 第一点，大多数企业级AI系统会将上下文（短期或长期）存入内存或数据库，从而实现连续回复和状态保持。 第二点，AI所需算力庞大，目前大多数企业级部署仍依赖云服务器，这为攻击者提供了潜在的云控制面目标。 第三点，随着AI Agent的广泛应用，其往往成为多种工具与权限的集合体，赋权不当极易引入安全漏洞。 关于AI的架构部分，我主要分为了四大模块： 第一部分是AI算力模块（云资源与模型服务）。 第二部分主要是AI大脑控制（AI Orchestrator）层面。 第三部分是AI的外部工具调用。 第四部分是AI的独立数据库（状态、记忆与知识存储）。 对于大多数读者来说，即使从未接触过 AI 开发，只要使用过对话式 AI，其背后基本都遵循如下架构 简单画一下AI的架构图便于理解：

三、重新理解 AI Agent 的安全边界 从系统视角看，一个典型的 AI Agent 通常由以下要素构成： ● 语言模型：负责理解与推理 ● 规则与策略：定义行为边界 ● 状态与记忆机制：保存上下文与历史 ● 工具与接口权限：连接外部系统 ● 调度与决策逻辑：决定执行路径 在这个结构中，模型只是“理解引擎”，
而真正决定风险上限的，是权限、状态与决策机制的组合方式。 如果这些组件之间缺乏清晰的安全边界，AI Agent 的行为就可能出现“超出设计预期”的情况。

四、风险分析一：状态与上下文的信任问题 在传统系统中，权限判断通常基于明确的身份认证与授权流程。 而在 AI 系统中，行为判断往往隐含地依赖于： ●系统提示与配置 ●历史对话内容 ●状态记忆中的既有结论 如果这些信息被不当继承或混合使用，就可能导致状态信任偏移。 例如，在多轮交互中，AI 可能基于先前结论延续对用户身份或角色的假设，而这一假设并不一定经过真实系统校验。 这种问题并非单点错误，而是由连续推理机制天然放大的系统性风险。 关于历史对话部分的关键风险点：

跨租户污染的真实案例： Slack AI 2024 prompt injection & data exfiltration（PromptArmor报告，2024年8月）：攻击者在公共频道注入恶意prompt，Slack AI在总结/搜索时会拉取私有频道数据，并生成可点击链接泄露给攻击者服务器。虽非严格向量库跨租户， 但展示了公共可见内容对私有检索结果的污染风险。Slack随后紧急patch。 此外，多轮对话 可能造成权限升级错觉------前提：Orchestrator 没有 硬校验，Tool 没有 权限二次确认 真实案例： ● ServiceNow Now Assist 2025第二序prompt injection（AppOmni报告，2025年11月）：低权限用户注入恶意prompt到内容中，诱导低权限Agent招募高权限Agent执行CRUD操作、发送外部邮件（使用发起交互用户的权限）。即使开启内置prompt injection保护仍可成功。ServiceNow确认是设计行为，但更新文档警示风险。 实操危害：导致调用内部/付费工具、泄露其他用户数据、业务逻辑绕过（如客服Agent退款、解锁）。

五、风险分析二：记忆机制带来的长期影响 为了提升体验，许多 AI Agent 引入了长期记忆或向量化知识存储机制，用于： ●保存历史偏好 ●复用上下文信息 ●构建内部知识库 但从安全角度看，这类机制引入了新的挑战： ●不同用户或租户之间的状态是否严格隔离 ●记忆内容是否具备可信来源标识 ●是否存在长期残留的错误认知 一旦记忆系统缺乏明确边界，其影响往往具有持续性与放大效应，而非一次性问题。 从状态持久化（可能包含记忆序列化）到云资源的攻击思路 前置条件：Agent 使用 LangChain 等框架的序列化功能持久化状态（包括记忆或工具上下文），且进程持有云凭证。 真实案例：LangChain Core CVE-2025-68664（LangGrinch，2025年12月）：攻击者通过 Prompt Injection 诱导 LLM 生成恶意元数据，污染序列化字段。 在该案例中，研究表明：当状态序列化与反序列化机制缺乏完整性校验时，Prompt 注入可能影响系统元数据处理流程，在特定配置下增加云凭证暴露的风险面。

六、风险分析三：工具调用与权限放大效应 在实际系统中，AI Agent 通常通过工具接口完成任务，例如： ●数据查询 ●服务调用 ●平台操作 出于便利性考虑，这些工具往往绑定的是服务级身份，而非用户的真实权限集合。 如果缺乏细粒度的权限约束与操作校验，可能出现以下风险模式： ●AI 的行为能力大于发起请求者的真实权限 ●工具返回结果被默认信任并参与后续决策 ●决策逻辑对异常输入缺乏防护机制 这些问题的本质并非传统意义上的漏洞，而是权限建模与信任传递设计不当。 1.调用工具的身份权限问题 本质：Agent通常以服务账号（高权限）调用工具，而非用户权限，导致过度代理（Excessive Agency），用户可诱导执行未授权操作（OWASP LLM08）。 真实案例： ●攻击链：低权限用户在可读内容（如ticket描述）中注入指令 → 低权限Agent解析并招募高权限Agent → 执行写操作或外发邮件。 2.调用工具----->可触发ssrf
真实案例：
● ChatGPT Custom GPTs/Actions SSRF（2024-2025多起相关报告及研究）：用户可控URL被Agent用于资源加载（如图片/网页检索），触发服务器端请求伪造，泄露云元数据服务（如Azure/AWS IMDS）和临时凭证（OpenAI已多次修复）。 3.工具返回结果反向污染Orchestrator/决策 4.调用工具----打到AI orchestrator面 真实案例： Microsoft 365 Copilot 数据外泄（2024-2025多起报告）：攻击者在共享文档/邮件中注入恶意指令，Copilot检索后信任并输出敏感信息，或生成含外泄链接的响应，导致间接数据泄露。（可替换或补充Slack案例）

七、RAG 与外部知识的供应链风险 当 AI Agent 具备联网搜索或自动构建知识库能力时，其知识来源不再完全可控。 在实践中需要关注的问题包括： ●知识收录的可信度与权重机制 ●外部内容对内部决策的长期影响 ●离线模式下对历史知识的持续依赖 这类风险往往不表现为即时异常，而是以潜移默化的方式影响系统行为，增加安全审计与治理难度。 供应链攻击 / RAG知识库污染 真实案例： ● AgentPoison (2024-2025)：在RAG知识库/记忆中注入极少恶意演示，成功攻击真实Agent（自动驾驶、QA、医疗），证明知识污染可持久误导。 ● Slack AI 2024：公共频道污染导致私有数据泄露（间接RAG污染）。

八、防御视角下的设计原则 从系统安全角度看，AI Agent 的防御重点不应放在“限制模型能力”，而应关注以下原则： ●权限判断必须来自真实系统，而非自然语言上下文 ●状态与记忆需按用户与租户强制隔离 ●工具权限遵循最小化原则 ●AI 的角色是“辅助决策”，而非“自动授权” ●关键操作始终需要显式校验与审计 这些原则并不会降低 AI 的业务价值，但能够显著降低其对整体系统安全边界的冲击。

九、结语 ● 当 AI Agent 被赋予执行能力后，安全边界不再只存在于接口、代码与权限系统中，而是被拆散并分布在上下文、状态、记忆与决策链路之中。 ● 真正值得警惕的，并不是模型是否“听话”，而是系统是否在无意识中，将关键判断权交给了未经验证的推理结果。 ●在企业级 AI 系统中，任何一次未被显式校验的状态继承、角色假设或工具调用，最终都会转化为真实系统中的权限行为。这正是 AI Agent 安全治理必须回到系统设计本身的原因。