Agent 与金融信息安全能碰撞出哪些研究方向？从提示注入到交易授权的技术分析-迪斯科星球

Agent 与金融信息安全能碰撞出哪些研究方向？从提示注入到交易授权的技术分析

当 AI 从“回答问题”发展到“调用工具并执行任务”，金融应用的安全边界也随之发生变化。

一个金融问答助手回答错误，可能误导用户；一个拥有业务操作权限的 Agent 判断错误，则可能进一步造成数据泄露、错误操作或业务流程被绕过。

因此，Agent 与金融信息安全之间存在明确的交叉研究空间。

但研究不能只停留在“用大模型检测风险”。更值得讨论的是：

当系统允许模型根据自然语言选择工具、读取数据和安排操作时，如何保证它始终在正确的授权范围内执行任务？

本文从具体业务场景出发，分析几个具有研究价值的方向，并给出可落地的实验设计。下文的方案属于研究建议，不代表已经验证的实验结论。

一、先区分两类交叉研究

Agent 与金融信息安全的结合，可以分为两个方向。

方向	核心问题	示例
使用 Agent 提升安全能力	Agent 能否更有效地完成安全任务？	告警分析、事件调查、证据整理
保障金融 Agent 自身安全	Agent 如何在处理金融数据和操作时保持可信？	防止越权查询、提示注入、错误执行

这两类研究相互关联，但评价目标不同。

前者关注检测质量、调查效率和误报率；后者关注权限边界、数据流向和执行结果。

此外，金融信息安全与金融风险管理也不能完全混为一谈。预测贷款违约、分析市场波动，主要属于金融风险研究；保护客户数据、防止未授权操作和确保审计记录完整，才更直接对应信息安全。

二、为什么 Agent 会改变金融应用的攻击面？

考虑一个企业财务助手：

读取付款申请 ↓ 核对合同和发票 ↓ 查询供应商信息 ↓ 生成付款指令 ↓ 提交审核

这个流程同时接触：

用户的合法指令。
外部提交的合同和附件。
内部数据库。
具有业务权限的工具。
人工审核结果。

传统程序通常按照预先编写的控制逻辑处理数据。Agent 则可能根据读取到的文本动态决定下一步行动。

如果外部附件中的文字被错误地当成操作指令，数据就可能影响执行流程。

NIST 将 Agent 劫持问题与“可信内部指令和不可信外部数据缺乏清晰分离”联系起来，这也说明它与传统安全中的信任边界问题具有连续性。NIST：Agent 劫持评估

金融场景中的特殊之处，是这些边界后面连接着敏感信息和具有实际业务后果的操作。

三、方向一：面向金融文档的间接提示注入防御

1. 研究问题是什么？

假设财务 Agent 需要从供应商提交的附件中提取付款信息。

附件是业务数据来源，但不应该拥有修改系统规则的权限。

如果附件中包含试图改变任务目标、绕过核验或引导输出敏感数据的内容，Agent 是否会受到影响？

这就是一个可以研究的具体问题：

如何允许 Agent 正常理解金融文档，同时阻止文档中的非授权指令影响工具执行？

这里需要区分：

文档中的事实，例如合同金额。
文档中的业务声明，例如供应商声称账户已变更。
真正有效的操作授权，例如经过验证的审批记录。

前两者都不应自动升级为第三者。

2. 可以研究哪些防御方式？

可以比较三类方案：

方案	核心思路	可能的局限
提示词约束	明确说明附件内容不构成授权	仍依赖模型正确遵循
内容检测	识别可疑指令并标记或隔离	可能误报，也可能漏报
执行层约束	工具调用必须满足独立业务策略	需要明确、完整的策略定义

更有价值的研究，不是单独证明某个提示词“有效”，而是分析这些方案如何组合，以及组合后会损失多少正常业务能力。

例如，系统可以允许模型提取附件里的新账户信息，但要求通过独立的供应商账户变更流程验证，不能直接用于付款。

3. 怎样做实验？

在隔离环境中建立模拟财务流程，使用合成合同、发票和供应商信息。

明确攻击者只能修改某些外部附件，不能修改系统提示、权限配置或审批数据库。

然后分别测试：

无恶意内容时，任务能否完成。
存在恶意内容时，模型是否提出违规调用。
执行层是否阻止违规操作。
最终数据库是否发生未经授权的变化。

可以参考 AgentDojo 的动态评估思路。它包含电子银行等工具使用场景，但通用银行任务仍不能完全代表真实机构的财务流程。AgentDojo 论文

潜在选题：

面向金融文档处理智能体的间接提示注入防御与安全—效用评估。

四、方向二：面向任务的最小权限与动态授权

1. 用户有权限，为什么 Agent 仍可能越权？

