Topic starter
30/09/2026 4:59 pm
TL;DR: C1.ai's analysis of AI-built applications finds local sign-in and permissions create duplicate directories, hardcoded permissions, and stale access decisions. Centralized authentication and externalized authorization make access easier to govern, review, and revoke without code changes.
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: 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.
Q: What breaks when AI-built apps keep permissions in local code?
A: Local permission logic ages quickly.
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.
Glossary terms: Externalized Authorization, Federated Sign-In, Application entitlement, Identity Sprawl
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 →
This topic was modified 4 days ago 2 times by NHI Mgmt Group
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