From Token Dispensaries to Agentic Identity: Hardening OAuth and Non‑Human Access with CAEP/SSF

Published: 2026-02-07

A useful way to think about modern identity risk is that we’re not just protecting accounts anymore — we’re protecting tokens, sessions, and increasingly non-human actors (workloads, pipelines, and AI agents) that can operate at machine speed.

In the last day, Praetorian published a great write-up on how two “medium” web-app flaws can chain into a catastrophic outcome: an exposed email-sending endpoint that lets attackers deliver phishing that passes SPF/DKIM/DMARC, and verbose error handling that leaks OAuth bearer tokens for Microsoft 365 Graph — effectively turning an application into a token dispensary. Once an attacker can mint or harvest tokens repeatedly, “rotate passwords” and “shorten token TTLs” stop being sufficient.

Primary source: Praetorian, Gone Phishing, Got a Token: When Separate Flaws Combine (2026-02-06/07) — https://www.praetorian.com/blog/gone-phishing-got-a-token-when-separate-flaws-combine/

This post uses that scenario as the jumping-off point to answer a question that’s showing up in more security programs:

How do we design token and session security that still works when access is driven by automation and agents, and when compromise can happen through any integration surface — not just the IdP login page?

We’ll cover:

The “token dispensary” failure mode and why it breaks traditional IAM assumptions
A practical control set for OAuth/OIDC token security (human and non-human)
How Continuous Access Evaluation and Shared Signaling Framework (CAEP/SSF) reduce the blast radius when tokens are stolen
Patterns for AI agent authorization and least privilege when your “user” is autonomous software
A phased adoption plan with concrete implementation steps

Along the way, I’ll name specific products/standards (Microsoft Entra ID, Okta, Ping, Auth0, AWS/GCP/Azure workload identity, HashiCorp Vault, CyberArk Conjur, SPIFFE/SPIRE, OpenID SSF/CAEP) while staying enterprise-neutral.

Why “token dispensaries” are worse than phishing

Traditional phishing aims to steal a password or MFA approval and then establish a session. In a mature environment, you can often blunt that with:

phishing-resistant MFA
conditional access / device posture
impossible travel / risk scoring
anomaly detection and rapid session revocation

A token dispensary flips the model:

The attacker doesn’t need to authenticate as the user.
They don’t need to bypass MFA.
They obtain an already-authenticated bearer token (often scoped to high-value APIs).
Worse: if the application can be coerced into leaking or generating tokens repeatedly (e.g., by triggering error conditions), the attacker can keep renewing access.

In Praetorian’s scenario, the leaked token was a Microsoft Graph OAuth token. With the right scopes/roles, Graph access can quickly become “read everything, send email as anyone, enumerate the org, pivot to SharePoint/OneDrive/Teams, and potentially reach Azure/Intune.”

The deeper lesson isn’t “be careful with Graph.” It’s:

Identity boundaries are now API boundaries. Any system that holds tokens is part of your identity perimeter.
Token theft is often quiet compared to interactive login abuse.
Token lifetime is not a sufficient control when the attacker can mint fresh tokens.

Token and session security: a practical control map

Before you add new tools, make sure you can answer these questions for your highest-risk applications and automation paths:

Where are tokens created? (IdP token endpoint, app-to-app exchange, workload identity federation, device code flows, on-behalf-of flows)
Where are tokens stored? (browser storage, mobile keychain, server memory, secrets manager, CI logs, crash dumps)
Where are tokens used? (APIs, third-party SaaS, internal microservices, agent tool calls)
How are tokens revoked? (expiry only vs. introspection vs. event-driven revocation)
How is misuse detected? (API anomaly detection, impossible token usage, token replay detection, UEBA/ITDR)

A comparison table: token/session artifacts and what to secure

