The credential an agent steals is usually not a password — it is a token. On 15 October 2026, Google announced that its OAuth Platform now supports DPoP (Demonstrating Proof-of-Possession) for refresh tokens, binding them cryptographically to a client keypair so a stolen token cannot be replayed.
What happened
Traditional OAuth bearer tokens work on a “finders-keepers” model: whoever holds the token can use it. Google’s post names the two attack classes that exploit this — Infostealer malware (RedLine, NodeStealer) and Adversary-in-the-Middle (AiTM) attacks.
DPoP is an application-layer OAuth 2.0 security profile (RFC 9449) that cryptographically binds a token to a client-generated asymmetric keypair, so “even if a token is stolen, it cannot be replayed without the corresponding private key.”
Google’s implementation is deliberately scoped:
- DPoP binding is applied to refresh tokens only. Sender-constraining the long-lived refresh token neutralizes the primary vector for persistent offline impersonation.
- Short-lived access tokens remain standard bearer tokens, so high-throughput resource APIs avoid per-request asymmetric signature verification — a stated performance-versus-security tradeoff.
- DPoP operates at the HTTP header level, which Google notes makes it “highly resilient for complex, multi-hop environments, including emerging Model Context Protocol (MCP) and autonomous agent architectures” — unlike transport-layer binding (mTLS, RFC 8705) that tends to terminate at cloud proxies and load balancers.
The post also states a directly agent-relevant deployment: Google Workspace Context-Aware Access (CAA) “leverages DPoP to secure enterprise AI workloads on the Gemini Enterprise Agent Platform by cryptographically validating agent identities at the Agent Gateway.”
Google is candid about DPoP’s limits in multi-agent systems: in a chain where Agent A delegates a task to Agent B, which calls Resource C, Agent B cannot sign a DPoP proof on behalf of Agent A without access to A’s private key — and sharing private keys “violates the core security principles”. Google positions DPoP as a single-hop control and points to the delegation problem as unresolved. (Readers comparing notes should also see the earlier KYA coverage of the IETF’s agent-authority and delegation drafts.)
DPoP complements, and does not replace, other controls: it does not protect browser session cookies, which Google and the WICG address separately via Device Bound Session Credentials (DBSC). Google references RFC 9700 (OAuth 2.0 Security Best Current Practice) and the Browser-Based Apps draft, and offers an adoption SKILL.md to help implementers.
Why it matters for KYA
Token theft is the quiet failure mode of agent identity. An agent that presents a valid token passes most “is this agent allowed?” checks — because the check verifies the token, not possession. DPoP changes the question to “does the caller hold the private key this token is bound to?”, which is the difference between an identity assertion and a possession proof.
For KYA practitioners, three points are worth acting on:
- Sender-constrained credentials are the baseline for long-lived agent secrets. If an agent’s integration uses a refresh token or long-lived credential, DPoP-style binding (or its equivalents) is now the expected hardening, not an exotic option.
- Google is validating agent identities at the gateway — not just user identities. Context-Aware Access using DPoP at an Agent Gateway for Gemini Enterprise is a concrete example of the “verify the agent at the door” pattern KYA describes.
- Delegation is still the open wound. Google’s own caveat — Agent B cannot prove possession of Agent A’s key — is exactly the multi-agent delegation problem that the standards work is racing to solve. DPoP secures the hop, not the chain.
Read it as a foundational, standards-based hardening step (RFC 9449, a mature profile) that enterprises and agent-platform builders can adopt today, with the honest caveat that it does not, by itself, solve delegated authority across a chain of agents.
Sources
- Google Developers Blog, “Announcing DPoP Support for Google OAuth: Securing Refresh Tokens”, 15 October 2026 — developers.googleblog.com.
- IETF, RFC 9449, “OAuth 2.0 Demonstrating Proof of Possession (DPoP)” (September 2023) — rfc-editor.org.
- IETF, RFC 9700, “Best Current Practice for OAuth 2.0 Security” (January 2025) — rfc-editor.org.
- IETF, RFC 8705, “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens” — referenced as the transport-layer alternative — rfc-editor.org.
Note: the DPoP scope decisions, the Agent Gateway/Context-Aware Access detail and the multi-agent caveats are Google’s own, as stated in the cited post.
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.