Portable trust for AI and delegated access in CIAM

At a glance

What this is: This is an analysis of how portable trust extends CIAM beyond authentication into real-time authorization for delegated users, proxies, and AI-assisted actions.

Why it matters: It matters because IAM teams now have to govern what authenticated identities can do after login, including customer delegation, consent-bound access, and AI-driven actions.

By the numbers:

• Millions of customer identities are managed at global scale with >99.99% uptime.

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

Context

Portable trust means access decisions follow the identity across the full digital journey, not just at login. In practice, that shifts CIAM from proofing and authentication into continuous authorization, where policy has to reflect consent, context, and delegation in real time.

The governance gap is that most customer identity programmes still treat authentication as the finish line. Once AI assistants, proxies, partners, and delegated actors can act on behalf of users, IAM and IGA teams need a control model that can constrain action at the point of use, not only at session start.

Key questions

Q: How should security teams enforce access decisions after login in CIAM?

A: They should use runtime authorization to evaluate each sensitive action against current consent, context, and entitlement state. That means the access decision happens at the point of use, not only when the user authenticates. This approach reduces inconsistency across apps and APIs and gives auditors one policy layer to inspect.

Q: When does delegated access become a governance risk?

A: Delegated access becomes risky when the delegate keeps permissions after the business purpose, relationship, or time window has ended. The control failure is usually not the initial grant, but the lack of explicit expiry and revocation. IAM teams should treat delegation as a scoped entitlement with lifecycle controls, not a permanent exception.

Q: What breaks when AI assistants are allowed to act on behalf of users without policy checks?

A: The assistant can make legitimate-looking requests that exceed the user's intended scope, especially when it can retrieve data, call APIs, or generate responses across sensitive systems. Without action-level policy checks, authentication becomes a weak proxy for authorisation. Teams lose the ability to prove that each AI-driven action stayed inside the approved boundary.

Q: How do teams know whether portable trust is actually working?

A: They should verify that the same policy outcomes are enforced across web, API, microservice, and data access paths, and that decisions change when consent or context changes. If the enforcement point differs by application, the model is not portable. Consistency, revocation speed, and auditability are the practical indicators.

Technical breakdown

Runtime authorization across APIs, microservices, and data layers

Runtime authorization evaluates access at the moment an identity tries to act. Instead of embedding static authorization logic in each application, policy engines centralise rules and use current context such as device, consent, user attributes, and transaction risk. That allows row-level, column-level, API, and application decisions to stay aligned as business conditions change. The architectural difference matters because the decision no longer depends on a token alone. It depends on whether the requested action is still allowed under the current policy state.

Practical implication: move sensitive access decisions out of application code and into centrally governed policy enforcement points.

Delegated access and proxy relationships in CIAM

Delegated access is not just another role. It is an identity acting under a constrained mandate, such as a financial proxy, power of attorney, or customer support delegate. The authorization model has to represent both the primary identity and the delegated scope, then revoke or narrow access when the context ends. If that logic is missing, the delegate inherits privileges that outlive the business relationship, which creates audit and exposure problems across customer data, transactions, and analytics.

Practical implication: model delegation as a first-class policy state with explicit scope, expiry, and revocation handling.

AI assistants need entitlement-bound policy, not blanket access

When an AI assistant operates on behalf of a user, authentication only proves who initiated the session. The harder problem is controlling what the assistant can retrieve, generate, or expose once inside the environment. Runtime authorization is what keeps the assistant bound to the user's entitlements, consent, and business context. Without that boundary, an assistant can cross from helpful automation into unscoped data exposure or unintended API action, even when the original login was legitimate.

Practical implication: require AI-assisted workflows to inherit policy constraints from the user and re-evaluate them before every sensitive action.

NHI Mgmt Group analysis

Portable trust is a CIAM control model, not a branding layer. The real change here is that authorization has moved from a back-end concern to the centre of customer identity governance. Once access must follow the identity across applications, APIs, data, and delegated actors, static role design stops being enough. Practitioners should treat portable trust as a policy architecture problem, not a user experience feature.

