This week C1.ai shipped four launches for the people building with AI. Coding agents made it possible to create an app in an afternoon but how that app is distributed and managed is still a complex problem to solve. Each launch took one thing every app needs and turned it into a service the app can call: a place to run, sign-in and permissions, credentials it never has to store, and governed access to LLM models. They work independently, but together they pave the road to the agentic enterprise, where the governed path is also the easiest one. In case you missed it, here's what we announced.
Day 1: C1 AppHub#
An internal app can go from idea to created in a matter of hours. No one formally declares it production. It becomes production through use, and it skips the platform and security review that production usually requires. That leaves questions nobody can answer quickly: who has access, which credentials the app holds, where its data goes, and who pays for the tokens.
C1 AppHub is an internal platform based on C1.ai’s best practices. It gives teams a deployment layer they can inspect and a standard way to connect every app to identity, authorization, credentials, network access, and models. Sign-in runs through C1.ai, and the app receives a verified identity. Sensitive actions ask C1.ai for a permissions decision. Apps request scoped credentials instead of storing durable secrets, and model calls route through approved providers with usage tied to an owner and a budget.
Every app gets an owner and lands in access reviews and offboarding, while workloads and data stay in the company's own environment. C1 AppHub also pairs with a skills file that teaches coding agents the company's pattern, so the agent writing the app builds it the governed way from the first commit. C1 AppHub makes the governed path the easy one.
Want to learn more? Check out the C1 AppHub post →
Day 2: Sign-in and Permissions#
Every internal app needs reliable answers to two questions: who is signing in, and what are they allowed to do? Most teams answer them by building a login flow and a permissions table into each app, then copying access data around until it drifts out of date.
C1.ai now acts as a standard OIDC provider that federates authentication to the identity provider a company already uses. C1.ai does not create another user directory or password store. Access to the app becomes a C1.ai entitlement, so it moves through request, approval, review, certification, and revocation like any other access.
For permissions, C1.ai exposes an authorization endpoint built on OpenID AuthZEN. The app asks whether a person can perform an action on a resource, and C1.ai checks the entitlement graph and returns a decision in real time. A revoked entitlement is denied on the next request. When someone hits "access denied," it becomes an in-app access request the owner can review with context and approve for a set window. The app keeps its custom logic without remaining the system of record for who can do what.
Want to learn more? Check out the Sign-in and Permissions post →
Day 3: Credential Vending and C1 Egress#
Hardcoded credentials spread. They end up in repos, container images, screenshots, laptops, and now agent context windows. Revoking one means finding every copy and redeploying everything that used it. Apps and agents need access to secrets, but they do not need to store them.
With credential vending, C1.ai mints a credential at the moment a workload needs it. Each one is scoped to a role, restricted to approved IP ranges, and delivered through a vault. A central inventory shows who minted it, what it can do, and when it was last used, and every issuance, use, and revocation is audited. Revocation takes effect on the next call instead of the next deployment. An agent can get a credential when its task starts that expires when the task ends. Contractors and CI/CD pipelines get just-in-time access in place of standing keys.
C1 Egress closes the other half of the gap. It is a governed egress proxy between the app or agent and the outside world. The workload sends its request without the secret, and the proxy adds the real credential only when policy allows the destination. Internal addresses and cloud metadata endpoints are blocked by default, and every call is logged without recording the secret. Inspect the agent's environment and there is no credential to steal, because the workload never held one.
Want to learn more? Check out the Credential Vending and C1 Egress post →
Day 4: C1 LLM Gateway#
Enterprise AI adoption is moving faster than the controls needed to manage it. When a team shares a provider key, every call loses its identity. Nobody can say which model received the data, who made the call, or what it cost.
C1 LLM Gateway treats routing as policy. Admins decide which models and hosting providers each identity can reach, and route traffic by data sensitivity, performance, and cost. Sensitive workloads can run on company-controlled infrastructure, and specific categories of data can be blocked from specific providers. The gateway separates which model answers a request from who hosts it.
Metered inference covers the spend. Callers go through C1.ai instead of holding a provider key, so each call is attributed to a caller, a model, and a cost. Teams get alerts before they run over, request budget increases through an approval, and receive time-limited access that ends on schedule. Model access and budgets become entitlements with an owner, an approval path, and an end date. Token costs remain the same, but teams can see and address spending before it becomes a problem.
Want to learn more? Check out the C1 LLM Gateway post → Introducing C1 LLM Gateway
Four launches, one paved road#
C1.ai now gives internal apps and agents a place to run, sign-in and permissions from the identity stack you already have, credentials they never have to store, and governed access to models and spend. Catch up on the whole week at Road to the Agentic Enterprise. C1 built a blueprint for securing the internal apps by everyone on your team.