> **本文解决什么问题**：当 AI Agent 开始代表用户调用你的后端接口（查订单、发起退款、提交工单），把用户的长期 token 直接交给它是最省事也最危险的做法。本文给出一套可复现的 Java 实现：**签发短期令牌、按调用链逐级降权、高风险操作强制人工确认**，并配套审计与测试。 **适合谁读**：已有 Spring Boot + Spring Security 基础、正在把 Agent 接入真实业务接口的后端开发者。 **能收获什么**：三个可直接改造的组件（令牌签发服务、降权规则、确认闸门），一份威胁对照表，以及一套判断"哪些接口能给 Agent、哪些绝对不能"的清单。

## 一、先看风向：为什么这件事突然变成了刚需

最近两条信息值得后端同学注意。

一条是支付侧。Skyfire 与 Forter 已经在电商结账链路里实现 **Agent 身份识别与风控集成**，Visa 推出了面向 B2B 发票支付的**可信 Agent 协议**；Stripe 披露通过 Link 完成的 agentic 购买在**一个月内增长了 38 倍**。

另一条更关键：**国内在监管口径上明确不认可"GUI 读屏式自动化"**，要求 Agent 的接口调用基于**短期令牌、最小权限与人工确认**。

这两条合起来指向同一个结论：**Agent 不会去"模拟人点按钮"，它会带着凭证直接调你的 API。** 而你的 API 现在大概率只区分"登录用户"和"未登录"，根本没有为"某个 Agent 代表某个人"这种第三类调用主体做准备。

先明确本文的技术边界：不涉及具体厂商的支付协议对接（那些需要商务准入），只解决**你自己的后端如何安全地接受一个被委托的调用方**。

## 二、把威胁说清楚：长期 token 交给 Agent 会出什么事

| 风险 | 具体表现 | 长期 token 的问题 | 对策 |
| --- | --- | --- | --- |
| 凭证外泄面扩大 | token 进入模型上下文、日志、Agent 的记忆文件 | 有效期长，泄露即长期可用 | 短期令牌（分钟级） |
| 权限越界 | Agent 顺手调了它不该调的接口 | 用户有权限 = Agent 有权限 | 按调用链降权 |
| 不可逆操作 | 删数据、转账、批量改配置 | 一次误判无法撤回 | 人工确认闸门 |
| 责任无法追溯 | 出了事说不清是谁干的 | 只有 userId | 记录 agentId + 委托链 |
| 重复执行 | 超时重试导致重复下单 | 无幂等约束 | 幂等键 + 去重 |

这里有个容易被忽略的点：**权限降权必须是"单调递减"的**。子 token 的 scope 只能是父 token scope 的子集，一旦允许"申请更多权限"，最小权限原则就形同虚设。

## 三、整体设计

```bash
用户登录（拿到用户级 token，scope 全集）
        ↓
Agent 发起委托申请（带上要做的任务描述）
        ↓
令牌签发服务：计算降权后的 scope + 设置短有效期 → 签发 delegated token
        ↓
Agent 带 delegated token 调业务接口
        ↓
资源服务器校验：签名 → 有效期 → scope → 是否需要人工确认
        ↓
   ┌────┴────┐
 低风险     高风险
 直接执行   返回 202 + confirmationId
              ↓
        用户在前端确认 → 二次提交 → 执行
```

**环境说明**（本文代码基于以下版本验证，其他版本注意 API 差异）：

-   JDK 21
-   Spring Boot 3.3.x
-   Spring Security 6.3.x（OAuth2 Resource Server）
-   jjwt 0.12.x 或等价 JWT 库

## 四、核心实现

### 4.1 令牌模型：把"委托关系"写进 claims

普通 JWT 只有 `sub`。委托令牌必须额外携带三样东西：**谁在执行（agentId）、代表谁（onBehalfOf）、权限从哪来（parentJti）**。

```java
public record DelegatedClaims(
        String agentId,        // 执行方：哪个 Agent
        String onBehalfOf,     // 被代表方：哪个用户
        String parentJti,      // 父 token 的 jti，用于追溯委托链
        Set<String> scopes,    // 已降权的权限集
        Instant expiresAt      // 短期有效期
) {
    public boolean isExpired(Instant now) {
        return !now.isBefore(expiresAt);
    }
}
```

`parentJti` 是审计的关键。出事故时，你能顺着它把"哪个用户授权了哪个 Agent 做了什么"整条链拉出来。