Artifact	Typical purpose	Typical lifetime	Common failure modes	Controls that actually help
Access token (OAuth2)	Call APIs	Minutes to ~1 hour	leaked in logs/errors, replayed from another host, over-scoped	short TTL; audience restriction; sender-constraining (DPoP / mTLS); least-privilege scopes; API gateway validation; anomaly detection
Refresh token	Get new access tokens	Hours–days (sometimes longer)	long-lived “skeleton key” in a laptop or CI runner	rotation + reuse detection; device binding; step-up on refresh; store in secure enclave; limit issuance to trusted clients
ID token (OIDC)	Authenticate client/app	Minutes–1 hour	treated like an access token; logged or reused incorrectly	never use as API auth; validate nonce/aud/iss; keep out of logs
Session cookie	Web session continuity	Hours	stolen via XSS/CSRF; session fixation	HttpOnly/SameSite; CSRF defense; session rotation; CAE/CAEP-driven revocation
API key	Simple app auth	Months/years	copied, shared, never rotated	replace with OAuth/OIDC or workload identity; rotate; scope; allowlist; secret scanning
Security Event Token (SET) (SSF)	Signal risk/change	N/A (event)	not consumed; no automation to act on signals	implement SSF subscribers; map events to actions; test revocation time

If your program only hardens interactive login (MFA, SSO policies) but ignores token storage and API-level behavior, you’ll keep losing to “medium” flaws chained together.

Concrete implementation guidance: harden the app surfaces that hold tokens

The uncomfortable truth: your IAM team can’t solve token dispensaries alone. This is an identity + application security + platform engineering problem.

Here’s a prioritized list of engineering controls that directly address the failure modes in the Praetorian-style chain.

1) Kill verbose error leakage in production (and make it measurable)

What to do

Ensure production error responses never include stack traces or internal context.
Use structured server-side logging with redaction.
Make “token in logs” a CI/CD and runtime SLO.

How

Add a global error handler (Express/Next.js/ASP.NET/Spring) that returns generic 4xx/5xx bodies.
Add log scrubbing patterns for JWT-like strings (three base64url segments) and common token headers.
Enable secret scanning in repos and CI logs.

Verification

Add a security test that intentionally triggers malformed requests and asserts the response body contains no token-shaped strings.

2) Constrain tokens to the sender (so replay fails)

If an attacker can steal a bearer token and replay it from anywhere, you’re relying on detection and timeouts.

Options

mTLS-bound access tokens (OAuth 2.0 Mutual-TLS)
DPoP (Demonstration of Proof of Possession)

In practice:

SaaS APIs vary in support; you’ll use this most often for internal APIs.
For internal microservices, consider SPIFFE/SPIRE to issue workload identities and bind service-to-service auth to mTLS.

3) Reduce token privilege at the API boundary (not just in the IdP)

Even with perfect issuance policies, over-broad API permissions make token theft catastrophic.

How

Use an API gateway (e.g., Kong, Apigee, AWS API Gateway, Azure API Management) to enforce:
- audience (aud) and issuer (iss)
- scope/role checks per route
- rate limits and anomaly rules (burst limits, geo/ASN rules, impossible usage)
Split “read directory” and “send mail” capabilities into separate applications/service principals.

4) Protect non-human identity (NHI) token flows

Most “token dispensaries” become existential when the leaked token belongs to:

a CI pipeline service principal
a workload identity used by a platform service
an agent runtime that can call many tools

Prefer federated workload identity over long-lived secrets:

AWS: IAM Roles for Service Accounts (IRSA) for EKS; OIDC federation for external identities
GCP: Workload Identity Federation (WIF)
Azure: Managed Identities (and workload identity federation for AKS)

Store secrets only as a last resort, and then use a real secrets manager:

HashiCorp Vault
AWS Secrets Manager
Azure Key Vault
GCP Secret Manager
CyberArk Conjur (often used for app secrets)

If you want more on NHI basics and governance, see:

Why CAEP/SSF matters in a world of stolen tokens

Short token lifetimes help — until they don’t.

If the attacker can:

mint new tokens by re-triggering an error
steal refresh tokens (or use refresh tokens legitimately)
pivot to a persistent credential (service principal secret, app password, device cert)

…then “15-minute access tokens” is mostly a speed bump.

Continuous Access Evaluation (CAE) and the Shared Signaling Framework (SSF) exist to close the gap between risk detection and session/token termination.

SSF standardizes how security events are shared as Security Event Tokens (SETs).
CAEP is an SSF profile focused on “continuous access evaluation” — i.e., dynamic session revocation and re-auth decisions.

Learn IAM topic reference:

https://learn-iam.com/topics/access-management/caep

CAEP/SSF vs. “just shorten TTLs”

