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.
At a glance
What this is: This is a product announcement about governed sign-in and permissions for AI-built applications, with the key finding that access should be externalized from each app into shared identity governance.
Why it matters: It matters because IAM and IGA teams need app access to inherit the same request, approval, review, and revocation controls they already use elsewhere, rather than creating isolated permission systems.
👉 Read C1.ai's announcement on governed sign-in and permissions for AI-built applications
Context
AI-built applications often fail as soon as they need identity decisions. If sign-in and authorization are implemented separately inside each app, teams end up with duplicate user stores, hardcoded allowlists, stale group copies, and offboarding gaps that the wider identity programme cannot easily see.
The governance problem is not just authentication. It is whether application access stays connected to enterprise policy after launch, especially when permission changes, access reviews, and revocation need to happen without a code change or a redeploy.
Key questions
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. If AI systems can transform or redistribute data, then the entitlement review must cover how the data will be used after access is granted. That requires tighter alignment between IAM, data governance, and AI owners.
Q: What breaks when AI-built apps keep permissions in local code?
A: Local permission logic ages quickly. Group copies go stale, allowlists drift, offboarding misses hidden apps, and even small access changes start requiring engineering work. The result is fragmented entitlement control, inconsistent enforcement, and a much harder certification process for security teams.
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. If authorization is left in code, every policy change becomes a development task instead of an identity governance decision.
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.
How it works in practice
OIDC federation for AI-built application sign-in
The article describes the app as using OpenID Connect federation rather than keeping its own password store. In this pattern, the application delegates authentication to an existing identity provider and receives a signed identity assertion back. That avoids a separate local user table, but it also means the application must treat identity as an externally governed input instead of an internal database record. The main architectural shift is that sign-in becomes an enterprise control, not an application feature.
Practical implication: keep AI-built apps on federated sign-in and avoid creating app-local accounts or password stores.
Externalized authorization with OpenID AuthZEN
Authorization here is not a static role check buried in code. The application asks an external policy endpoint whether a specific user can perform a specific action on a specific resource, and the decision is evaluated in real time against the entitlement graph. This means access can reflect current policy, not yesterday's copied group membership or a cached allowlist. It also makes policy updates portable across applications because the app consumes decisions instead of reimplementing logic.
Practical implication: move permission decisions out of application code and into a governed authorization service.
Access requests and certification as part of the app flow
The article ties denial, request, approval, and revocation into the same access path. That matters because access control is not only about blocking actions, but about creating an auditable workflow when a user lacks entitlement. When the request path is built into the application, the same governed control can support time-bound access, owner approval, and later certification. Without that, teams end up recreating ticketing logic in every app or leaving users stranded at an error page.
Practical implication: embed request and approval workflows so denied access becomes a governed entitlement process, not a help-desk workaround.
NHI Mgmt Group analysis
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.
Governed sign-in only works when authorization is equally governed. Federated authentication solves one part of the problem, but hardcoded allowlists and copied directory groups still leave permissions out of sync with policy. Externalized authorization is the more important control plane because it lets reviews, revocation, and separation-of-duties decisions affect the next request instead of waiting for code changes. Teams should treat application permissions as governed entitlement, not local configuration.
Access request workflow is part of identity control, not user experience decoration. The article correctly ties denial to approval and time-bound access, which is how access governance becomes operational rather than theoretical. When that workflow is absent, employees create shadow processes through tickets, chats, or developer intervention. The implication is simple: if the application cannot request, approve, and expire access, the enterprise will recreate those controls informally and inconsistently.
Named concept: application identity sprawl. This is what happens when every AI-built app becomes a mini identity system with its own user store, its own permission logic, and its own lifecycle gaps. That pattern is structurally hard to review, certify, and revoke at scale, because governance fragments by application instead of by entitlement. Practitioners should stop treating AI-built apps as isolated products and govern them as part of the enterprise identity estate.
Day-one governance is the real signal here. The article's strongest implication is not the feature set itself, but the assumption that new AI-built applications should inherit identity control from launch. That aligns with how identity programmes are moving: controls are shifting left into build and release cycles rather than being bolted on after access problems appear. Teams should re-evaluate how quickly new apps can be brought under the same review and revocation model as the rest of the estate.
What this signals
Application identity sprawl: AI-built apps that carry their own login and permission model create a new class of governance debt. The control objective is not just preventing account duplication, but ensuring every app entitlement remains visible to access review, revocation, and offboarding processes.
Governance programmes should expect the next wave of app risk to come from identity fragmentation inside business-built software, not only from external SaaS. The practical response is to treat federated authentication and externalized authorization as baseline requirements for any app that handles enterprise access.
For practitioners
- 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.
- Align offboarding with app entitlements Ensure application access revocation is driven by enterprise lifecycle events, not by whether someone remembers a hidden allowlist or user table.
Key takeaways
- AI-built applications create governance debt when each app manages its own sign-in and permissions instead of using shared identity controls.
- The operational problem is stale access, hidden offboarding gaps, and permission changes that still depend on code updates or redeploys.
- Externalized authorization and embedded request workflows make access decisions reviewable, revocable, and consistent across the application estate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on federated sign-in versus app-local authentication for AI-built applications. |
| NHI-05 — Overprivileged NHI | Locally copied roles and allowlists can leave AI-built apps with access broader than intended. | |
| Recommendation — Use federated authentication and avoid app-local credential stores for AI-built applications. Audit app entitlements for excess access and reduce permissions to the minimum needed for each action. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The governance pattern applies to AI-built applications that can mis-handle identity and privilege decisions. |
| Recommendation — Externalize identity and privilege decisions so application logic cannot silently expand access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The announcement is fundamentally about governing permissions and authorizations across applications. |
| Recommendation — Apply PR.AA-05 to centralize entitlement decisions and keep application access reviewable. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The access model depends on limiting what each user can do inside an AI-built app. |
| Recommendation — Enforce least privilege so application entitlements do not default to broad access. | ||
Key terms
- Federated Sign-In: Federated Sign-In lets a user access one system using credentials managed by another trusted identity provider. Technically, it relies on trust relationships, usually through SAML, OIDC, or similar federation protocols, so the service provider accepts an external assertion about the user’s identity, authentication state, and sometimes group or role attributes.
- Externalized Authorization: A design pattern where access decisions are removed from application code and handled by a separate policy layer. This makes authorization easier to govern, test, audit, and reuse across services, especially when roles, attributes, and request context change frequently.
- Entitlement Graph: A mapped view of who or what has access to which systems, roles, and privileges. It provides the operational basis for review, certification, and segregation-of-duties analysis. Without it, teams rely on disconnected reports that cannot reliably prove control effectiveness.
- Application Identity Sprawl: Application identity sprawl occurs when each application becomes a separate identity system with its own accounts, permissions, and lifecycle gaps. It fragments governance, makes offboarding incomplete, and creates hidden access paths that the enterprise only discovers after controls have already drifted.
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
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
