Topic starter
23/06/2026 7:24 pm
TL;DR: PlainID says CIAM implementations that stop at login leave authorization scattered across applications, APIs, and data layers, creating gaps for delegated access and AI-assisted actions. The control point shifts to runtime authorization at the moment of action, where policy, consent, and context must follow the identity.
Editorial analysis by NHI Mgmt Group, based on content published by PlainID: “Portable Trust: How Thales and PlainID Extend CIAM for Advanced Digital Business”.
Key questions
Q: What breaks when CIAM authorization is only enforced at login?
A: Login-only authorization leaves later application, API, and data decisions to code paths that may not reflect current consent, context, or delegation scope.
Q: Why do delegated access patterns need real-time policy checks?
A: Delegated access can change meaning by purpose, time window, and relationship.
Q: How should teams govern AI agents that act inside customer accounts?
A: Treat them as delegated non-human identities, not as ordinary customer sessions.
Practitioner guidance
- Centralise runtime authorization Move high-risk customer access decisions out of application code and into a policy layer that can evaluate context at the moment of action.
- Model delegated access explicitly Define delegate scope, time window, and revocation conditions as policy data so proxy access does not rely on ad hoc exceptions.
- Bind AI actions to current entitlements Require AI assistants and agents to be checked against the authenticated user’s consent and entitlements before data retrieval or API use.
Bottom line: CIAM that stops at authentication leaves the hardest governance question unresolved: what an identity may do once it is inside the system.
What's in the full article
PlainID's full blog post covers the operational detail this post intentionally leaves for the source:
- Policy language and runtime decision flow for centralized authorization across applications and APIs
- Examples of delegated access patterns for accountants, proxies, and hybrid B2C journeys
- How AI assistants are bound to user entitlements, consent, and business context at action time
- The joint Thales and PlainID architecture for identity proofing, adaptive authentication, and authorization
👉 Read PlainID's analysis of portable trust for CIAM and AI delegation →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:23 am
Portable trust is now an authorization problem, not a login problem. The article is right to separate authentication from the decision that follows it, because modern CIAM journeys now include customers, delegates, partners, and AI-mediated actions. Once identity can act across APIs and data layers, the control that matters is no longer proof of identity alone but the ability to bound every action to current context. Practitioners should treat runtime authorization as the governing control plane for customer access.
A question worth separating out:
Q: What is the difference between authentication and authorisation in CIAM architectures?
A: Authentication proves the user’s identity. Authorisation uses that verified identity, usually through a token and its attributes, to decide what an API should allow. Separating the two makes the design clearer and safer because the login flow can vary by scenario while access decisions remain consistent, auditable, and based on the right data.
👉 Read our full editorial: Portable trust for AI and delegated access in CIAM