Topic starter
30/09/2026 4:59 pm
TL;DR: AI-built applications often create duplicate directories, hardcoded permissions, and stale access decisions because authentication and authorization are handled inside each app, according to C1.ai. Moving sign-in and permissions into a governed control plane makes access review, revocation, and request workflows enforceable before app-specific sprawl becomes another identity problem.
NHIMG editorial: what this means for NHI practitioners
Questions worth separating out
Q: How should security teams govern data access for AI workloads?
A: They should govern AI data access by business purpose, dataset classification, and downstream reuse, not by repository alone.
Q: What breaks when AI-built apps keep permissions in local code?
A: Local permission logic ages quickly.
Q: When should teams use externalized authorization for new apps?
A: Teams should use externalized authorization from day one when the app will need access reviews, separation-of-duties checks, or rapidly changing roles.
Practitioner guidance
- Externalize application sign-in Use federated sign-in so AI-built apps rely on the enterprise identity provider instead of creating local user tables or password stores.
- Move permissions out of code Centralise authorization decisions in a governed policy layer so access changes do not require editing source code or waiting for redeploys.
- Embed request and approval flows Make denied access a governed entitlement request with owner approval and time-bound access rather than a help-desk ticket or developer exception.
What's in the full announcement
C1.ai's full product announcement covers the operational detail this post intentionally leaves for the source:
- How governed sign-in is wired into an existing identity provider through OpenID Connect
- How OpenID AuthZEN decisions are evaluated against the entitlement graph at request time
- How access requests, approvals, and time-bound entitlements work inside the application flow
- How the same control model is extended across AI-built applications, traffic controls, and model usage
👉 Read C1.ai's announcement on governed sign-in and permissions for AI-built applications →
AI-built app permissions: what changes for identity teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
30/09/2026 5:00 pm
AI-built applications become identity islands when authentication and authorization are coded locally. The article shows the classic failure mode: each app starts with its own login, its own permission model, and its own maintenance burden. That creates duplicate directories, stale access, and hidden offboarding gaps that the enterprise cannot govern consistently. The practitioner lesson is that app-level convenience becomes identity sprawl unless access is externalized early.
A question worth separating out:
Q: What is the difference between federated sign-in and app-local access control?
A: Federated sign-in answers who the user is by relying on the enterprise identity provider. App-local access control answers what the user can do, but if that logic lives inside each app it becomes hard to review, revoke, and keep consistent across the estate.
👉 Read our full editorial: Governed sign-in and permissions for AI-built apps reduce access sprawl
