C1 Launch Week continues. Monday gave teams a governed place to build internal apps and agents. Tuesday covered who can sign in and what they can do. Today we're closing the gap between those two: how an app or agent gets the credential it needs without ever holding onto it.
Today we're launching credential vending and C1 Egress. C1 mints a scoped, short-lived credential the moment a workload needs one instead of handing out a durable secret to keep. C1 Egress sits on the network path and substitutes the real credential only when a request is going somewhere policy allows, so the application itself never holds it. Together they eliminate hardcoded credentials and close the revocation gap that turns a long-lived credential into a breach.
Hardcoded credentials spread quickly#
App development has changed. Team members across the organization are now empowered to be builders and solve problems, but the person who built your newest internal app may never have heard the phrase "hardcoded credential."
Every app that connects to company data, a third-party service, or an API needs credentials. The usual approach is to paste an API key or token into an environment variable or configuration file, and from there it moves — into a code repository, a container image, a screenshot in a support thread, an agent's context window, or someone's laptop.
Once a credential spreads, it becomes difficult to answer basic questions: who created it, what can it access, where is it stored, when was it last used. Revoking it means finding every copy and shipping a new deployment. That was manageable when a small group of engineers built every internal application. It does not scale when anyone in the company can create an app or agent in an afternoon.
C1 mints the credential instead#
Rather than asking an app to hold its own secret, C1 mints a credential when the workload needs one. Each credential is scoped to a specific role and restricted to approved IP ranges, so if it leaks, it grants far less than a long-lived API key would. Credentials are delivered through a vault rather than handed to the application for permanent storage.
A central credential inventory shows who minted a credential, what it can do, and when it was last used, so teams no longer have to piece that history together from whichever secrets tool each builder happened to choose. Every issuance, use, and revocation is recorded in an audit trail, and revocation takes effect on the next call instead of waiting for the next deployment.
This shows up in a few familiar scenarios:
- AI agent task access. A credential is minted when a task starts and expires when the task ends, so the agent gets only the access that job requires with no standing access afterward.
- Contractors and automated pipelines. Short-lived workers and CI/CD jobs receive just-in-time credentials governed by the same policy engine used for employee access.
- Service account replacement. Teams can replace shared, never-rotated service credentials with per-task credentials tied to a specific identity and purpose.
C1 Egress keeps the secret out of the workload#
Credential vending controls what a credential can do. C1 Egress controls where a request can go.
The proxy sits between an internal app or AI 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. Requests to internal addresses and cloud metadata endpoints are blocked by default, closing a common path attackers use to trick agents into exposing data.
Every call is logged with its source, destination, and policy decision — the secret itself is never recorded. Because enforcement happens at the network layer rather than inside an environment variable, it still applies even when application code tries to route around the intended path. Inspect the workload's environment and there's no credential in it for an attacker to find, because it never held one.
Secure by default, not by expertise#
The builder shouldn't need to become a secrets-management expert before shipping a secure internal app. With credential vending and C1 Egress, the safe outcome comes from the platform and from policy that can be reviewed, updated, and enforced — not from every individual builder getting it right.
That's what makes it possible to let thousands of internal apps and AI agents work with real company data quickly and securely.
Day 1 made shadow AI visible. Day 2 brought identity and access under one roof. Today, Day 3 makes the safe path to credentials the automatic one. Tomorrow is our final drop of launch week — check back to see it.
Apps and agents need access to secrets. They don't need to store them.
Book a demo at c1.ai.
Adopt AI, fearlessly.
FAQ#
What is credential vending?#
Credential vending is how C1 issues application and agent credentials on demand instead of handing out a durable secret to store. Each credential is minted at the moment a workload needs it, scoped to a specific role, restricted to approved IP ranges, and tracked in a central inventory with a full audit trail of every issuance, use, and revocation.
What is C1 Egress?#
C1 Egress is a governed proxy that sits between an internal app or AI agent and the network. It substitutes the real credential onto a request only when the destination is allowed by policy, blocks requests to internal addresses and cloud metadata endpoints by default, and logs every call's source, destination, and decision without ever recording the secret itself.
How is this different from an environment variable?#
An environment variable puts the real secret inside the application, where it can end up in logs, crash dumps, repositories, or a container image. Credential vending keeps the secret out of the application entirely, and C1 Egress injects it only at the moment of an approved outbound request.
Why does revocation matter so much?#
A hardcoded credential is only as safe as every place it's been copied to. Finding and rotating every copy typically means a new deployment. Because C1 mints and injects the credential itself, turning it off takes effect on the very next call — no redeploy required.