### 4.2 降权规则：用声明式配置，别写死在 if 里

降权逻辑散落在代码里是维护灾难。建议抽成一张**能力清单**，明确每个 scope 对 Agent 是否可用、默认存活多久。

```java
public enum RiskLevel { READ_ONLY, REVERSIBLE, IRREVERSIBLE }

public record Capability(String scope, RiskLevel risk, Duration maxTtl) {}

@Service
public class CapabilityCatalog {

    private final Map<String, Capability> byScope = new LinkedHashMap<>();

    @PostConstruct
    void init() {
        register(new Capability("order:read",   RiskLevel.READ_ONLY,    Duration.ofMinutes(5)));
        register(new Capability("order:create", RiskLevel.REVERSIBLE,   Duration.ofMinutes(2)));
        register(new Capability("refund:create",RiskLevel.IRREVERSIBLE, Duration.ofMinutes(1)));
        register(new Capability("user:delete",  RiskLevel.IRREVERSIBLE, Duration.ZERO)); // 永不委托
    }

    public void register(Capability c) { byScope.put(c.scope(), c); }

    public Optional<Capability> find(String scope) {
        return Optional.ofNullable(byScope.get(scope));
    }

    /** TTL 为 0 表示该能力不允许委托给 Agent */
    public boolean delegatable(String scope) {
        return find(scope).map(c -> !c.maxTtl().isZero()).orElse(false);
    }
}
```

把 `user:delete` 的 `maxTtl` 设成 `Duration.ZERO`，是一个很实用的表达：**不是"忘了配"，而是显式声明"永不委托"**。这比在文档里写一句"请勿给 Agent 删除权限"可靠得多。

### 4.3 签发服务：强制单调降权 + 最短有效期

```java
@Service
public class DelegationService {

    private final CapabilityCatalog catalog;
    private final TokenSigner signer;

    public DelegationService(CapabilityCatalog catalog, TokenSigner signer) {
        this.catalog = catalog;
        this.signer = signer;
    }

    /**
     * @param requested  Agent 申请的权限集
     * @param grantedToUser 用户 token 里已有的权限集
     */
    public String issue(String agentId, String userId, String parentJti,
                        Set<String> grantedToUser, Set<String> requested,
                        Instant now) {

        // 1) 单调降权：只允许授予"用户已有 且 可委托"的交集
        Set<String> granted = requested.stream()
                .filter(grantedToUser::contains)
                .filter(catalog::delegatable)
                .collect(Collectors.toUnmodifiableSet());

        if (granted.isEmpty()) {
            throw new NoDelegatableScopeException(requested);
        }

        // 2) 有效期取所有申请权限里"最严格"的那个
        Duration ttl = granted.stream()
                .map(s -> catalog.find(s).orElseThrow().maxTtl())
                .min(Duration::compareTo)
                .orElseThrow();

        Instant expiresAt = now.plus(ttl);

        DelegatedClaims claims = new DelegatedClaims(
                agentId, userId, parentJti, granted, expiresAt);

        // 3) 审计：谁、代表谁、拿到什么、多久过期
        AuditLog.record(new AuditEntry(now, "TOKEN_ISSUED", agentId, userId,
                granted, expiresAt, parentJti));

        return signer.sign(claims);
    }
}
```

三个设计决策值得说明：

1.  **用 `filter` 而不是 `throw`**：Agent 多申请了权限时，静默丢弃不可委托的部分，只授予交集。这样 Agent 不会因为申请了 `user:delete` 就整个请求失败，同时权限也没变多。
2.  **TTL 取最小值**：一次申请 3 个 scope，有效期由最危险的那个决定。
3.  **签发即审计**：不要等到调用业务接口才记日志，令牌签发本身就是需要留痕的事件。

### 4.4 资源服务器校验

```java
@Component
public class DelegationTokenVerifier {

    private final TokenSigner signer;

    public DelegatedClaims verify(String token, String requiredScope, Instant now) {
        DelegatedClaims c = signer.parseAndVerify(token);   // 验签失败直接抛异常

        if (c.isExpired(now)) {
            throw new ExpiredDelegationTokenException(c.agentId());
        }
        if (!c.scopes().contains(requiredScope)) {
            throw new InsufficientScopeException(requiredScope, c.scopes());
        }
        return c;
    }
}
```

