# Introducing sign-in and permissions for your AI-built applications > Source: > Published: 2026-09-29 07:00:00+00:00 Every AI-built application needs reliable answers to two questions: Who is signing in, and what are they allowed to do? Too often, each app answers those questions on its own. That leads to duplicate user directories, hardcoded permissions, outdated access, and more work for developers and security teams. C1.ai today launched governed sign-in and permissions for AI-built applications. This feature is baked into the identity governance system a company already uses so developers can ship faster, employees can get access without unnecessary tickets, and security teams gain a clear, enforceable record of who can use each app and what they can do inside it. ## Why AI-built application access breaks down over time[#](#why-ai-built-application-access-breaks-down-over-time) A developer builds a tool with AI. It needs a login, so they wire up an authentication library and create a local user table. Then it needs permissions, so they add a list of email addresses or copy group membership from the company directory on a schedule. Both solutions start aging as soon as the app launches. The local user table becomes one more directory to maintain. Copied group membership falls out of sync when someone changes roles. Permission logic gets buried in source code, where even a simple access change may require engineering work. When an employee leaves, the off-boarding process may never reach an app that IT does not know exists. The gaps are most obvious when someone needs access. The app returns an error, the employee opens a ticket, and a developer has to investigate or deploy a change. A routine permissions decision turns into lost time for everyone involved. C1.ai replaces that patchwork with governed sign-in, real-time authorization, and a built-in way to request access. ## OIDC authentication without another user directory[#](#oidc-authentication-without-another-user-directory) C1.ai acts as a standard OpenID Connect (OIDC) provider for AI-built applications. An app connects to C1.ai, which federates authentication to the identity provider (IDP) the company already uses. Employees keep signing in with their existing credentials. Developers do not have to build a login page, manage passwords, or maintain a separate user table. And C1.ai does not become another password store, because authentication remains with the upstream identity provider. The bigger benefit appears after launch. Access to the application becomes a C1.ai entitlement instead of an entry in a configuration file or a hardcoded allowlist. Teams can manage that access through the same request, approval, access review, certification, and revocation processes they already use for other systems. That changes the experience for everyone involved: - **Developers ship sooner.** They can use a standard OIDC integration instead of building and maintaining authentication infrastructure. - **Employees use familiar credentials.** There is no separate account or password to remember. - **Security teams gain visibility.** AI-built application access appears alongside the rest of the company's governed access. - **Off-boarding reaches the app.** Revocation no longer depends on someone remembering a hidden user table or allowlist. ## Real-time permissions with OpenID AuthZEN[#](#real-time-permissions-with-openid-authzen) Authentication confirms who someone is. Permissions determine what that person can do after signing in. Many AI-built apps make permissions decisions from locally stored roles or copied directory groups. Those snapshots can become stale. They also cannot account for changes in risk, certification status, or separation-of-duties policy at the moment someone tries to take an action. C1.ai exposes an authorization endpoint built on OpenID AuthZEN, an open standard for externalized authorization. The application asks whether a specific person can perform a specific action on a specific resource. C1.ai evaluates the request against the entitlement graph and returns a decision in real time. Rather than copying access data into every app, the application asks for the current decision when it needs one. Because the endpoint is standards-based, developers can use AuthZEN-compatible clients instead of integrating with a proprietary authorization interface. Permissions policies are easier to apply consistently across applications, and teams can change them without rewriting every app. The practical payoff is immediate enforcement. If an access review removes an entitlement, the application can deny the next unauthorized request. There is no need to wait for a redeploy, a directory sync, or a cached permission to expire. ## Turn "access denied" into an access request[#](#turn-access-denied-into-an-access-request) Returning a denial is easy. Helping someone resolve it is where most applications fall short. When employees see an access-denied message, they often have no idea why access was blocked or who can approve it. They file a help desk ticket, message the application owner, or ask a developer to change the code. Each app ends up recreating the same request-and-approval workflow or offering no workflow at all. With C1.ai, an employee can submit that request from the application. The right owner reviews it with the relevant context. If approved, access can be granted for a defined period, and the same authorization check that returned a denial can allow the action. The app does not need a code change or a custom approval system. That gives employees a clear next step without weakening control: - Employees can see why access was denied and what to do next. - Application owners can review requests with useful context. - Time-bound access can expire instead of lingering indefinitely. - Security teams retain the approval history and evidence needed for reviews. - Developers do not have to build ticketing and approval workflows into every app. ## Move permission logic out of application code[#](#move-permission-logic-out-of-application-code) An application's rules, including which records someone can see, which actions they can take, and under what conditions, reflect how the business operates. That logic matters, but it is often written once, buried in code, and understood only by the person who built the tool. When C1.ai handles authorization decisions, those rules become visible and governable. Teams can review them, update them, apply them consistently, and reuse the same model in the next AI-built application. This does not strip away the custom logic that makes an app useful. It gives that logic a durable control plane outside the application itself. Developers spend less time maintaining access plumbing. Employees get a faster route to the access they need. Security teams get stronger evidence of how permissions are granted, used, reviewed, and revoked. AI-built applications remain tailored to the business without turning into isolated identity systems that the company has to discover and govern later. ## Govern AI-built application access from day one[#](#govern-ai-built-application-access-from-day-one) Day one of C1 Launch Week gave teams a governed place to build applications and agents. Day two focuses on who can sign in and what they can do once they arrive. The rest of the week extends that control to the credentials applications hold, where they can send traffic, which models can see company data, and how model usage is metered. Build with AI. Use C1.ai to handle OIDC authentication, real-time authorization, access requests, and ongoing identity governance from the start. Ready to see it in action? [Book a demo](https://www.c1.ai/lp/request-demo) at c1.ai.