假设某个财务人员拥有查询流水、维护供应商和提交付款申请的权限。

这不代表他每次让 Agent 工作时，都授权 Agent 使用全部能力。

例如，用户只提出：

汇总上个月的付款情况。

当前任务需要查询和汇总，不需要修改供应商账户。

因此，可以区分三层权限：

用户长期拥有的权限 ↓ 当前任务被授予的权限 ↓ 当前步骤允许使用的权限

一个值得研究的问题是：

如何将用户的自然语言任务，转换为可以由程序执行和检查的有限授权？

OWASP 的 Agent 安全资料也强调最小权限、工具授权和执行监控，但将其细化到金融业务，仍需要处理账户、金额、对象和审批状态等约束。OWASP Agent 安全指南

2. 权限不能只限制工具名称

仅允许调用submit_payment，并不能说明任何付款参数都合理。

更细的策略可能包含：

{ "task_id": "task_1024", "allowed_tools": ["query_invoice", "prepare_payment"], "source_account": "account_A", "allowed_payees": ["supplier_17"], "currency": "CNY", "max_total_amount_minor": 500000, "expires_at": "2026-10-01T10:00:00Z" }

这个例子中的金额按最小货币单位表示，具体币种精度需要由系统定义。

它只是授权结构示意。真正的权限必须来自可信身份和业务流程，不能让模型自行生成后直接生效。

3. 更有研究价值的是“累计约束”

假设系统限制单次操作金额，但没有限制任务总额。多次分别符合单次规则的调用，合起来仍可能超出授权范围。

因此，金融 Agent 的权限检查往往需要考虑整个执行轨迹：

同时还要处理并发：多个操作同时通过检查时，额度预留和扣减需要具备原子性。

这使问题从“检查一个 API 参数”，进一步变成“约束一个持续执行的任务”。

4. 如何证明研究贡献？

可以比较：

固定角色权限。
任务级静态权限。
随步骤变化的权限。
包含累计约束的任务级权限。

评价越权操作率、正常任务完成率、人工介入次数和授权检查开销。

潜在选题：

面向金融工具调用智能体的任务级授权与累计风险约束方法。

五、方向三：敏感金融数据在检索、记忆与多 Agent 协作中的传播控制

1. 查得到，不代表可以发出去

一个 Agent 可能有权读取客户资料，用于内部分析；但它未必有权将原始资料写进报告、发送邮件，或者传递给另一个服务。

这说明两种权限需要分开：

数据读取权限。
数据使用与传播权限。

在 Agent 系统中，数据可能经历：

数据库 → 检索片段 → 模型上下文 → 摘要 → 长期记忆 → 子 Agent → 最终报告

每一步都可能改变内容形式，也可能让原始的敏感标签丢失。

2. 可以研究“带来源的数据流”

给数据附加元信息，例如：

{ "record_id": "record_08", "classification": "customer_sensitive", "allowed_purpose": "internal_reconciliation", "source": "customer_database", "allowed_destinations": ["internal_report"] }

然后研究标签如何随以下操作传播：

摘要。
多份资料合并。
数值聚合。
Agent 间消息传递。
长期记忆写入。
文件导出。

最难的情况往往不是原文复制，而是模型将敏感信息改写成了新的表达。

例如，摘要删除了姓名，却保留了能够与其他资料关联的独特交易信息。此时“没有姓名”并不必然意味着无法识别个人。

3. 标签机制也存在局限

如果完全依靠另一个模型判断输出是否敏感，仍然可能误判。

可探索的方案包括：

在数据进入模型前进行字段级最小化。
对导出目标施加独立限制。
保留证据来源与数据分类。
将可识别原始数据限制在受控计算环境中。
对需要精确结果的任务使用确定性工具完成聚合。

“部署在本地”可以改变数据暴露范围，但不会自动解决内部越权、日志泄露和跨任务记忆污染。

4. 如何评估？

同时测试合法分析能力与泄露风险：

合成敏感标识的原样泄露率。
改写后的语义泄露率。
跨用户、跨任务信息串用率。
合法报告被错误阻止的比例。
任务准确率和延迟。

只测模型是否输出了某个固定字符串，会漏掉改写、组合和推断形式的泄露。

潜在选题：

面向多智能体金融分析流程的敏感信息传播追踪与输出控制。

六、方向四：把人工确认从一句“同意”变成可验证的授权

1. 人工参与为什么仍然可能出错？

很多系统把人工确认设计成：

是否同意继续？

但用户到底批准了什么？

如果用户看到的只是模型总结，而最终执行参数发生变化，人工确认就可能失去意义。

例如：

审核时：向供应商 A 提交付款申请 执行时：收款账户已经被替换

研究重点可以放在：

如何证明最终执行的操作，与用户实际审阅并批准的操作一致？