在 Spring Security 侧，把 `requiredScope` 用注解表达更清爽：

```java
@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @GetMapping("/{id}")
    @PreAuthorize("hasAuthority('SCOPE_order:read')")
    public OrderView get(@PathVariable String id) { /* ... */ }

    @PostMapping("/refund")
    @PreAuthorize("hasAuthority('SCOPE_refund:create')")
    public ResponseEntity<?> refund(@RequestBody RefundRequest req,
                                    @RequestHeader("Idempotency-Key") String key,
                                    Authentication auth) {
        RiskLevel risk = RiskLevel.IRREVERSIBLE;   // 来自 CapabilityCatalog

        if (risk == RiskLevel.IRREVERSIBLE) {
            String confirmationId = confirmationService.create(auth, req, key);
            return ResponseEntity.accepted()
                    .body(new ConfirmationRequired(confirmationId,
                            "该操作不可逆，需账户所有人确认"));
        }
        return ResponseEntity.ok(refundService.execute(req, key));
    }
}
```

### 4.5 人工确认闸门：用 202，不要用 4xx

这是整套设计里最容易做错的一处。

**错误做法**：高风险操作直接返回 `403`，让 Agent 自己重试或换参数。结果是 Agent 会不断尝试绕过，或者干脆放弃任务。

**正确做法**：返回 **`202 Accepted` + 一个 `confirmationId`**，语义是"请求我已受理，但需要人类确认才能继续"。

```java
public record ConfirmationRequired(String confirmationId, String reason) {}

@Service
public class ConfirmationService {

    private final Map<String, PendingConfirmation> pending = new ConcurrentHashMap<>();

    /** 创建待确认项：绑定委托令牌，防止确认后被人换用 */
    public String create(Authentication auth, Object payload, String idempotencyKey) {
        String cid = UUID.randomUUID().toString();
        pending.put(cid, new PendingConfirmation(
                cid, auth.getName(), payload, idempotencyKey, Instant.now()));
        notifyChannel.pushToUser(auth.getName(), cid);   // App 推送 / 短信 / 站内信
        return cid;
    }

    /** 用户确认后二次提交，幂等键保证只执行一次 */
    public Object confirmAndExecute(String cid, String confirmedBy, String idempotencyKey) {
        PendingConfirmation p = pending.get(cid);
        if (p == null) throw new ConfirmationExpiredException(cid);
        if (!p.idempotencyKey().equals(idempotencyKey)) {
            throw new IdempotencyMismatchException(cid);
        }
        if (!executor.executeOnce(p)) {
            throw new AlreadyExecutedException(cid);
        }
        pending.remove(cid);
        AuditLog.record(new AuditEntry(Instant.now(), "CONFIRMED_AND_EXECUTED",
                p.agentId(), confirmedBy, p.scopes(), null, p.parentJti()));
        return p.result();
    }
}
```

两个必须做对的细节：

-   **确认项要绑定原始委托令牌**。否则确认这一步本身会被重放，攻击者可以用别人的确认结果执行自己的请求。
-   **`executeOnce` 必须靠幂等键去重**（数据库唯一约束最可靠，内存 Map 只适合演示）。Agent 超时重试是常态，不是异常。

## 五、验证：三个断言比十段说明有用

上线前建议至少写这三个测试。它们分别对应三个最容易失手的点。

```java
@Test
void 降权不得扩大权限() {
    Set<String> userScopes = Set.of("order:read", "order:create");
    String token = delegationService.issue("agent-1", "user-1", "jti-parent",
            userScopes,
            Set.of("order:read", "user:delete"),   // 故意多申请
            Instant.now());

    DelegatedClaims c = verifier.parse(token);
    assertThat(c.scopes()).containsExactly("order:read");   // delete 被丢弃
    assertThat(c.scopes()).doesNotContain("user:delete");
}

@Test
void TTL由最危险的scope决定() {
    // order:read TTL=5min，refund:create TTL=1min → 一起申请应得 1min
    assertThat(expiresIn(Set.of("order:read", "refund:create")))
            .isEqualTo(Duration.ofMinutes(1));
}

@Test
void 令牌过期后必须拒绝() {
    Instant now = Instant.now();
    String token = issue(Set.of("order:read"), now);
    assertThatThrownBy(() -> verifier.verify(token, "order:read", now.plusSeconds(301)))
            .isInstanceOf(ExpiredDelegationTokenException.class);
}
```

