Notifications
Clear all
Topic starter
07/06/2026 8:56 pm
TL;DR: Old or compromised sessions can remain valid after password resets, device loss, or offboarding, and WorkOS describes session revocation as the mechanism that invalidates them across devices, including AI agent sessions. The governance issue is that expiry alone does not close access cleanly; revocation does.
NHIMG editorial — based on content published by WorkOS: Session revocation explained for users and AI agents
Questions worth separating out
Q: How should security teams implement sign out everywhere for active sessions?
A: Security teams should centralise session state, list all sessions for the subject, revoke each one, and clear the initiating device locally.
Q: Why do revoked sessions still matter after a password reset or offboarding event?
A: A password reset or offboarding event changes the trust state immediately, but a session can remain valid until its natural expiry unless it is explicitly revoked.
Q: How can organisations tell whether session revocation is actually working?
A: Look for rejected reuse attempts on revoked session IDs, complete revocation coverage after lifecycle events, and audit logs that show who revoked what and when.
Practitioner guidance
- Make revocation a request-time control Validate session status on every authenticated request, not only at token expiry.
- Tie revocation to lifecycle events Trigger session termination automatically on password reset, SSO deactivation, offboarding, and permission changes.
- Inventory active sessions per subject Maintain a live list of sessions with user agent, IP address, last activity, and session ID so administrators and users can review where access exists.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The Sessions API workflow for listing active sessions and revoking them one by one.
- Implementation detail for clearing the initiating device while invalidating sessions on other devices.
- Widget-based self-service session management, including user-visible device, browser, and IP metadata.
- Event handling patterns for the session.revoked webhook and local cleanup logic.
👉 Read WorkOS's guide to session revocation and sign out everywhere →
Session revocation for AI agents and users: are your controls enough?
Explore further
08/06/2026 8:41 am
Session expiry is not lifecycle control. Expiration says when access might end on its own, but revocation is the control that ends access when the security state changes. That distinction matters across password resets, device compromise, and offboarding, where waiting for natural expiry leaves a usable authentication window. Practitioners should treat revocation as a governance primitive, not a convenience feature.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 44% of organisations have implemented any policies to govern AI agents, according to the same SailPoint research.
A question worth separating out:
Q: What should teams do when AI agent access needs to be cut off immediately?
A: Teams should terminate the agent session, revoke any linked authorisation state, and remove the integration or permission that allowed the agent to act. The goal is to stop the actor before it can continue making API calls or accessing resources under stale intent.
👉 Read our full editorial: Session revocation and sign-out everywhere for users and AI agents
