AuthN Protocols

Q1: How does an agent authenticate (token, cert, workload identity)?

Agents typically authenticate in three “modern” ways, depending on where they run and what they call:

• Tokens (OAuth/OIDC): the agent presents a short-lived access token (often a JWT) on each API call; the resource verifies signature + audience + expiry. This is the default for API-style access.

• Certificates (mTLS): the agent proves identity at the transport layer with an X.509 cert; servers can require mutual authentication before any request is accepted.

• Workload identity (SPIFFE/SPIRE): the runtime gives each workload a verifiable identity (SVID), usually short-lived certs, and workloads use them for mTLS and provenance across services.

A strong agentic design picks one primary method, then adds sender-constraining (PoP) and lifecycle automation so identity stays trustworthy under scale.

Learn More

Q2: Should agents use OAuth client credentials, mTLS, or SPIFFE/SPIRE?

Use this rule of thumb:

• OAuth Client Credentials when the agent is a machine client calling your APIs and you want standardized scopes, audiences, and policy at the auth server. It’s the simplest “API-first” baseline.

• mTLS when you need strong client authentication and/or certificate-bound tokens (great for regulated or high-assurance environments).

• SPIFFE/SPIRE when you have many dynamic workloads (Kubernetes, microservices, agents spawning frequently) and you want runtime attestation + automatically rotated short-lived certs without manually distributing secrets.

In practice: SPIFFE/SPIRE for internal workload identity + OAuth tokens for API authorization, with mTLS or PoP to stop replay.

Learn More

Q3: How do we authenticate agents that browse the web?

Web-browsing agents are high risk because they touch untrusted content and unpredictable flows. A modern pattern is:

• Put the agent behind a controlled egress (proxy) that enforces allowlists, blocks risky domains, and logs outbound requests.

• Require the agent to use per-request credentials: short-lived tokens scoped to the exact destination + action, never “one token for the whole internet.”

• Treat websites as untrusted inputs: sanitize extracted text, block prompt injection patterns, and separate “browse” from “act” (the agent can read broadly, but can only execute actions via approved tools).

• For any login to external sites, prefer delegated OAuth when available; otherwise use a brokered vault session (never paste long-lived secrets into the agent context).

(These are architecture practices; standards you’ll rely on for the credentials themselves are OAuth tokens + sender-constraining like DPoP/mTLS. )

Learn More

Q4: Can we enforce "sender-constrained" tokens (DPoP)?

Yes. DPoP (RFC 9449) is specifically designed to sender-constrain tokens so a stolen access token is harder to replay. The client generates a key pair and sends a signed DPoP proof with each request; the server verifies the proof and binds token usage to that key.

This is especially valuable for agents because tokens often leak through logs, tracing, or tool outputs. Pair DPoP with:

• Short lifetimes + minimal scopes (so even successful theft has limited impact)

• Refresh token rotation (so refresh theft becomes detectable and correctable)

Learn More