Static authorization logic creates an identity governance blind spot. Hardcoded rules in application code fragment the policy surface and make access decisions inconsistent across channels. That fragmentation matters more when consent, device, behaviour, and delegation can all alter the permitted action. The practitioner implication is that governance teams need one decision layer they can audit, test, and change without rewriting every application.

AI-assisted access makes the decision boundary more important than the login boundary. When an assistant can retrieve data or trigger responses on a user's behalf, the identity event that matters is the action, not just the authentication. This is where CIAM, NHI-style runtime control, and human identity governance converge. Teams that still think in session terms will miss the point at which policy actually needs to intervene.

Consent and delegation are now the same governance problem at different scales. A customer granting an accountant limited access, a proxy acting for a patient, and an AI assistant acting on behalf of a user all require explicit scope control. The common failure mode is access that remains valid after the relationship or purpose changes. Practitioners should manage these relationships as governed entitlement states, not as one-time login events.

Portable trust is the named concept this market needs because the perimeter has already moved. Identities now cross organisational and technical boundaries while retaining action authority. That means trust must travel with the identity, but only within a bounded policy context. Practitioners should use this model to decide where authentication ends and continuous authorisation begins.

From our research:

• Strong governance depends on shortening the exposure window, because 91.6% of secrets remain valid five days after the targeted organisation is notified, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams still cannot reliably map who or what can act inside critical systems.
• For a broader governance baseline, the Ultimate Guide to NHIs also shows that 97% of NHIs carry excessive privileges, reinforcing why action-level policy matters.

What this signals

Portable trust will force customer IAM teams to think like policy engineers. The operational question is no longer whether a user authenticated successfully, but whether each downstream action still matches the approved purpose. That is a material change for CIAM, IGA, and consent governance because the control plane has to follow the identity across channels, not stop at the session boundary.

The research signal is clear: 91.6% of secrets remain valid five days after the targeted organisation is notified, according to the Ultimate Guide to NHIs. That same kind of remediation lag is what makes delayed policy updates dangerous in delegated and AI-assisted customer journeys.

Identity blast radius: this is the practical metric teams should watch when customer accounts can proxy, share, or delegate access. If authorization rules are not consistently enforced across apps, APIs, and data paths, then the blast radius is defined by the least controlled integration, not by the login process.

For practitioners

• Move sensitive decisions into runtime policy enforcement Centralise authorization for application, API, and data-layer decisions so access can be evaluated against current consent, context, and entitlement state instead of static code paths.
• Model delegation as an explicit access state Define delegated access with scope, expiry, and revocation conditions so proxies, accountants, and other on-behalf-of actors do not inherit broad standing access.
• Bind AI-assisted actions to the user's entitlement boundary Require assistants and agents to re-check policy before each sensitive retrieval, response, or API call so their actions remain within the authenticated user's permissions.
• Separate authentication events from authorization decisions Treat login as identity proof, then apply a second control layer that can allow, narrow, or block specific actions as context changes across the customer journey.

Key takeaways

• CIAM is no longer complete when authentication succeeds, because real governance now happens at the point of action.
• Delegated access and AI-assisted workflows require explicit scope control, expiry, and revocation or they inherit excess authority.
• Portable trust is only credible when policy enforcement is consistent across applications, APIs, and data layers.

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 Authorization: An access control approach that evaluates whether a specific action is allowed at the moment it is requested. It uses current policy, context, and entitlement state rather than relying only on a login event or static role assignment.
• Delegated Access: Permission granted to one identity to act on behalf of another within a limited scope. In practice, it should carry explicit boundaries for purpose, duration, and revocation so the delegate does not outlive the business relationship.
• Action-Level Policy: A governance pattern where each meaningful action is checked against current policy before it is allowed to proceed. It matters when users, proxies, or AI assistants can retrieve data, call APIs, or expose information inside sensitive workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by PlainID: Portable trust for AI and delegated access in CIAM. Read the original.