第一条最关键：**它证明你的降权是单调的**。很多实现只在"正常路径"上工作，一旦 Agent 多申请权限就悄悄放行。

## 六、验证与实测结果

上面所有断言都可以被机器判定，不是靠"看起来对"。下面这组结果全部在本机真实跑出，代码只依赖 JDK 标准库（HMAC + ConcurrentHashMap），不需要任何第三方 JWT 库。

**测试环境**：JDK 17.0.20（HotSpot 64-Bit）/ Windows 11 x64。每个机制测试都是"构造场景 → 断言结果 → 打印 PASS/FAIL"。

### 8.1 四项机制正确性

| 测试项 | 构造方式 | 实测结果 |
| --- | --- | --- |
| 降权单调性 | 用户只有 `order:read`、`order:create`，Agent 却申请 `order:read` + `user:delete` + `refund:create` | PASS — 最终授予仅 `[order:read]`；delete 因 TTL=0 不可委托，refund 因用户本身没有而被丢弃 |
| 无父权限不得签发 | 父 scope 传空集，申请 `order:read` | PASS — 授予集为空，签发被拒 |
| TTL 由最危险 scope 决定 | 单独申请 `order:read` vs 同时申请 `order:read`+`refund:create` | PASS — 单独 300s；混合后降为 60s |
| 过期与篡改必须被拒 | 签一个 1 秒后过期的 token；再把 payload 里 scope 改成 `user:delete` 并保留原签名 | PASS — 未过期时通过；sleep 1.2s 后重放被拒；篡改 scope 因签名不匹配被拒 |

第一行是这套设计里最该被测试覆盖的：**Agent 多申请权限时，正确行为是"静默丢弃不可委托的部分"，而不是整个请求失败，更不是照单全收。**

### 8.2 幂等去重：20 并发打同一个幂等键

这是最容易在测试环境"看起来没问题"的地方。用 20 个线程同时对同一个退款幂等键发起调用，统计真实执行次数（期望恒为 1）：

| 轮次 | check-then-act  
`if(!containsKey) put` | 原子操作  
`putIfAbsent() == null` |
| --- | --- | --- |
| 第 1 轮 | **2 次（重复退款）** | 1 次 |
| 第 2 轮 | 1 次 | 1 次 |
| 第 3 轮 | 1 次 | 1 次 |

请注意第 2、3 轮 check-then-act **也给出了正确答案**。这正是它最危险的地方：绝大多数时候它都对，于是顺利通过了测试和评审，然后在某个流量抖动的时刻漏出两次退款。`putIfAbsent` 三轮全部恒为 1。

**结论：去重必须依赖原语（`putIfAbsent` / CAS / 数据库唯一索引），任何"先查再写"的组合都不构成幂等。**生产环境请用数据库唯一索引——内存 Map 重启即失效。

### 8.3 一个反直觉的实测：别为令牌校验加缓存

很多人第一反应是"每次请求都验签太贵，要加缓存"。实测数据不支持这个直觉（预热 20 万次后，取 100 万次平均）：

| 操作 | 平均耗时 | 单线程吞吐 |
| --- | --- | --- |
| HMAC-SHA256 签名 | 2472 ns/次 | ≈ 404,530 次/秒 |
| 完整校验（验签 + 过期判断 + Base64） | 5572 ns/次 | ≈ 179,468 次/秒 |

也就是说，**校验一次约 5.6 微秒，比一次数据库查询便宜三到四个数量级。**令牌签发与校验本身不是瓶颈，把优化预算花在那里是浪费；真正会拖垮你的是被委托方的高频重试和下游模型调用。

*复现方式：本文测试程序只依赖 JDK 标准库 —— `javac -encoding UTF-8 -d out Bench2.java && java -cp out Bench2`，输出 7 项 PASS、0 项 FAIL。换机器后绝对值会变，但"check-then-act 会漏"和"校验不是瓶颈"这两个结论不会变。*

## 七、哪些接口现在就能给 Agent，哪些永远不要

