Notifications
Clear all
Topic starter
06/07/2026 9:39 am
TL;DR: Single sign-on is framed as an authentication layer that spans web, mobile, admin, and AI agent use cases, with OpenID Connect used to preserve identity across systems and sessions, according to Curity. The governance issue is that SSO makes access easier to extend, so IAM teams must separate user convenience from lifecycle control and privilege scope.
NHIMG editorial — based on content published by Curity: Single Sign-On guidance and related implementation articles
Questions worth separating out
Q: How should security teams govern single sign-on for AI agents?
A: Security teams should govern AI agent SSO as workload identity, not as human authentication with a different front end.
Q: Why does SSO create governance risk if the session is too broad?
A: A broad SSO session can propagate access across many systems after the original authentication event, so revocation becomes harder and the blast radius grows.
Q: What do IAM teams get wrong about SSO and application sessions?
A: IAM teams often assume that signing out of one app ends the identity relationship everywhere, but an SSO session may still be valid elsewhere.
Practitioner guidance
- Separate SSO session policy from application session policy Define when the central identity session should outlive, match, or terminate an application session, and make re-authentication depend on sensitivity rather than convenience.
- Apply actor-type governance to federated identities Classify each SSO subject as human, workload, or agent before choosing claims, token lifetime, and offboarding rules.
- Review token renewal and revocation paths Test what happens when access should end but the identity session is still valid, including browser sessions, refresh tokens, and downstream app caches.
What's in the full article
Curity's full article collection covers the operational detail this post intentionally leaves for the source:
- Implementation examples for SSO on web, mobile, and administrative clients using OpenID Connect
- Guidance on session prompting and authentication-method-specific SSO behaviour
- Practical distinctions between SSO sessions and application sessions
- Options for securing AI agents with a Single Sign-On Service
👉 Read Curity’s SSO guidance for web, mobile, and AI agent use cases →
SSO for AI agents and web clients: what IAM teams need to know?
Explore further
06/07/2026 9:54 am
SSO is becoming an identity distribution layer, not just a login convenience. Once authentication is centralised, the real control question becomes how far the resulting identity can travel across applications, APIs, and agents. That changes SSO from a UX feature into a governance mechanism that influences blast radius, session persistence, and revocation reach. Practitioners should treat it as an access propagation problem.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means many federated access paths are still being governed blind.
A question worth separating out:
Q: How can organisations decide whether an SSO design is suitable for AI agents?
A: An SSO design is suitable for AI agents only if the identity can be constrained like any other workload, with bounded audience, short-lived credentials, and clear offboarding. If the design depends on human assumptions such as interactive login, it is a poor fit. The safest models treat the agent as a managed non-human identity.
👉 Read our full editorial: Single sign-on for AI agents and web apps needs tighter governance
