AI安全新焦点：如何防范代理式AI的身份与数据越权风险

F5生态系统 | 2026年10月30日

过去的生成式AI主要负责回答问题，人们更关心它会不会说错话、泄露敏感信息。代理式AI则不同，它不只生成内容，还能调用API、查询数据库、发送消息、修改工单，甚至与其他AI配合完成任务。当AI从“提供建议”走向“代替用户执行操作”，AI安全的重点也随之发生变化。
企业需要回答的不再只是模型能看到什么数据，还包括AI以什么身份工作、能够调用哪些工具、一次授权可以持续多久，以及出现误操作后能否还原完整过程。任何一个环节控制不足，都可能让原本用于提升效率的AI获得超出业务需要的权限。

AI为什么更容易产生越权风险

传统应用的操作流程通常由开发人员提前写好。用户点击哪个按钮，系统执行什么动作，范围相对明确。AI则会根据目标、上下文和模型判断自主安排步骤。同样一句“整理本月异常订单”，它可能查询订单数据库、读取客户资料、调用分析工具，再生成报告并发送给相关人员。
问题在于，模型对任务的理解不一定与企业的权限边界完全一致。如果工具接口开放过多，AI可能为了完成任务读取无关数据；如果使用权限较高的服务账号，它还可能执行普通用户本来无权进行的操作。

用户有权限，不代表AI可以直接继承

员工可能拥有客户系统、财务平台和内部知识库的访问权限，但这些权限是根据其岗位和人工操作场景分配的。AI如果直接继承用户的全部权限，就可能在短时间内读取和处理远超人工操作规模的数据。
因此，企业需要分别判断用户是否可以提出这项任务，以及AI是否可以通过指定工具执行。授权条件至少应考虑用户身份、AI身份、目标资源、操作类型和数据范围，不能只依赖用户已经通过登录认证。
对于查询、修改、删除和对外发送等不同操作，也应设置不同权限。AI可以读取某项数据，不代表它可以修改或传播；能够生成邮件草稿，也不等于可以自动发送。

工具调用是AI越权的关键入口

AI本身未必直接接触业务系统，它通常通过 API 、插件或其他工具完成操作。因此，工具接口开放得越宽，AI可能造成的影响就越大。
有些工具为了方便使用，只提供一个“执行查询”接口，却允许AI提交任意条件；有些接口虽然要求认证，但没有进一步检查数据范围；还有些AI可以调用通用代码执行工具或浏览器，间接绕开原有应用限制。
企业在接入工具时，应尽量提供用途单一、权限明确的接口。例如，与其允许AI直接访问整个客户数据库，不如提供一个只能查询指定客户必要字段的业务API。对转账、删除数据、修改权限、发布内容和向外部发送文件等高风险动作，则应增加人工确认或二次审批。
这种确认不能只是弹出一个含糊的“是否继续”。界面应明确显示AI准备调用什么系统、处理哪些数据以及执行什么动作，让审批人能够理解实际影响。

提示注入可能把正常权限变成攻击工具

AI需要读取邮件、网页、文档和知识库来完成任务，但这些内容并不一定可信。攻击者可能把恶意指令隐藏在网页、附件或文档中，诱导AI忽略原有要求、调用其他工具或向外发送数据，这类风险通常被称为间接提示注入。
即使AI只拥有完成工作所需的权限，恶意内容仍可能借用这些正常权限执行错误操作。因此，最小权限虽然重要，却不能单独解决AI安全问题。
企业不应把外部内容中的文字直接当成系统指令，也不能只依靠提示词告诉模型“不要泄露数据”。来自用户的目标、系统制定的规则和外部资料应保持清晰边界。AI调用工具前，还需要由模型之外的策略控制层再次检查操作是否允许。

防止数据越权，需要控制输入、检索和输出

数据风险并不只发生在AI读取数据库时。用户输入、检索增强生成使用的知识库、AI长期记忆、工具返回结果和模型最终输出，都可能包含敏感信息。
企业首先应减少不必要的数据暴露。AI只获得完成当前任务所需的字段和记录，而不是把整个文档库或数据库一次性交给模型。知识库检索也要继承原系统的用户、部门和租户权限，不能因为接入AI后绕过原有控制。
其次要限制长期记忆。对话中的身份证号、账号信息、合同内容和访问凭证，不应在缺少明确规则的情况下写入可长期调用的记忆库。不同用户、部门和客户之间的记忆数据还应隔离，避免后续对话错误引用他人的信息。
在输出阶段，企业可以识别个人信息、财务数据、源代码和访问凭证，并根据策略执行脱敏、阻断或记录。但输出检查只能作为补充，真正有效的数据保护仍要从源头限制AI能够访问的数据范围。

