TL;DR: C1.ai says applications often leak reusable secrets into code, containers, and agent context windows, creating a revocation gap that only ends when every copy is found and redeployed. Credential vending and egress proxying shift control to scoped, time-bound issuance and network-layer substitution, making revocation immediate and exposure much harder to sustain.
At a glance
What this is: This is a C1.ai press release about credential vending and governed egress for applications, with the central finding that removing reusable secrets from the app path reduces exposure and accelerates revocation.
Why it matters: It matters because IAM and NHI teams need controls that survive code sprawl, container reuse, and agentic runtime paths, not just vault storage in theory.
👉 Read C1.ai's announcement on credential vending and governed egress for applications
Context
Applications are not failing because secrets exist, but because reusable credentials stay embedded in places the owning team cannot reliably inventory or revoke. Once a credential is copied into configuration, logs, containers, or runtime context, the governance model shifts from issuance to recovery, and recovery is usually too slow.
For identity programmes, that creates a non-human identity governance problem rather than a simple secrets-storage problem. The question becomes whether access can be issued, observed, and revoked at the same pace as application execution, especially when builders can create and ship software faster than security teams can chase every copy.
Key questions
Q: What breaks when hardcoded secrets are used in cloud environments?
A: Hardcoded secrets break the normal lifecycle of credentials because they move outside vaulting, rotation, and revocation controls. Once a credential is embedded in code or configuration, it can be copied, reused, and forgotten. That creates a long-lived exposure path that IAM teams often cannot see until the secret is already in use.
Q: How should teams decide between stored secrets and credential vending?
A: Use credential vending when the workload only needs temporary access and can be governed through scope, expiry, and audit. Stored secrets are harder to justify when the same permission can be issued just in time and revoked immediately after use.
Q: What are the signs that secret governance is failing?
A: Common signs include secrets that never expire, weak rotation discipline, and inconsistent lifecycle management across vaults and applications. Another warning signal is when security teams cannot quickly identify where a secret is used or who owns it. If those controls are missing, the organisation is likely relying on fragile manual processes instead of enforceable policy and continuous oversight.
Q: How do egress proxies and credential vending differ in application identity control?
A: Credential vending governs how access is issued and tracked, while an egress proxy governs where the application can use that access. The first addresses secret lifecycle and auditability, and the second prevents the workload from bypassing policy or carrying the real secret in its own environment.
How it works in practice
Why hardcoded application secrets create a revocation gap
A hardcoded secret is any reusable credential placed inside code, configuration, or runtime state so the application can authenticate without an external issuance step. The technical failure is not storage alone. It is that each copy becomes an independent revocation problem, and the team loses a single control point for expiry, rotation, and audit. Once the same credential appears in repositories, images, screenshots, or agent context, the blast radius expands across every copy that inherited it. That is why vault-only strategies often fail at the moment of compromise: the system can no longer prove where the secret lives.
Practical implication: Treat every embedded reusable credential as a governance failure until issuance, inventory, and revocation are centrally controlled.
How credential vending changes application authentication
Credential vending replaces static secret distribution with on-demand issuance of scoped credentials. In this model, the application does not store the long-lived secret itself; it receives a time-bound credential tied to role, policy, and often network constraints such as allowed IP ranges. The control value comes from lifecycle ownership: every mint, use, and revocation can be logged and reviewed, which means the organisation can answer who issued access, what it can reach, and when it was last used. That moves the problem from secret hiding to access governance.
Practical implication: Use issuance logs and scope limits as the primary evidence for whether application access is actually governed.
Why network-layer egress control matters for non-human identities
Egress control is the enforcement layer that constrains where an application can send requests, independent of what the code tries to do. By substituting the real secret only at the network boundary, the proxy removes the credential from the application environment while still allowing authorised outbound calls. Blocking internal addresses and cloud metadata endpoints by default also closes common abuse paths where an attacker or misbehaving workload tries to pivot using the application's own trust. The key architectural point is separation of duties: the workload requests access, but the proxy owns secret handling and policy enforcement.
Practical implication: Place secret substitution outside the workload so code changes cannot bypass credential handling or outbound policy.
NHI Mgmt Group analysis
Revocation delay is the real control failure in application secret management. The problem is not simply that secrets are stored, but that reusable credentials keep working after the organisation has lost track of every copy. When revocation depends on finding each embedding point and redeploying code, the control no longer matches the speed of application delivery. Practitioners should treat revocation latency as the core risk indicator, not vault adoption alone.
Credential vending shifts application access from possession to issuance. That matters because governance becomes observable at the moment of minting, not inferred later from where a secret might have landed. Scoped credentials, IP pinning, and audit trails make application access answerable in a way that static secrets never do. For identity programmes, the decisive question is whether issuance is now the governed object.
Governed egress is a stronger boundary than application code. If the enforcement point sits outside the workload, the application cannot silently bypass secret handling by changing how it routes requests. That is especially relevant for modern build-and-deploy patterns where many more people can create applications without deep security knowledge. The implication is that policy must follow the path of execution, not rely on every developer remembering credential hygiene.
Hardcoded credential sprawl is a named governance concept, not a hygiene issue. Once a secret can appear in code, images, screenshots, logs, and agent context, the identity programme is no longer managing one credential but a replicating exposure surface. This is the same structural problem that makes machine identity governance harder than human account governance: the access object outlives the operator's memory. Practitioners should frame the issue as lifecycle control over replicable access, not just secret storage.
From our research library:
- 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.
- Read next: Secrets Management Guide
What this signals
Issuance has to become the control point. Application security fails when the organisation treats secret storage as the end state instead of the beginning of governance. The practical shift is to manage minted credentials the same way identity teams manage access lifecycles, with scope, expiry, and revocation all visible at issuance time.
Secret substitution changes the trust boundary for non-human identities. Once the workload no longer holds the real credential, code review and image scanning stop being the only line of defence. The programme needs enforcement at the point of use, because that is where secret exposure either persists or disappears.
For practitioners
- Audit for embedded reusable credentials Search source code, build artefacts, container images, logs, and agent context windows for secrets that can be copied outside central control.
- Shift application access to issued credentials Replace static credential distribution with scoped, time-bound issuance and keep a complete mint-use-revoke inventory for each application identity.
- Place secret handling outside the workload Use a network-layer enforcement point to substitute real credentials only at authorised destinations and block internal addresses and cloud metadata endpoints by default.
- Measure revocation by request, not redeploy Verify that disabling a credential stops the next call without waiting for application changes, image rebuilds, or redeployment cycles.
Key takeaways
- Reusable application secrets create a governance problem because revocation becomes dependent on finding every copy, not just disabling one credential.
- The operational value of credential vending is that access can be scoped, logged, and revoked as an issued identity event instead of a hidden static artefact.
- Network-layer egress enforcement strengthens application identity control because the workload never needs to hold the real secret in its own environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on eliminating secrets that leak into code, images, and runtime paths. |
| NHI-07 — Long-Lived Secrets | The core risk is reusable credentials that stay valid until every copy is found and revoked. | |
| NHI-05 — Overprivileged NHI | The release emphasizes scoped credentials pinned to role and network limits. | |
| Recommendation — Scan application estates for leaked secrets and move sensitive access out of embedded storage. Replace long-lived application credentials with issued, time-bound access and enforce revocation. Constrain application identities to the minimum role and destination set they actually need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and revocation are central to this application access model. |
| Recommendation — Apply authenticator management to issue, track, rotate, and revoke application credentials. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Hardcoded secrets create a credential-access path and enable downstream exfiltration. |
| Recommendation — Map embedded secret exposure to credential access and monitor for secret theft and reuse. | ||
Key terms
- Credential Vending: Credential vending is the process of issuing temporary access credentials at runtime instead of relying on long-lived secrets. In Lake Formation workflows, it supports short-lived, job-scoped access to governed data, reducing the blast radius of credential exposure and aligning access with the duration of the workload.
- Egress control: Egress control is the policy layer that governs where a service can send outbound traffic. For identity workloads, it is a critical boundary because a request fetch path without outbound restrictions can be turned into a proxy for internal access, credential leakage, or data exfiltration.
- Revocation Gap: The revocation gap is the delay between deciding to remove access and fully eliminating all usable copies of the credential. It grows when secrets are hardcoded, duplicated, or cached across systems, and it is a major failure mode in machine identity governance.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
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 credential vending flow for App Hub applications, including how scoped credentials are issued and logged.
- The egress policy behavior that substitutes the real secret and blocks internal or metadata-bound requests by default.
- The launch-week context that ties this release to App Hub sign-in, permissions, and governed access for applications.
- The vendor's own phrasing on how revocation takes effect on the next call rather than the next deploy.
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 30, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org