2. 可以绑定哪些内容？

审批对象可以包含：

操作类型。
付款账户与收款对象。
金额和币种。
依据文件版本。
工具参数版本。
有效期和一次性操作标识。

执行前重新检查这些内容，以及当前业务状态。

参数发生实质变化时，原批准不应自动适用。

但参数哈希本身不能证明用户理解了操作。审批界面仍然需要清晰呈现关键字段，不能只展示一个不可读的哈希值。

3. 可研究的核心问题

这一方向同时涉及信息安全与人机交互：

展示原始参数、自然语言说明，还是两者结合？
哪些变化需要重新确认？
如何降低重复确认导致的审批疲劳？
如何防止批准被重复使用？
批准后、执行前业务状态变化，应该怎样处理？

可以通过模拟业务实验比较不同审批界面的错误批准率、完成时间和用户理解程度。

潜在选题：

面向金融 Agent 的意图—审批—执行一致性验证机制。

七、方向五：使用 Agent 辅助金融安全事件调查

前面几个方向是在保护 Agent，这个方向则是用 Agent 帮助安全人员工作。

例如，系统发现：

异常登录 → 查询大量客户资料 → 发起批量导出

Agent 可以协助读取日志、串联时间线、检索处置手册，并整理待核查证据。

但它的价值不能只通过“报告写得像专家”来判断。

更合适的研究问题是：

在相同证据和工具条件下，Agent 能否提高事件调查质量，并减少无效操作？

可以比较：

方案	特点
固定规则	稳定、易解释，但适应范围有限
单次模型分析	实现简单，但不能主动补充证据
固定工具工作流	步骤可控
Agent 自主调查	能动态选择查询，但执行路径更复杂

评价指标应包括证据引用正确率、遗漏率、误报率、调查时间和工具调用成本。

自动封禁账户、删除数据等处置动作，应与分析报告分开评估。发现可疑行为，不等于已经有足够依据执行破坏性处置。

潜在选题：

基于证据约束的金融安全事件调查智能体及其可验证性评估。

八、怎样把方向缩小为一个可执行的课题？

如果希望同时兼顾论文探索与工程实现，可以优先选择：

金融文档处理 Agent 的提示注入防御与任务级授权。

它的边界相对明确，也容易搭建实验环境。

1. 构建模拟业务

使用合成数据模拟：

读取申请 → 核对发票 → 查询供应商 → 生成付款草稿 → 审核 → 模拟提交

无需连接真实银行或使用真实客户信息。

2. 明确威胁模型

例如规定：

攻击者只能控制供应商附件。
不能修改用户会话和权限策略。
不能访问审批服务密钥。
目标是诱导未经授权的数据输出或业务变化。

如果不限定攻击者能力，不同方案的测试结果就很难比较。

3. 设置对照组

可以设计四组：

基础 Agent。
加入安全提示词。
增加内容检测。
增加独立任务级授权。

必要时继续比较组合方案。

4. 同时评估安全与可用性

指标	含义
攻击成功率	最终环境出现攻击目标的比例
正常任务完成率	无攻击时合法任务成功的比例
攻击下任务完成率	有攻击时仍完成原任务的比例
错误阻断率	合法操作被阻止的比例
人工介入率	需要额外审核的比例
执行开销	延迟、调用次数和推理成本

还应区分：

模型提出违规操作

与：

违规操作真正执行成功

前者说明模型层被影响，后者说明系统防线被突破。把二者合并统计，会掩盖执行层防护的作用。

5. 避免评估只对固定样例有效

实验应包含未参与方案设计的文档、任务和攻击变体，固定模型与代码版本，并进行重复运行。

如果要声称具有较强防御能力，还需要考虑了解防御机制的攻击者，而不能只测试几段固定文本。NIST 对 Agent 劫持评估的讨论，也强调了更充分攻击测试的重要性。NIST 评估说明

九、真正的研究价值在哪里？

Agent 与金融信息安全的交叉点，已经超出了“识别一句话是否危险”。

更具体的问题是：

不可信文档能否改变执行目标？
授权能否精确到任务和累计操作？
敏感数据在摘要和协作后是否仍受控制？
人工批准能否与最终执行保持一致？
安全调查结论能否追溯到真实证据？

这些问题既继承了访问控制、信息流安全和审计等传统研究，也增加了模型决策不确定性、自然语言授权和多步骤执行的新难点。

不过，搭建一个 Agent 加规则引擎，并不自动构成研究创新。需要进一步提出可检验的方法、与已有方案比较，并说明安全收益、业务代价和适用边界。

更有研究价值的目标是：让金融 Agent 的每一次数据访问和业务操作，都能说明依据、验证授权，并在失败时留下可核查的结果。

企业官网建设流程全解析