Alguard：为AI代理购物打造双层级信任防线

当你的AI助手可以"直接买"的时候，谁来决定这笔钱该不该花？这是Amazon Developer Hackathon参赛项目Alguard试图回答的核心问题。该项目针对Alexa+场景，提出了一套双层级信任架构，用结构性隔离而非提示词约束来阻断代理购物中的prompt注入风险。

问题：能花钱的代理必然可被注入

一个被授权控制资金的AI代理，本质上就是一个可被prompt注入攻击的目标。传统防御手段——无论是LLM guardrail还是系统提示词——都属于建议性约束，足够巧妙的注入攻击总能绕过。作者在项目说明中直言：如果Alexa+真的能做到"一句话就买"，那么失败模式的代价就是真金白银的损失。

这并非危言耸听。代理购物的攻击面比传统支付场景更宽：攻击者可以通过恶意网页内容、伪造的商家信息、甚至多轮对话中的语义操纵来诱导代理执行未经授权的购买。仅靠"告诉模型不要这样做"，在安全工程上等同于没有防线。

核心不变量：请求方与审批方必须分离

Alguard的设计围绕一条结构性规则展开：

发起高风险操作的系统，永远不是批准该操作的系统。

这条规则不是写在prompt里的，而是刻进整个服务架构里的。它不是建议，而是物理约束。这意味着即使攻击者完全控制了代理的推理过程，也无法触及审批通道——因为审批通道根本不在代理能访问的网络路径上。

双层级架构：MCP服务器与人工通道的物理隔离

Tier 1：MCP服务器（代理侧）

第一层是一个MCP服务器（mcp_server/server.py），通过Streamable HTTP暴露三个工具：

• attempt_purchase——发起购买尝试
• get_session_status——查询会话状态
• get_audit_trail——获取审计日志

关键设计在于：没有approve工具。它不是被隐藏了，也不是被guardrail保护了，而是根本不存在于工具schema中。代理在协议层面就没有批准自己请求的能力。

MCP（Model Context Protocol，模型上下文协议）是Anthropic于2024年11月开源的标准化协议，用于让LLM应用以统一方式连接外部工具、数据源和服务。它解决了过去每个AI应用都要为不同工具写定制集成代码的碎片化问题：工具提供方只需实现一次MCP服务器，任何兼容MCP的客户端（Claude Desktop、IDE插件、自研代理）都能直接调用。MCP服务器通过标准传输层暴露"工具（tools）""资源（resources）""提示（prompts）"三类能力，其中tools是最常被用于赋予AI代理执行能力（如调用API、操作数据库、发起支付）的一类。文中Alguard正是利用MCP server暴露attempt_purchase等工具给代理调用，并通过Streamable HTTP传输（MCP在2024年底引入的传输方式，取代早期的SSE方案）让代理侧与服务器通信。理解MCP的关键在于：工具的schema就是能力边界，未出现在schema中的能力代理无法调用——这为结构性隔离提供了协议级支撑。

Tier 2：人工审批通道（用户侧）

第二层是一个独立的FastAPI服务（web_api/resolve_action.py），运行在8010端口，拥有独立的OAuth audience和独立的approve scope。这是唯一能解除HALTED状态的地方。

两层之间没有任何网络路径连通。用户需要手动携带action_id在人工通道中完成审批。这个看似"不方便"的设计，恰恰是安全性的来源：代理无法自动化地完成"请求-批准"闭环。

OAuth audience与scope是OAuth 2.0授权框架中的两个核心概念。scope定义令牌被授予的权限范围（如read:profile、approve），而audience（aud参数）限定令牌的预期接收方——一个audience为A服务的令牌，B服务应当拒绝接受，即便令牌本身未过期且签名有效。Alguard给人工审批通道配置独立的audience和独立的approve scope，意味着即便攻击者拿到了代理侧的令牌，该令牌也无法在审批通道生效：令牌的audience不匹配会被直接拒绝。这是一种纵深防御——即便物理网络隔离被突破，认证层的隔离仍然兜底。在代理场景中，为不同信任层分配不同audience/scope是常见的权限分区实践，通常与最小权限原则（least privilege）配合使用。

风险引擎：多维度评分与硬规则兜底

每次购买尝试都会经过一套评分体系：

• 品类严重度——礼品卡、加密货币、电汇属于高风险；日用品属于低风险
• 异常检测——新商家、金额相对历史飙升、频率异常、HALT后重试
• 所有者信任分——批准时+0.03，拒绝时-0.15