对高风险任务保留人工控制

AI适合自动处理重复、低风险和可恢复的任务，但并非所有操作都适合完全自主执行。
企业可以按照业务影响划分自动化等级。普通资料检索和内容整理可以自动完成；客户信息变更、外部邮件发送和生产配置调整需要用户确认；资金操作、权限分配和批量删除等任务则应设置更严格的审批流程。
同时，还要为AI设置明确的停止条件，例如连续调用失败、请求数据量异常、访问多个不相关系统或尝试绕过策略时，应暂停任务并转交人工处理。限制单次任务的调用次数、持续时间和数据量，也有助于控制异常行为的影响范围。

审计记录要能还原AI的完整行动链

传统日志通常只记录一次API调用，但AI任务可能包含多个计划步骤、子AI和工具。如果审计记录彼此分散，安全团队只能看到最终结果，无法判断AI为什么做出某个决定。
企业需要记录任务发起人、AI身份、使用的模型与版本、调用过的工具、访问的数据范围、执行结果、策略判断和人工审批情况。涉及多个AI协作时，还要记录任务是如何转交的，以及下游AI继承了哪些权限。
完整记录并不等于无限保存所有提示和业务数据。企业仍应根据数据敏感程度设置脱敏、访问权限和保存期限，在可审计与隐私保护之间取得平衡。

F5如何支持AI运行阶段的安全控制

AI的身份和业务权限仍需由企业身份系统、应用及数据平台共同管理，运行时安全能力则可以帮助企业观察和限制模型、AI与数据之间的交互。F5 AI Guardrails 可针对AI模型、AI和数据交互设置运行时策略，识别提示注入、敏感数据泄露和不符合要求的输出，并根据策略采取相应措施。F5 AI Red Team 用于主动测试AI系统中的攻击路径，再将发现的问题转化为运行时防护规则。
对于通过API连接模型、工具和数据源的AI应用，F5 Distributed Cloud API Security 可提供 API发现、监测和保护；F5 AI Gateway 则可在提示与响应传输过程中识别个人信息、财务数据、源代码等敏感内容，并执行记录、脱敏或阻断。
这些能力不能代替身份授权设计。企业仍需先明确AI可以代表谁、调用哪些工具和访问哪些数据，再通过运行时检查、API安全和持续测试降低策略被绕过的风险。

AI安全需要从“保护模型”走向“约束行动”

AI带来的主要变化，是AI开始拥有调用工具和改变业务状态的能力。企业如果仍然只关注模型输出是否合规，就可能忽略机器身份、权限继承和数据访问中的真实风险。
防范AI越权，需要让每个AI都有明确身份，让每次工具调用都经过授权，让敏感数据始终受到原有权限边界约束，并为高风险操作保留人工确认。同时，企业还要通过运行时监测和持续测试发现新的攻击方式。
真正可靠的AI安全，并不是要求AI永远不犯错，而是确保它即使受到误导或判断失误，也只能在可控范围内行动。

常见问题

1. "Security for AI" 和 "AI for Security" 之间有何本质区别？
面向 AI 的安全（Security for AI）聚焦于保护 AI 应用、模型、代理式AI与数据，抵御提示注入、越狱、数据泄露以及模型滥用等 AI 特有威胁。用于安全的 AI（AI for Security）则利用 AI 技术增强传统安全运营，例如更快速的威胁检测或自动化分诊。 F5 将面向 AI 的安全置于优先位置，通过在任何环境中提供运行时防护、定制化护栏与自动化测试，确保 AI 系统在规模化落地时依然安全、合规且可信。

2. AI 安全解决方案如何防御提示注入（prompt injection）和越狱（jailbreaking）？
AI 安全解决方案通过在运行时实施防护栏，在实时检测提示词、上下文、工具调用和输出的同时，防御提示注入与越狱攻击。 F5 采用分层防御，识别恶意意图、阻断策略绕过尝试，并防止未授权访问数据——无需重新训练模型。自动化红队测试持续验证新的攻击模式，并将发现转化为主动防护，使防御能力能够随威胁演进而自适应。

3. 实施 AI 驱动的安全运营相比传统 SIEM 的投资回报率（ROI）是多少？
与传统 SIEM 相比，AI 驱动的安全运营可实现更快的检测速度、更低的运营开销，并降低事件影响。 AI 安全解决方案不再依赖静态规则和人工分析，而是通过自动化安全漏洞发现、优先处置真实风险，并实时自适应调整防御。借助 F5，企业可减少高成本的重复培训周期，限制数据泄露与停机，并加速安全采用 AI——以更低风险与更高运营效率实现可量化的 ROI。