Approach	What it does well	What it fails at	Where it fits
Short access token TTL	reduces window for stolen access token	doesn’t revoke refresh tokens; doesn’t stop replay during TTL; doesn’t address token minting vulnerabilities	baseline for everything
Token introspection	can invalidate tokens centrally	adds latency; not always supported; still requires revocation signal	internal APIs, high-risk services
CAE/CAEP events (SSF)	pushes revocation/risk changes in near real-time across systems	requires subscriber implementation; vendor ecosystem still uneven	SSO + SaaS + critical apps; Zero Trust
ITDR + SOAR automation	detects identity attacks and triggers actions	detection gaps; false positives	layered defense, incident response

The key benefit for token theft scenarios: once a high-confidence signal exists (“token leaked”, “endpoint exploited”, “impossible token usage”, “service principal suspected compromised”), you can propagate that signal so dependent systems revoke sessions/tokens immediately.

What events should you actually signal?

Start with a small, high-value event taxonomy:

account/service principal disabled
credential reset / key rotated
device compliance lost
user risk elevated (high)
session revoked
workload identity suspected compromised

Then map each event to an action in your apps/APIs:

revoke server-side sessions
deny token refresh
require step-up (phishing-resistant)
downgrade scopes (read-only mode)
quarantine the workload (block egress, rotate identity)

Agent authorization: what changes when the “user” is autonomous?

AI agents introduce two IAM shifts:

The actor is not a human — but may act on behalf of a human.
The blast radius is tool-shaped — an agent’s power is the sum of all tools and API scopes you give it.

If an agent runtime leaks tokens, the result looks exactly like the Praetorian chain — except the attacker may inherit broad “automation” access.

Key patterns to anchor on:

Pattern A: Tool-by-tool authorization (don’t hand the agent a master token)

Instead of giving the agent one token that can call many systems, broker access per tool call:

agent requests a capability (e.g., “read ticket #123”, “rotate secret X”)
policy engine evaluates context and grants a narrow token
token is valid for one tool, one audience, short lifetime

This is where policy engines and fine-grained auth help:

OPA / Gatekeeper for Kubernetes admission controls
Cedar / Zanzibar-inspired models for app authorization
“Policy decision point” architectures (PDP/PEP)

See Learn IAM topics:

Pattern B: Delegation and impersonation that is explicit and auditable

If an agent acts for a person, make delegation first-class:

explicit “act as” grants
time-bound delegation
approval workflows for high-risk actions
audit trails that preserve: human initiator → agent → tool call → downstream action

Topic:

https://learn-iam.com/topics/identity-for-ai/delegation-impersonation

Pattern C: Non-human identity governance for agents

Treat each agent runtime as a managed identity with lifecycle controls:

inventory: what agents exist, where they run
ownership: business + technical owner
permissions: least privilege per environment
rotation: keys, certs, federation settings
kill switch: one control to disable/quarantine

A phased adoption plan (90 days to “materially better”)

You don’t need to boil the ocean. You need to close the most common, highest-impact gaps.

Phase 0 (Week 1–2): Establish baselines and stop the bleeding

Deliverables

Inventory of token-issuing systems and “token-holding” apps (including CI/CD, agent runtimes)
Standard for production error handling and logging redaction
“No tokens in logs” detection (CI + runtime)

Actions

implement generic error responses in internet-facing apps
rotate any long-lived secrets found in logs
enable secret scanning in repos and CI

Phase 1 (Weeks 3–6): Reduce privilege and constrain replay

Deliverables

API gateway enforcement for audience/issuer/scope on critical APIs
Scope model review for Microsoft Graph / Google Workspace / SaaS APIs
Workload identity migration plan (federation over static secrets)

Actions

split service principals by function (read vs write)
introduce DPoP or mTLS where feasible for internal APIs
migrate CI/CD to OIDC federation (GitHub Actions, GitLab CI, Azure DevOps) where supported

Phase 2 (Weeks 7–10): Event-driven revocation with CAEP/SSF

Deliverables

CAEP/SSF capability map across your IdP and key service providers
first “revocation path” implemented end-to-end (detect → signal → enforce)

Actions

pick one use case: “disable user → sessions revoked everywhere” or “risk high → step-up required”
implement SSF subscriber(s) for your most critical app(s)
run a tabletop exercise: token leak scenario with measured revocation time