Topic starter
30/09/2026 4:59 pm
TL;DR: C1.ai says AI-built applications often create duplicate directories, hardcoded permissions, and stale access decisions when each app handles sign-in and authorization locally, while governed sign-in and permissions move those decisions into a central control plane that supports access review, request, and revocation. That shifts access governance from app-by-app cleanup to enforceable identity control.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “Introducing sign-in and permissions for your AI-built applications”.
Key questions
Q: What breaks when AI-built apps keep permissions in local code?
A: Local permission logic ages quickly.
Q: Why do app-local permissions increase governance risk for AI-built applications?
A: Because permission decisions hidden in code cannot be certified, revoked, or reused with the same discipline as centrally governed entitlements.
Q: How do teams know if authorization is actually governed in AI-built apps?
A: Look for a live entitlement decision point, a visible request-and-approval trail, and revocation that takes effect without a redeploy or directory sync.
Practitioner guidance
- Inventory app-local identity stores Find every AI-built application that still maintains a local user table, copied directory group list, or hardcoded allowlist, then classify those controls as unmanaged identity dependencies.
- Move sign-in to federated OIDC Require new AI-built apps to authenticate through the enterprise identity provider rather than storing passwords or building a separate login stack inside the app.
- Externalize entitlement decisions Route application authorization to a governed decision service so the app asks for a live permission result instead of relying on cached roles or source-code logic.
Bottom line: AI-built applications create a governance problem when sign-in and permissions are implemented locally instead of through a shared identity control plane.
What's in the full announcement
C1.ai's full post covers the operational detail this post intentionally leaves for the source:
- The request-and-approval flow for AI-built app access, including how the app owner approves a live entitlement change
- The OpenID Connect integration pattern for federated sign-in without creating another user directory
- The AuthZEN-based authorization flow that returns live permission decisions at request time
- The way access review, certification, and revocation are attached to app entitlements rather than code changes
👉 Read C1.ai's analysis of governed sign-in and permissions for AI-built applications →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/09/2026 5:00 pm
AI-built applications become an identity governance problem when they externalise neither authentication nor authorization. The risk is not just duplicate login logic, but the creation of parallel access systems that the enterprise cannot review with the same discipline as core IAM. Once permissions live in code or copied directory snapshots, offboarding and recertification lose their control point. Practitioners should treat app-local identity logic as a programme-level exception, not a normal design choice.
A question worth separating out:
Q: What should security teams do when AI-built apps need model access and spend control?
A: Treat model access as an entitlement, not a convenience feature. Tie each model route to a known owner, an approved provider, and an approval path so spend, data exposure, and revocation can be governed together.
👉 Read our full editorial: Governed sign-in and permissions for AI-built apps reduce access sprawl