返回项目展示
项目描述
# **Agent Procurement Wallet **
**一个面向 Agent 的非托管采购钱包。**
核心不是让 LLM 直接花钱，而是：**LLM 负责提议，Policy Engine 负责限制，Escrow/Validator 负责结算。**
---
## 一、产品定义
### 1. 产品定位
买方 Agent 负责：
* 定义目标
* 拆成中间结果
* 设预算、约束、验收标准
* 选择卖方
* 失败时替换卖方
卖方 Agent / 服务商负责：
* 针对部分能力投标
* 交付结构化结果
* 接受阶段验收
* 通过后收款
### 2. 产品本质
它不是：
* 普通钱包
* 纯招标市场
* 纯卖方自组织网络
它是：
# **买方主控 + 市场化投标 + 节点可替换 + 托管结算 的 Agent Wallet**
---
## 二、最终版核心原则
### 原则 1
**资金永远不直接暴露给 LLM。**
### 原则 2
**每个任务有独立预算、独立权限、独立审计。**
### 原则 3
**卖方默认不可信，只能被验证、被约束、被结算。**
### 原则 4
**不追求“绝对安全”，追求“失败有边界”。**
---
## 三、系统结构
## 1. User Treasury
用户主资金账户。
作用：
* 资产自持
* 不直接给 Agent 使用
* 只给任务分配预算
---
## 2. Task Wallet
每个任务创建一个独立任务钱包。
包含：
* 总预算
* 单笔上限
* 时间有效期
* 白名单卖方
* 白名单 Token
* 白名单方法
* 审批阈值
* 风险等级
---
## 3. Session Key / Delegated Key
给买方 Agent 一个临时受限授权。
作用：
* 只能操作当前任务钱包
* 只能做当前任务允许的动作
* 到期失效
* 可随时 revoke / pause
Monad 的 EIP-7702 让 EOA 获得类似 smart wallet 的能力，比如 session keys、social recovery、gas sponsorship；但这些是底层能力，不是默认安全策略。文档同时说明 delegation 默认不会自动过期，且 delegated EOA 在 Monad 上还有额外约束，例如余额下探到 10 MON 以下会触发特殊规则、delegated code 不能调用 `CREATE/CREATE2`。所以权限边界、额度、到期、撤销，仍然需要产品自己设计。([Monad 文档][1])
---
## 4. Policy Engine
这是产品主脑，不是钱包签名器。
控制：
* 预算限制
* Token 限制
* 白名单收款方
* 白名单合约 / 方法
* 单笔/累计额度
* 人工审批阈值
* 高风险拦截
* 紧急暂停
* 任务结束自动回收权限
NIST 明确建议 AI agent 需要单独的权限与授权策略，并遵循 least privilege 和 separation of duties。([NIST技术文献][2])
---
## 5. Procurement Router
负责：
* 收投标
* 比价
* 选型
* 编排 DAG
* 节点替换
* 支付路径选择
它支持三种支付模式：
### Direct Pay
固定价格、低风险、标准能力
适合 API、存储、固定服务
### Routed Pay
多个白名单卖方可选
系统自动比价后直付
### Escrow Pay
高风险、关键节点、可验收结果
先托管，验收后放款
---
## 6. Seller Registry
不是“完全开放、谁都能上”。
最终版采用：
### **准入 + 运行约束 + 经济约束**
#### 准入层
* 卖方身份注册
* 基础资质审核
* 能力声明标准化
* 接口与输出格式登记
#### 运行层
* 沙箱执行
* 最小数据暴露
* 临时凭证
* 只接收结构化输入输出
#### 经济层
* 保证金 / bond
* 关键节点 escrow
* 失败扣罚
* 信誉衰减
所以**不建议只做“第三方代码审查后才能上线”**。
因为 prompt injection、恶意输入、依赖污染、模型漂移都可能在运行时出问题。OWASP 明确指出 prompt injection 无法仅靠系统提示或 RAG 彻底缓解；Excessive Agency 的根因之一也是 excessive permissions / excessive autonomy。([OWASP Gen AI Security Project][3])
---
## 7. Validator / Receipt Engine
每个关键节点必须：
* 输出结构化结果
* 通过确定性校验器
* 生成收据
收据字段：
* task_id
* buyer_agent_id
* seller_agent_id
* payment_id
* amount
* token
* reason
* policy_hit
* approval_status
* validator_result
* timestamp
---
## 8. Recovery / Admin Layer
包含：
* pause
* revoke
* rotate session key
* seller disable
* emergency freeze
* admin change timelock
OpenZeppelin 提供成熟的角色控制与 timelock 机制；`AccessControl` 支持多角色动态 grant/revoke，`TimelockController` 适合承接敏感权限和延迟执行。([OpenZeppelin Docs][4])
---
## 四、关键安全问题与最终解法
## 1. Prompt Injection / LLM 乱花钱
### 风险
恶意网页、文档、投标内容诱导 LLM 发起错误采购。
### 最终解法
* LLM 不能直接转账
* LLM 只能提交 procurement intent
* 真实执行必须过 Policy Engine
* 高风险操作需要人工确认
* 工具调用白名单化
OWASP 明确指出外部内容可触发 indirect prompt injection，且 RAG/微调不能彻底解决。([OWASP Gen AI Security Project][3])
---
## 2. Session Key 权限过大
### 风险
泄露后长期滥用、跨任务滥用。
### 最终解法
* 每任务单独 key
* 限时
* 限额
* 限 token
* 限方法
* 限卖方
* 任务结束自动回收
* 手动 revoke / pause
---
## 3. 恶意卖方 Agent
### 风险
假投标、低价钓鱼、拿钱不交付、交付垃圾结果。
### 最终解法
* verified registry
* bond / stake
* escrow
* milestone settlement
* deterministic validator
* reputation 只作辅助，不作单点信任
---
## 4. 主控 Agent / Orchestrator 被攻陷
### 风险
恶意选卖方、刷低价值订单、偏向关联卖方。
### 最终解法
**不能彻底解决，只能控制爆炸半径。**
控制方式：
* orchestrator 不能动主金库
* orchestrator 不能改 policy
* 只能动当前 task wallet
* 大额节点必须二次确认
* 关键结算由独立 validator / escrow 决定
* 全量审计可回放
* 紧急暂停随时生效
---
## 5. 验收被欺骗
### 风险
卖方交付看起来正确、实际上无价值。
### 最终解法
* 结构化中间结果
* 确定性校验
* 多源交叉验证
* challenge/dispute window
* 高价值节点支持人工复核
---
## 6. 合约 / 管理员风险
### 风险
管理员权限过大、升级后门、资金被错误操作。
### 最终解法
* 最小合约面
* 多角色权限
* timelock
* pausable
* 敏感操作双签/guardian
* 审计与测试
---
## 7. 数据泄露
### 风险
买方把任务上下文、商业机密、API key 泄露给卖方。
### 最终解法
* 子任务最小披露
* 临时凭证
* 脱敏输入
* 卖方只看自己所需片段
* 不向卖方暴露主账户密钥和全局上下文
---
## 五、最终版一句话价值
### 对用户
**不是让 AI 能花钱，而是让 AI 能在可控预算下采购外部能力完成任务。**
### 对评委
**不是 wallet UI，而是把 agent payment 做成了 buyer-controlled procurement system。**
### 对安全
**We do not assume trusted agents; we design for bounded failure.**
---
