Portable trust for AI and delegated access in CIAM

At a glance

What this is: This is an analysis of portable trust in CIAM, arguing that authentication alone is not enough when customers, delegates, proxies, and AI agents need real-time authorization across applications, APIs, and data.

Why it matters: It matters because IAM teams increasingly have to govern who can act, not just who can log in, across delegated and AI-mediated journeys where static roles and code-based controls break down.

👉 Read PlainID's analysis of portable trust for CIAM and AI delegation

Context

Portable trust in CIAM is the idea that access decisions should follow the identity through the full digital journey, not stop at the login event. PlainID argues that authentication answers who the user is, but not what they can do once inside applications, APIs, and data flows.

The governance gap is that customer access now includes delegates, proxies, partners, and AI-assisted actions operating across business contexts. That makes static roles, embedded authorization logic, and one-time token issuance too blunt for modern CIAM programmes, especially when consent and business rules change in real time.

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. The result is that a user can be authenticated but still act outside intended policy boundaries. For modern CIAM, that means the real control point is the action itself, not the initial session creation.

Q: Why do delegated access patterns need real-time policy checks?

A: Delegated access can change meaning by purpose, time window, and relationship. Real-time policy checks ensure a proxy only sees or does what the current delegation still allows, instead of inheriting a blanket entitlement that persists after the business context has changed.

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. Governance should require explicit consent, narrow authorization scope, token binding, and a complete audit record tying each action back to the human principal that approved it.

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.

Technical breakdown

Runtime authorization in CIAM

Runtime authorization is policy evaluation at the moment an action is attempted, rather than at initial authentication. In CIAM, that means the entitlement decision can use current identity attributes, device state, consent, location, and delegated scope before allowing an API call, row-level data access, or response generation. The architecture centralises policy so the same rules apply consistently across channels instead of being reimplemented in application code. That matters because customer context changes faster than release cycles, and hardcoded rules drift from business intent.

Practical implication: move sensitive customer decisions out of code paths and into centrally managed runtime policy.

Delegated access and proxy control

Delegated access is not simple shared login. It is a conditional right for one actor to act on behalf of another under an explicit scope, time window, and business purpose. In CIAM, that can include accountants, healthcare proxies, financial advisers, or AI assistants acting with user authority. The technical risk is scope leakage, where the delegate inherits more access than intended or continues after the consent boundary changes. Portable trust only works if the authorization layer understands delegation as a first-class identity state, not as an exception handled by custom logic.

Practical implication: model delegated authority as policy data, with explicit scope and revocation conditions.

AI assistants as policy-bound actors

When AI assistants or agents act on customer data, the identity problem changes from login assurance to action assurance. The system must decide whether a given assistant-driven request is within the authenticated user’s consent, entitlement, and business context before the request reaches sensitive data or downstream APIs. Without that check, an assistant can retrieve, combine, or expose data outside policy boundaries even when the human user authenticated correctly. That is why the article frames authorization as the control that makes AI safer in customer-facing environments.

Practical implication: require policy evaluation for AI-mediated actions before data retrieval, API use, or response generation.

Threat narrative

Attacker objective: The objective is to obtain authorised-looking access that can still reach sensitive data or actions outside the intended customer, delegate, or AI policy boundary.

1. Entry occurs through a legitimate CIAM login or delegated session where the identity is authenticated but not yet constrained at the point of action.
2. Escalation follows when static roles, embedded code, or stale consent allow broader application, API, or data access than the current context permits.
3. Impact is the exposure or misuse of customer data and actions taken outside policy, consent, or delegation scope, including AI-assisted responses.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Static roles are too coarse for delegated and AI-assisted customer journeys. Roles were built to describe relatively stable duties, not changing combinations of device, location, consent, and purpose. That mismatch creates policy drift when the same identity can interact through a browser, a proxy, an API, or an assistant. The practical conclusion is that CIAM programmes need context-aware policy evaluation, not more role sprawl.

Identity governance now has to follow the action path across human and machine-mediated use cases. The article shows why customer identity cannot be treated as a single event at onboarding or login. In a delegated model, the real question is whether each action is still within scope at the moment it occurs, especially when an AI system is executing or drafting responses on the user’s behalf. That makes centralized authorization and auditability a governance requirement, not an implementation detail.

AI-assisted access exposes the gap between user intent and system execution. When an assistant retrieves customer data or calls APIs, the request may be technically authenticated but still semantically out of bounds for consent or business purpose. That is the portable trust gap in its clearest form: the identity is known, but the action is not yet governed. Security teams should treat AI-assisted customer workflows as authorization-sensitive by default.

Portable trust should become the organising concept for modern CIAM architecture. The article surfaces a useful named concept because it captures the actual design shift: access decisions must travel with the identity from onboarding through delegation, application use, and AI-driven action. That framing is useful because it joins IAM, consent, and data governance into one operating model. Practitioners should use it to evaluate whether their CIAM stack governs the full journey or only the entry point.

What this signals

Portable trust is becoming the missing control plane in CIAM. Enterprises that still separate login from action will keep pushing risk into application code, API gateways, and custom data checks. The stronger pattern is to let policy travel with the identity so consent and context are re-evaluated as the user, delegate, or AI assistant acts.

Context-aware authorization is now the deciding factor in customer identity programmes. Device, location, relationship, and purpose are no longer edge cases. They are the conditions that determine whether access should continue, narrow, or stop, especially when a proxy or assistant is involved.

Delegation and AI will force CIAM teams to think in terms of action boundaries. Session management alone does not answer who may see a record, generate a response, or call an API on someone else’s behalf. The programme that wins here is the one that can prove access was valid at the moment it was used.

For practitioners

• 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.
• Unify audit trails across channels Keep one policy log for application, API, and data-layer decisions so reviewers can trace who acted, under what context, and why.

Key takeaways

• CIAM that stops at authentication leaves the hardest governance question unresolved: what an identity may do once it is inside the system.
• Delegated access and AI-assisted actions both require policy decisions that reflect current context, not static role assignments.
• Portable trust is the practical answer when customer identity, consent, and authorization need to stay aligned across the full journey.

Key terms

• Portable Trust: A trust model in which access decisions follow the identity across the full digital journey, not just at initial authentication. It combines identity proof, policy, consent, and contextual enforcement so the allowed action can change as conditions change.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Policy-Bound Actor: A policy-bound actor is any human, proxy, or AI assistant whose actions must be checked against current entitlements and consent before access is granted. The term is especially useful when an authenticated user is not the only entity making or carrying out requests.

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

👉 The full PlainID post covers the joint Thales and PlainID model for runtime authorization, delegation, and auditability.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.