TL;DR: Akeyless shows that platform engineering centralises CI/CD workflows, GitHub Actions, Kubernetes, Argo CD, and portal-driven self-service, but this convenience also concentrates secrets, credentials, and access paths into a smaller set of governable choke points. Short-lived credentials help, yet the real issue is whether teams can manage secret zero, rotation, and access control without leaving exposed windows.
At a glance
What this is: Akeyless argues that platform engineering improves developer velocity, but it also turns secrets management, access control, and rotation into central governance problems across CI/CD and internal developer platforms.
Why it matters: This matters because platform teams now own the trust boundaries around NHI credentials in delivery workflows, where one weak secret can expose pipelines, clusters, and downstream systems at scale.
👉 Read Akeyless's analysis of platform engineering secrets governance for CI/CD workflows
Context
Platform engineering is the practice of building internal toolchains and workflows that let developers ship faster without handling every infrastructure detail themselves. In this article, the security gap is not the platform model itself but the way self-service delivery concentrates secrets, credentials, and access paths across GitHub Actions, Kubernetes, Argo CD, and internal portals.
Secrets management is the discipline of controlling credentials such as API keys, tokens, certificates, and passwords across their full lifecycle. The article’s core point is that platform engineering only stays secure when secret zero, rotation, and access boundaries are governed as part of the platform, not left as pipeline implementation detail.
The risk profile described here is typical of modern platform engineering programmes, not an edge case. As organisations standardise on internal developer platforms and GitOps-style delivery, secrets governance becomes a shared control plane problem rather than an isolated application-team concern.
Key questions
Q: What breaks when platform engineering relies on secret zero in CI/CD workflows?
A: Secret zero creates a single bootstrap dependency that can undermine every downstream workflow if it is stored, shared, or copied into pipelines. When that credential is exposed, an attacker may gain the ability to mint or retrieve additional secrets across repositories, deployments, and environments. Platform teams should treat bootstrap access as a design choice, not a background implementation detail.
Q: Why do long-lived credentials increase risk in internal developer platforms?
A: Long-lived credentials extend the period in which a stolen or overused secret can be abused, especially when the same credential can reach CI/CD, Kubernetes, and data stores. In internal developer platforms, that persistence can turn one compromise into repeated access across multiple systems. Short-lived issuance reduces exposure, but only if the platform limits scope and reuse.
Q: What are the signs that CI/CD secret governance is failing?
A: Common warning signs include shared secrets across multiple pipelines, credentials stored in workflow files or build variables, broad access to secret brokers, and unclear ownership for rotation or revocation. Another signal is when teams cannot explain which workflow minted a credential or why it still exists. Those conditions indicate the platform has weak lifecycle governance, not just a tooling gap.
Q: How should platform teams govern secrets across internal developer platforms?
A: They should treat secrets as part of the platform control plane, not as a separate vaulting concern. That means defining where secrets are created, injected, rotated, and revoked, then mapping each step to an accountable control owner. The key is to reduce the number of places where credentials can be copied or cached outside runtime identity.
Technical breakdown
Why secret zero becomes a platform engineering control point
Secret zero is the first credential or trust mechanism used to obtain other secrets. In platform engineering, it becomes a structural dependency because GitHub Actions, portal automation, and cluster workflows all need a way to authenticate before any dynamic secret can be issued. If that bootstrap path relies on stored long-lived credentials, the entire platform inherits the blast radius of one exposed entry point. The article shows a safer pattern by relying on JWT and Kubernetes auth so the platform can authenticate without hard-coded credentials. That removes one of the most common hidden trust anchors in delivery pipelines.
Practical implication: inventory every bootstrap credential and replace static secret-zero paths with identity-based authentication where possible.
How dynamic secrets change CI/CD trust boundaries
Dynamic secrets are short-lived credentials generated for a specific workload, database, or pipeline action. They reduce exposure duration, but they do not eliminate the need for governance because the platform still has to define who can request them, when they can be used, and what environment they can reach. In this article, the MySQL credential is requested just in time and refreshed as needed, which is the right operational model for reducing persistence. The important detail is that dynamic issuance only helps if the surrounding control plane treats issuance, scope, and expiry as first-class policy decisions.
Practical implication: bind every dynamic secret to workload scope, TTL, and auditable issuance policy rather than treating rotation as a standalone fix.
Why internal developer platforms concentrate NHI governance risk
An internal developer platform centralises access to repositories, deployment tooling, infrastructure targets, and credential brokers. That concentration is useful for standardisation, but it also means a single platform decision can influence many non-human identities at once, including CI jobs, deployment controllers, and application runtimes. The article’s example with Port, GitHub Actions, and Argo CD shows how quickly one self-service flow can spread credential handling across multiple systems. For identity teams, the question is not whether to centralise, but whether the central platform has explicit ownership for secret lifecycle, environment isolation, and access review boundaries.
Practical implication: assign platform ownership for NHI lifecycle controls across the full delivery chain, not just inside one vault or one pipeline.
Threat narrative
Attacker objective: The attacker or insider objective is to reach reusable secrets and deployment paths that allow compromise of multiple applications or environments through one CI/CD workflow.
- Entry occurs through self-service platform workflows that trigger CI/CD automation with stored access paths to secret backends, source control, and deployment systems.
- Credential exposure risk increases when long-lived secrets or bootstrap tokens are available to pipeline jobs, repositories, or logs that multiple roles can reach.
- Privilege amplification follows when the same delivery path can create repositories, provision namespaces, update manifests, and access database credentials.
- Impact is broad because one compromised workflow can expose application secrets, deployment access, and downstream environment credentials across the platform estate.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secrets governance is becoming the control plane for platform engineering. The article shows that GitHub Actions, Kubernetes, Argo CD, and internal portals are no longer separate concerns when they share secret issuance paths. Once platform teams make developer self-service the default, they also inherit responsibility for the lifecycle of every token, password, and certificate that powers it. The practitioner takeaway is that platform engineering and secrets governance must be designed together, not sequenced separately.
Secret zero is the hidden assumption that decides whether a platform is governable. Secret zero was designed for environments where a stable bootstrap credential could be protected and reused safely. That assumption fails when delivery workflows expect machine-authenticated access across multiple systems and environments, because any stored bootstrap secret becomes the most valuable credential in the chain. The implication is that platform governance must stop treating bootstrap access as a convenience layer and start treating it as an identity design decision.
Dynamic secrets reduce persistence, but they do not solve authority sprawl. Short-lived credentials are useful because they shrink the time window in which a secret can be abused. But if the platform can mint them broadly across repositories, jobs, environments, and databases, then the real risk shifts from duration to delegated authority. The practitioner conclusion is that issuance policy, scope control, and environment isolation matter as much as rotation.
Internal developer platforms turn NHI lifecycle governance into a shared operational discipline. The article’s workflow crosses portal requests, CI orchestration, repository creation, container builds, and deployment automation. That means offboarding, revocation, rotation, and auditability cannot sit in a single team’s backlog or toolchain. The right governance model is cross-platform ownership with clear controls over which workflow may request which credential, under which condition, and for how long.
Identity blast radius is the right concept for platform engineering risk. A single delivery workflow can touch many identities, many secrets, and several runtime environments in one chain. That is not just secret sprawl, it is blast-radius expansion through trusted automation. For practitioners, the question becomes how much damage one workflow can do if its trust boundary is compromised, and whether that boundary is explicit in policy.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Secrets Management Buyer's Guide
What this signals
Identity blast radius is the operating metric that platform teams should watch. When a single workflow can request repository access, deployment access, and database credentials, the issue is no longer just secret sprawl. The programme question is how much damage one compromised pipeline can do before the trust boundary is crossed.
Platform engineering teams should assume that self-service will concentrate non-human identity risk unless governance is built into the platform contract. That means the controls for issuance, rotation, revocation, and environment isolation belong in the platform design, not in separate downstream scripts or local team practices.
For practitioners
- Map every secret-zero dependency Document which CI/CD jobs, portal automations, and deployment controllers still rely on bootstrap credentials, then classify which ones can move to workload authentication or short-lived tokens.
- Enforce per-workflow secret scoping Limit each pipeline to the exact repositories, namespaces, database targets, and secret classes it needs, and deny reuse across environments by default.
- Separate platform control from application convenience Treat repository creation, manifest updates, and secret issuance as distinct policy decisions so one workflow cannot silently expand into unrelated privileges.
- Audit dynamic secret issuance paths Review who can mint short-lived database or deployment credentials, what approvals or identities are required, and how expiry is enforced when jobs rerun.
- Log and review cross-system credential use Correlate portal actions, pipeline activity, and vault issuance logs so unexpected credential requests are visible before they become reusable access paths.
Key takeaways
- Platform engineering increases delivery speed, but it also centralises the secrets and credentials that control CI/CD and runtime access.
- The most consequential weakness is not tooling choice, it is whether secret zero, rotation, and scoping are governed as part of the platform.
- Practitioners should treat the platform as a shared identity control plane and define who can mint, use, and revoke each credential path.
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 and NIST CSF 2.0 set 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 focuses on exposed bootstrap secrets and pipeline credential handling. |
| NHI-07 — Long-Lived Secrets | The post argues for short-lived credentials instead of reusable secrets in platform workflows. | |
| NHI-04 — Insecure Authentication | JWT and Kubernetes auth are used to avoid hard-coded credential bootstrap in the workflow. | |
| Recommendation — Scan CI/CD paths for leaked secrets and remove any stored bootstrap credentials from delivery workflows. Replace persistent delivery credentials with short-lived, workload-bound access wherever possible. Use identity-based authentication for secret issuance rather than embedding static login material in pipelines. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and rotation are central to the article's secrets governance message. |
| Recommendation — Apply authenticator lifecycle controls to rotate, revoke, and expire delivery credentials on schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who can access what across platform workflows. |
| Recommendation — Define and enforce least-privilege permissions for every pipeline, portal, and runtime identity. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Compromised CI/CD credentials can expose secrets and move access across environments. |
| Recommendation — Map pipeline-secret exposure to credential-access and lateral-movement detection in CI/CD monitoring. | ||
Key terms
- Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
- Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
- Internal Developer Platform: An internal developer platform is a standardised set of tools, templates, and workflows that lets development teams provision and operate services with less friction. It centralises control to improve usability, which means the platform team's identities and policies become critical security boundaries.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
What's in the full article
Akeyless's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step GitHub Actions workflow design for creating and wiring a secure app template
- Demo-specific configuration for Port, Argo CD, and Akeyless integration across the delivery chain
- Implementation detail for using JWT and Kubernetes authentication to avoid hard-coded bootstrap credentials
- Practical walkthrough of dynamic secret handling for the Flask and MySQL example environment
👉 Akeyless's full post covers the GitHub Actions, Port, and Argo CD workflow in implementation detail.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org