Topic starter
05/10/2026 6:49 pm
TL;DR: C1.ai says AI-built applications often rely on hardcoded sign-in lists and local permission tables that go stale, while governed sign-in and permissions instead use existing entitlements, access reviews, and a standards-based authorization endpoint to control access. The identity problem is no longer app creation, but whether application access can stay aligned with enterprise governance at speed.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “C1.ai launches sign-in and permissions for the apps you build”.
Questions worth separating out
Q: How should teams prevent AI-built applications from creating shadow identity stores?
A: Treat local allowlists, copied group tables, and app-specific user records as policy debt.
Q: Why do hardcoded app permissions become a governance problem over time?
A: Because they freeze access decisions at build time while the organisation keeps changing.
Q: What do teams get wrong when they treat application embedded authorization as a simple shortcut?
A: The common mistake is assuming a library removes the need for a real permissions architecture.
Practitioner guidance
- Replace app-local user tables Map every AI-built application that stores its own allowlist or group copy back to the enterprise entitlement source and remove duplicated access state.
- Route authorization through a central policy endpoint Require applications to call a governed authorization service at request time so separation of duties, certification, and revocation are evaluated centrally.
- Fold AI-built apps into recertification cycles Include published apps, their access entitlements, and their revocation paths in the same access reviews used for other governed applications.
What's in the full announcement
C1.ai's full post covers the operational detail this post intentionally leaves for the source:
- The exact governed sign-in flow for AI-built applications, including how builders inherit identity from the enterprise provider.
- The application-permissions request path built on OpenID AuthZEN and how request-time authorization is evaluated.
- How access reviews, separation of duties, and revocation are applied when app entitlements are managed centrally.
- The launch-week context for how this capability fits alongside the broader C1.ai application-governance stack.
👉 Read C1.ai's post on governed sign-in and permissions for AI-built applications →
AI-built app permissions: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
05/10/2026 6:49 pm
AI-built applications expose an identity sprawl problem before they expose a code problem. The control failure is not simply poor engineering, but the tendency to recreate local sign-in and authorization state for every new app. That state diverges from enterprise governance almost immediately, which means the security team loses visibility into who can access what and why. Practitioners should treat this as a governance design flaw, not a development convenience.
A question worth separating out:
Q: What should organisations do when an AI-built app already has local sign-in logic?
A: Move sign-in to the enterprise identity provider first, then replace local permission logic with a central entitlement check. The goal is to stop new access decisions from being created in code, because every duplicated control path becomes another place for stale access to persist.
👉 Read our full editorial: Governed sign-in and permissions for AI-built applications