Governed sign-in and permissions for AI-built apps reduce access sprawl

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 app-local access logic creates duplicate directories, hardcoded permissions, and stale decisions.

Why it matters: It matters because identity teams need AI-built apps to use governed authentication and authorization patterns from day one, instead of creating another hidden access estate that breaks offboarding, review, and revocation.

👉 Read C1.ai's analysis of governed sign-in and permissions for AI-built applications

Context

AI-built applications become an identity problem when each app invents its own sign-in and permissions model. The immediate issue is not AI itself, but the repeated creation of app-local directories, allowlists, and approval paths that drift away from the company’s governed access model.

In this article, C1.ai positions governed sign-in and permissions as a way to keep authentication and authorization under the company’s existing identity governance system. That matters for AI-built apps because the access boundary is often created after the code is written, which makes governance harder to recover later.

The operational question is whether identity controls live inside each application or in a control plane the organisation can review, certify, and revoke centrally. For AI-built apps, that choice determines whether access sprawl is prevented at issuance or cleaned up after deployment.

Key questions

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: 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. When the access model is embedded in the app, every change becomes a developer task, and control evidence is scattered across implementations instead of attached to one governed policy source.

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. If access still depends on stale snapshots, local tables, or code changes, the application is not under durable identity governance.

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.

How it works in practice

Why app-local sign-in creates identity sprawl

When developers embed authentication inside each application, they usually create a local user table or mirror directory groups on a schedule. That pattern works at launch, but it quickly diverges from the authoritative identity source. The result is duplicate directories, stale group membership, and permissions logic hidden in code where access changes become engineering work. In identity governance terms, the application becomes its own mini-IGA domain, but without the controls, review cadence, or offboarding discipline that the enterprise already runs elsewhere.

Practical implication: treat any app-local directory or hardcoded allowlist as a governance defect, not just a development shortcut.

How externalized authorization changes the control model

Externalized authorization moves the permission decision out of the application and into a shared decision point that evaluates a request at the moment of use. In this article, that means the app asks whether a specific person can perform a specific action on a specific resource, rather than trusting a static role snapshot. That model is materially different from copying groups into each app because it can reflect current entitlement state, certification outcomes, and separation-of-duties policy in real time. It also reduces the need to redeploy code just to change access logic.

Practical implication: centralize permission decisions where policies can be changed once and enforced everywhere the app is used.

Why OIDC matters for AI-built app governance

OpenID Connect gives AI-built apps a standard sign-in path without forcing them to become identity stores. The app federates authentication to the existing identity provider, which means employees keep using their current credentials while the application avoids creating another password system. This matters because authentication and authorization are often bundled together in custom app code, which makes them harder to audit and harder to offboard. Separating sign-in from permissions also makes the access record easier to govern because the request, approval, and revocation lifecycle stays attached to the enterprise identity plane.

Practical implication: use federated sign-in to keep authentication authoritative, then govern application entitlements separately from the codebase.

NHI Mgmt Group analysis

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.

Governed sign-in is really a control-plane decision, not an app feature. The valuable shift is that access becomes part of the governed identity estate instead of a hidden configuration file or embedded allowlist. That matters because access review, certification, and revocation only work when the entitlement is visible and centrally enforceable. Identity teams should re-evaluate where the authoritative permission decision lives before AI-built apps multiply the problem.

Real-time authorization exposes a useful named concept: identity sprawl by design. This is the pattern where every app creates its own directories, role copies, and exception workflows because governance was deferred to the code layer. C1.ai’s model is relevant because it shows how fast app-driven convenience becomes access fragmentation. The practitioner takeaway is to stop measuring only whether the app signs in successfully and start measuring whether its permissions remain governable after launch.

AI-built apps do not need bespoke access plumbing to be business-specific. The business logic can stay custom while the identity decision stays standardised. That separation is the important architectural line: use application code for application behaviour, and use the identity plane for who can do what. Practitioners should design for reuse of access policy, not reuse of access exceptions.

This pattern validates a broader governance principle for AI-built software: if access cannot be reviewed, it is not governed. A central control plane makes the entitlement reviewable, revocable, and portable across applications. That is the real test identity teams should apply as AI-built apps move from pilots to production. The programme goal is not fewer apps, but fewer undiscoverable identity decisions.

What this signals

Identity sprawl by design: AI-built apps often start with local convenience patterns that become long-lived governance liabilities. The important programme signal is not the number of apps alone, but whether each app can still be reviewed, revoked, and certified without custom engineering.

The access plane for AI-built apps should be evaluated the same way identity teams evaluate any other governed entitlement source. If the permission model cannot survive an access review, a mover event, or offboarding, then it is not ready for production governance.

For practitioners

• 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.
• Attach access review to application entitlements Make certification and revocation operate on the app entitlement itself, not on an inferred directory group, so removal actually reaches the application boundary.
• Track offboarding coverage for hidden apps Test whether joiner-mover-leaver and offboarding workflows reach AI-built applications that were created outside the standard application portfolio and security review path.

Key takeaways

• AI-built applications create a governance problem when sign-in and permissions are implemented locally instead of through a shared identity control plane.
• The main failure mode is access sprawl: duplicate directories, stale entitlements, and buried permission logic that is hard to review or revoke.
• Centralized authentication and externalized authorization make AI-built app access visible, enforceable, and easier to offboard without code changes.

Key terms

• 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.
• 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.
• Application entitlement: Application entitlement is the permission or access level a user, app, or service has within a software system. It matters because entitlement determines what data can be reached, changed, or deleted, and stale entitlements can remain active long after the original need has disappeared.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.

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

👉 C1.ai's full post shows the request, approval, and live authorization flow in more implementation detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.