Topic starter
30/09/2026 4:59 pm
TL;DR: The core issue is not secret storage alone but the revocation gap and credential sprawl that emerge when applications hold reusable access; credential vending and C1 Egress eliminate hardcoded secrets by issuing scoped, time-bound credentials and keeping the real secret out of the application path, which reduces exposure and speeds revocation, according to C1.ai.
NHIMG editorial: what this means for NHI practitioners
Questions worth separating out
Q: What breaks when hardcoded credentials are left in code or configuration files?
A: Hardcoded credentials break the assumption that access can be rotated, revoked, and audited on demand.
Q: Why do hardcoded credentials create more risk than many teams expect?
A: Hardcoded credentials create risk because they are easy to copy, hard to inventory, and often survive long after the system that used them changes.
Q: What are the signs that a machine credential lifecycle is failing?
A: Look for secrets in source repositories, container images, environment variables, and agent contexts, especially when revocation requires redeployment.
Practitioner guidance
- Implement runtime credential vending Issue application access only at execution time, scope it to the role and network conditions required, and log each mint, use, and revocation.
- Remove hardcoded secrets from application paths Scan source, images, config files, and agent context for embedded credentials and replace them with centrally mediated access.
- Externalise secret handling from the workload Place secret substitution and outbound policy enforcement in a proxy or gateway so the application never stores the real credential.
What's in the full announcement
C1.ai's full press release covers the operational detail this post intentionally leaves for the source:
- The exact launch framing for credential vending and C1 Egress, including how the two controls work together.
- The vendor's description of scoped issuance, audit logging, and revocation behaviour at the request level.
- The policy examples for blocked internal addresses and cloud metadata endpoints.
- The launch-week context and surrounding platform announcements mentioned in the release.
👉 Read C1.ai's press release on credential vending and C1 Egress →
Credential vending for applications: does it close the revocation gap?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
30/09/2026 5:00 pm
Credential vending shifts the control boundary from secret possession to secret issuance. That is the real governance change here. When applications do not hold reusable credentials, the programme can measure who minted access, what it can do, and when it was last used. For NHI teams, that is a materially better control model than trying to discover copies after the fact.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams govern application access without exposing the real secret?
A: Use a mediated access path where a proxy or vault issues the credential only for approved destinations and logs each decision. That approach keeps the application from handling the secret directly, which reduces leakage surface and makes policy enforcement independent of application code quality.
👉 Read our full editorial: Credential vending and egress control reduce secret exposure for apps