在此之上还有一组硬规则，无论信任分多高都无法绕过：单笔超过$1000、每小时超过$1500、24小时内超过$3000、高风险品类、24小时内HALT后重试、未审批商家消费$250。这些硬规则的存在意味着，即使攻击者成功提升了信任分，也无法突破金额和品类的绝对上限。

工程难点：并发、崩溃一致性与跨进程去重

项目说明中特别提到了几个让实现变难的点：

并发审批。 两个并发的批准请求必须只有一个成功。解决方案是单条条件UPDATE配合rowcount == 1检查，用数据库原子性保证互斥。

崩溃一致性。 如果进程在"已批准"和"已履约"之间崩溃，reconcile_unfulfilled()会在启动时幂等地修复状态。

跨进程去重。 进程内锁只是快速路径，真正的保证来自insert_action_if_not_duplicate()，它在BEGIN IMMEDIATE事务内完成检查加插入。

Bedrock是非关键依赖。 解释文本由Bedrock的converse生成，但Bedrock故障永远不会改变决策结果——降级模板会诚实标注source = local-fallback。

BEGIN IMMEDIATE是SQLite的事务启动模式之一。SQLite支持三种BEGIN模式：DEFERRED（默认，读时才加锁）、IMMEDIATE（立即申请写锁，其他写事务阻塞）、EXCLUSIVE（申请排他锁，阻断所有读写）。BEGIN IMMEDIATE的关键价值在于在事务一开始就获得写锁，避免"先读后写"场景下的竞态：如果两个进程同时用DEFERRED模式做"检查是否存在→不存在则插入"，两者可能都读到"不存在"，随后其一写入成功、另一写入失败或产生重复。使用IMMEDIATE后，第二个进程在BEGIN阶段就被阻塞，直到第一个事务结束，从而保证"检查+插入"的原子性。文中insert_action_if_not_duplicate()正是用这一模式实现跨进程去重，这是SQLite在多进程环境下实现幂等写入的标准手法。相比之下，进程内锁（threading.Lock等）只在单进程内有效，多进程部署时会失效。

红队测试：15种攻击全部拦截

项目包含一个红队演示脚本（demo/showcase.py），模拟敌对代理会尝试的15种攻击：品类撒谎、通过重试洗白HALT状态、session_id轮换、NaN金额、连续超额消费等。所有攻击均被拦截，输出ALL ATTACKS HANDLED。

这组测试覆盖了代理购物场景中最典型的绕过手法。品类撒谎试图绕过风险评分，重试洗白试图利用状态机漏洞，NaN金额则是典型的输入验证攻击——这些在传统支付系统中也常见，但在代理场景下攻击者可以自动化地高频尝试。

后续方向

作者列出了四个下一步计划：将resolve_pending_action接入真实扣款（Checkout / ChargePermissionId）、用MCC数据替换文本启发式品类推断、将共享SQLite拆分为按层独立存储、加入基于EWMA的漂移检测（当前检查能捕捉突变但捕捉不到缓慢上升的漂移）。

最后一点尤其值得关注：当前的异常检测基于阈值比对，但攻击者完全可以通过多次小额消费逐步抬高基线，让后续的大额消费显得"正常"。EWMA漂移检测正是针对这类慢速攻击的补充。

EWMA（Exponentially Weighted Moving Average，指数加权移动平均）是一种赋予近期数据更高权重的平滑统计方法，公式形如 S_t = α·x_t + (1-α)·S_{t-1}，其中α控制对新数据的敏感度。相比简单滑动窗口平均，EWMA对近期变化响应更快，同时保留历史趋势，常用于时序监控、异常检测与金融信号处理。在欺诈与滥用检测中，EWMA可追踪用户或会话的"行为基线"（如平均消费金额、交易间隔），当实时值显著偏离基线时触发告警。文中提到当前基于阈值的检测能捕捉突变（一次性大额消费）但捕捉不到缓慢漂移（攻击者用多次小额消费逐步抬高基线后再来一笔大额），EWMA正是针对这一盲区的常见补充手段——它能敏锐捕捉基线的移动方向与速度。常与EWMA配合的还有CUSUM（累积和）算法，两者都擅长检测缓慢漂移型异常。

结构性安全 vs 提示词安全

Alguard的价值不在于它的功能有多丰富，而在于它示范了一种思路：对于高风险代理操作，安全性应该来自架构约束而非模型对齐。当代理能够控制真实资金时，"相信模型会遵守指令"不是一个可接受的假设。把审批权从代理的可达范围内物理移除，比任何prompt engineering都更可靠。

这套模式可以推广到代理场景下的其他高风险操作：删除数据、发送邮件、修改配置。核心原则是一致的——请求方永远不应该同时是审批方。