TL;DR: Revocation gaps, not just secret storage, are now the operational failure mode for NHI governance, and credential vending and C1 Egress remove hardcoded secrets from apps and AI agents by issuing short-lived, scoped credentials on demand and injecting them only when policy allows a request, according to C1.ai.
At a glance
What this is: This is a product announcement about credential vending and a governed egress proxy that keep secrets out of applications while narrowing credential scope and lifetime.
Why it matters: It matters because IAM teams now have to govern where credentials are issued, used, and revoked across apps, agents, pipelines, and service accounts, not just where they are stored.
👉 Read C1.ai's article on credential vending and C1 Egress
Context
Credential vending is a model where an application or agent receives a short-lived credential only when it needs one, rather than holding a durable secret in memory, code, or configuration. The governance problem is not only exposure at rest, but also the spread of the same credential across repositories, images, logs, screenshots, and support threads.
For NHI programmes, this shifts the control point from static secret management to issuance-time policy and network-time enforcement. It also changes the revocation problem, because the useful security boundary is no longer the stored secret alone, but the combination of role scope, destination policy, and auditability.
Key questions
Q: What breaks when apps and agents keep hardcoded secrets?
A: Hardcoded secrets create a spread problem, not just a storage problem. The same credential can end up in repositories, images, logs, screenshots, and agent context windows, which makes ownership and revocation ambiguous. Once the copy count grows, the organisation loses control over where access exists and how quickly it can be removed.
Q: When does short-lived credential issuance reduce risk most effectively?
A: It reduces risk most when the workload only needs access for a single task, a bounded job, or a narrowly approved destination. In those cases, on-demand issuance limits blast radius and makes revocation effective on the next call instead of on the next deployment.
Q: What do security teams get wrong about secret rotation?
A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.
Q: How should teams govern credentials for AI agents and CI/CD jobs?
A: They should govern them as task-scoped non-human identities, not as permanent application secrets. That means assigning short-lived credentials, limiting destinations, logging issuance and use, and ensuring the identity cannot keep access after the task ends or the pipeline completes.
How it works in practice
How credential vending changes secret custody
Credential vending replaces durable secret custody with on-demand issuance. Instead of storing an API key or token inside a workload, a broker mints a scoped credential at the moment of use and ties it to a role, destination constraint, or time window. That narrows the blast radius if the credential leaks, because the secret is no longer a permanent bearer token sitting in a repository or environment variable. It also improves inventory, because issuance, use, and revocation can be tracked centrally rather than inferred from scattered secret stores.
Practical implication: move from static secret placement to policy-governed issuance for workloads that only need temporary access.
Why egress policy matters for workload identity
C1 Egress represents a different control layer: it sits on the outbound path and injects the real credential only when the destination is approved. That matters because many secret leaks happen after the app has already obtained the credential, whether through prompt injection, misrouting, or code abuse. By keeping the secret out of the workload and adding it only at the network boundary, the control reduces what the application can exfiltrate or misuse. The model also blocks internal addresses and cloud metadata endpoints by default, which closes a common route for privilege abuse.
Practical implication: treat outbound control as part of identity governance, not just network filtering.
What revocation looks like when secrets are no longer hardcoded
Traditional revocation is slow because the same secret may exist in many places, so turning it off often requires finding copies and redeploying. Credential vending changes the revocation mechanism by making the issuer authoritative for each call. If a credential is cancelled at the policy layer, the next request fails without waiting for a new build or image rollout. That is a materially different operating model for NHI governance, because the control boundary moves from endpoint cleanup to centralized enforcement and audit.
Practical implication: design revocation around issuance control and next-call enforcement instead of deployment-dependent secret replacement.
NHI Mgmt Group analysis
Credential custody, not credential possession, is the real control boundary: the article shows why keeping a secret out of the workload matters more than simply storing it somewhere safer. When a credential can be pasted into config, copied into images, or inherited by an agent context window, the governance problem becomes propagation, not just storage. That is the right mental model for NHI programmes that have outgrown manual secret placement.
Revocation gap is the failure mode that matters most here: a long-lived secret does not become dangerous only when it leaks, but when the organisation cannot invalidate every copy quickly enough. This is why issuance-time control is more important than post-exposure cleanup. NHI governance has to treat revocation latency as a first-class risk.
Scoped, short-lived credentials align better with workload identity than shared secrets do: the article points toward per-task access, approved destinations, and central auditability as the operational shape of modern machine identity. That does not eliminate risk, but it reduces the consequences of misuse and makes accountability measurable. The implication is a shift from secret ownership to credential lifecycle governance.
Hardcoded secrets are an identity design problem, not a developer etiquette problem: builders will keep shipping apps and agents faster than manual security review can keep up. The control therefore has to be automatic, policy-driven, and tied to workload identity instead of relying on every builder to understand secrets handling. Practitioners should reframe this as a platform governance issue, not user training.
Identity blast radius is now determined by where a credential can travel, not just who created it: the article's egress model shows that request destination is part of identity scope. That matters for NHI governance because the same credential can be harmless in one path and catastrophic in another. Teams should treat destination policy as part of least privilege, not a separate networking concern.
What this signals
Credential vending turns secret handling into issuance governance: the practical shift is away from where a secret is stored and toward how access is created, constrained, and revoked. For teams running apps, agents, and pipelines, the question is no longer whether a secret is encrypted at rest, but whether the workload ever needs to hold it at all.
Destination policy becomes part of least privilege: when egress controls inject a credential only for approved requests, the network path is part of identity scope. That widens the responsibility of IAM and PAM teams, because outbound routing decisions now influence who or what can actually use a credential.
For practitioners
- Inventory hardcoded secret paths Map where API keys, tokens, and certificates are currently copied into code, configuration, containers, logs, and support workflows so you can remove the highest-spread credentials first.
- Shift workload access to short-lived issuance Replace durable shared secrets with on-demand credentials for apps, agents, contractors, and CI/CD jobs where the access need is task-scoped and time-bounded.
- Enforce outbound destination policy Tie credential use to approved destinations and block internal addresses and cloud metadata endpoints by default so the workload cannot freely route around policy.
- Centralise credential audit trails Record who minted each credential, what it can access, when it was used, and when revocation took effect so incident response does not depend on scattered secret tools.
Key takeaways
- Hardcoded secrets are still a governance failure because they spread beyond the original workload and become hard to revoke cleanly.
- Credential vending reduces exposure by issuing short-lived, scoped credentials on demand instead of persisting shared secrets inside applications.
- The strongest control pattern combines issuance-time policy, destination enforcement, and central auditability so revocation works immediately.
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 secrets spreading into code, logs, images, and agent context windows. |
| NHI-07 — Long-Lived Secrets | The post argues that durable credentials create the revocation gap credential vending is meant to close. | |
| NHI-05 — Overprivileged NHI | Scoped, role-bound credentials are the article's answer to excessive access on shared credentials. | |
| Recommendation — Eliminate secret leakage paths by moving workload credentials out of application storage and into governed issuance. Replace long-lived secrets with short-lived credentials where revocation latency creates unacceptable exposure. Constrain NHI credentials to the minimum role and destination scope required for each task. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 governs issuance, rotation, and revocation of authenticators used by non-human identities. |
| AC-6 — Least Privilege | The article's scoped credentials and destination limits directly reflect least-privilege access design. | |
| Recommendation — Apply IA-5 to manage credential lifecycle, rotation, and revocation for workload authenticators. Use least privilege to bound each workload credential to the smallest feasible role and path. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets enable credential access that can be reused for lateral movement across systems. |
| Recommendation — Map exposed workload secrets to credential access and lateral movement detections. | ||
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 Policy Enforcement: A control that restricts where systems can send network traffic. In CI/CD environments, it prevents malicious code from downloading tooling, calling command-and-control infrastructure, or exfiltrating secrets to destinations that are not explicitly approved.
- Revocation Gap: The revocation gap is the delay between discovering a secret should be invalidated and actually removing its usefulness everywhere it exists. For non-human identities, the gap widens when credentials are copied into code, images, logs, or agent context windows, making cleanup slower than exposure.
- Scoped Credential: A scoped credential is a secret, token, or certificate that can only perform a narrow set of actions for a limited time or workflow. For NHI governance, scoped credentials reduce blast radius by preventing an agent from reusing broad access across unrelated systems or tasks.
What's in the full announcement
C1.ai's full article covers the operational detail this post intentionally leaves for the source:
- How credential vending is wired into workload access workflows for apps and AI agents
- How C1 Egress enforces destination policy and blocks internal and metadata endpoints
- How revocation behaves on the next call rather than after a redeploy
- How the central credential inventory and audit trail are structured for operations
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