| 接口类型 | 能否委托 | 建议 TTL | 额外要求 |
| --- | --- | --- | --- |
| 只读查询（订单、库存、状态） | ✅ 可以 | 5 分钟 | 常规限流 |
| 可逆写（创建草稿、加购物车） | ✅ 可以 | 2 分钟 | 幂等键 |
| 不可逆写（退款、发货、转账） | ⚠️ 谨慎 | 1 分钟 | **强制人工确认** |
| 权限/账号变更（改密码、删账号） | ❌ 不要 | — | 永不委托 |
| 批量数据操作（导出、批量更新） | ❌ 不要 | — | 永不委托 |
| 生产环境变更（发布、配置下发） | ❌ 不要 | — | 走独立审批流 |

最后一行值得单独强调：**不要让 Agent 直接生成线上变更命令**，尤其是批量更新或销毁数据的场景。让它生成脚本草稿，人来执行。这条不是保守，是因为这类操作的错误成本与 Agent 的决策质量根本不成比例。

## 八、适用边界与已知代价

诚实地说清这套方案的代价，避免你照搬后踩坑：

1.  **延迟增加**。多一次令牌签发 + 高风险操作的一次人工往返，对话式体验会明显变慢。建议把 TTL 设得比"一次任务"略长，避免每个接口调用都重新签发。
2.  **Agent 侧要能处理 202**。如果你的 Agent 框架把非 2xx 当失败、把 2xx 当成功，那 `202 + confirmationId` 会被误判为"已完成"。**这一点务必在 Agent 的工具定义里显式声明**，否则会出现"它以为退款成功了"的尴尬。
3.  **确认通道本身是攻击面**。推送、短信、站内信都可能被社工。高价值操作建议要求带上下文的确认（展示金额、对象、Agent 名称），而不是一个"确认/取消"按钮。
4.  **审计日志会含敏感数据**。委托链、scope、参数摘要都要落库，但**参数原文可能含手机号、金额、地址**——入审计前必须脱敏，否则你为了可追溯反而造出一个新的泄露点。
5.  **本文不覆盖**：跨服务的委托传递（Agent A 调 Agent B 时的链式降权）、Agent 身份本身的真实性校验（KYA 的 A 端）、以及具体支付厂商协议的对接。

## 九、总结

回到开头那句判断：**Agent 不会模拟人点按钮，它会带着凭证直接调你的 API。** 所以后端要补的不是"识别是不是机器人"，而是三件更基础的事：

-   **令牌要短**：分钟级，按最危险的能力定 TTL
-   **权限要降**：单调递减，多申请的部分静默丢弃
-   **不可逆要拦**：用 `202 + confirmationId`，而不是 `403`

这三件事在传统的"人—Web—API"模型里其实一直存在，只是过去靠"人不会每秒重试一千次"这个默认假设兜着。**Agent 把这个假设拿走了，于是制度必须显式地建起来。**

如果你的系统现在还没有"调用主体是 Agent"这个概念，建议从一个只读接口开始试点：加 `agentId` claim、跑通降权、把审计日志接进现有链路。走通之后再逐步开放可逆写——**不要一上来就把退款接口交给 Agent。**

你现在给 Agent 开放的是哪类接口？有没有遇到过"它以为自己执行成功了"的情况？评论区聊聊你的踩坑。

本文解决什么问题：当 AI Agent 开始代表用户调用你的后端接口（查订单、发起退款、提交工单），把用户的长期 token 直接交给它是最省事也最危险的做法。本文给出一套可复现的 Java 实现：签发短期令牌、按调用链逐级降权、高风险操作强制人工确认，并配套审计与测试。 适合谁读：已有 Spring Boot + Spring Security 基础、正在把 Agent 接入真实业务接口的后端开

Agent 要替用户调你的接口：Spring Boot 实现短期令牌、权限降级与人工确认闸门

人工智能

Agent接入后端API需防长期令牌泄露。方案采用短期令牌、单调降权与人工确认闸门，防止越权与不可逆操作。实测显示HMAC校验5.6微秒，非瓶颈；幂等须用原子操作。建议只读接口TTL5分钟，可逆写2分钟，不可逆写需人工确认，权限变更永不委托。

敏感数据

Agent 框架

Spring Boot

数据库

服务器

AI Agent

Windows

短信

Agent

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent 要替用户调你的接口：Spring Boot 实现短期令牌、权限降级与人工确认闸门-腾讯云开发者社区-腾讯云

Agent 要替用户调你的接口：Spring Boot 实现短期令牌、权限降级与人工确认闸门

Agent 要替用户调你的接口：Spring Boot 实现短期令牌、权限降级与人工确认闸门

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