KubeCon 2025 showed identity is becoming the cloud-native control plane

At a glance

What this is: KubeCon 2025 highlighted how cloud-native security is moving from network trust to identity-led control across workloads, databases, and AI systems.

Why it matters: For IAM and NHI practitioners, the message is that static credentials and IP-based assumptions are no longer enough for distributed, agent-driven environments.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read GitGuardian's KubeCon 2025 coverage of cloud-native identity and AI security

Context

Cloud-native security is no longer just about hardening clusters or reducing exposure at the perimeter. The practical problem now is governance: workloads, service accounts, and AI agents behave like non-human identities, but many teams still rely on static credentials, network boundaries, and manual trust decisions that do not scale to ephemeral systems.

KubeCon 2025 made that gap visible across multiple talks. The common thread was not a single product category, but a shift toward workload identity, federated trust domains, and policy enforcement that follows the workload. That is a familiar trajectory for cloud-native teams, but it is increasingly the operating model for NHI governance as well.

The article’s starting position is typical for mature cloud-native programmes: it assumes security must be built into the runtime rather than bolted on later. What stood out is how consistently the sessions tied reliability, identity, and rollout discipline together, which is becoming the norm rather than the exception.

Key questions

Q: How should teams govern workload identity in cloud-native environments?

A: Teams should treat workload identity as the primary authorization layer for cloud-native systems. Bind each workload to a stable identity, enforce policy in the runtime, and log identity decisions centrally. That approach is stronger than IP-based controls because workloads move, scale, and restart continuously across clusters and regions.

Q: Why do network controls fall short for Kubernetes and service meshes?

A: Network controls are useful, but they are not a durable trust model because IP addresses, namespaces, and routing change constantly. In Kubernetes and service-mesh environments, identity must travel with the workload so authorization remains valid even when placement changes or traffic is rebalanced.

Q: What is the difference between workload identity and secret-based access?

A: Workload identity proves what a service is, while secrets only prove that something knows a credential. Identity-based controls are easier to govern because they can be issued, rotated, and revoked in a structured lifecycle. Secret-based access often creates hidden standing privilege that is harder to audit.

Q: How should security teams roll out runtime authorization without disrupting services?

A: Start with shadow mode, measure policy impact on live traffic, and promote rules gradually from observation to enforcement. Keep rollback mechanisms available and prioritise critical services for the most careful testing. This reduces the risk of outages while still moving toward stronger identity controls.

Technical breakdown

Why workload identity is replacing network trust

In cloud-native systems, the network is too unstable to serve as the primary trust boundary. IP addresses change, namespaces drift, and service placement shifts constantly, which makes identity based on location fragile. Workload identity instead binds trust to the service account, certificate, or SPIFFE identity that follows the workload across environments. That allows mTLS, authorization policy, and audit trails to stay consistent even when infrastructure moves. The architectural point is simple: if the workload is what acts, then the workload needs the identity. This is also why service meshes and SPIFFE-style identity systems keep appearing in modern platform security designs.

Practical implication: Treat network signals as context, not proof, and base authorization on stable workload identity.

How federated trust domains change NHI governance

Federated trust domains let different clusters, business units, or environments issue and validate identities under a shared trust model without collapsing everything into one flat credential space. A root CA or trust anchor delegates issuance to child domains, which keeps blast radius smaller and makes policy ownership clearer. In NHI terms, this matters because service accounts, automation tokens, and AI agents often span multiple systems that were never designed to share a single authority. The governance challenge is not only technical issuance, but lifecycle control: who can mint trust, who can revoke it, and how cross-domain access is reviewed over time.

Practical implication: Map each trust domain to an accountable owner and review cross-domain issuance as a privileged function.

Why policy enforcement must move into the runtime

A runtime policy model enforces identity and authorization where the connection is actually made, not where the application was deployed. That approach is more resilient than library-only controls because it does not depend on every team rewriting code in lockstep. It also supports gradual rollout through shadow mode, policy simulation, and staged enforcement, which is critical when thousands of services already exist. For NHI governance, the key architectural lesson is that visibility without enforcement is not enough. Teams need runtime decisions that can be tested, observed, and rolled back without stopping production traffic.

Practical implication: Use shadow mode and staged enforcement before turning runtime identity controls on globally.

Threat narrative

Attacker objective: The attacker aims to abuse non-human access paths to move across cloud-native systems without being constrained by the original trust boundary.

1. Entry occurs through weak or static trust assumptions, such as IP-based access or exposed credentials that do not distinguish a legitimate workload from a malicious one.
2. Escalation happens when the attacker can move laterally across services or clusters because identity and authorization are not consistently enforced at runtime.
3. Impact is persistent access to workloads, data paths, or AI infrastructure that should have been isolated by workload identity and scoped policy.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity is becoming the control plane for cloud-native security. The article’s strongest signal is not about Kubernetes alone, but about where trust is being anchored. IP-based controls, static passwords, and ad hoc secrets are too brittle for fleets of short-lived workloads and agents. The discipline now is to treat identity as the primitive that ties authentication, authorization, and audit together. Practitioners should expect cloud-native security to keep converging on workload identity.

Runtime enforcement is now a governance requirement, not a nice-to-have. Security models that depend on every developer team adopting a library change will stall, as the Uber example showed. Shadow mode, proxy-based policy, and incremental rollout are becoming the practical path to adoption. That makes identity governance measurable instead of aspirational. Practitioners should plan for controls that can be enforced where traffic actually flows.

Federated trust domains reduce blast radius, but they increase policy responsibility. The move from one flat trust boundary to nested domains is healthier, but only if lifecycle ownership is clear. Each domain needs documented issuance rules, revocation paths, and review cadence for cross-account access. Otherwise, federation just spreads the problem out more elegantly. Practitioners should pair decentralised issuance with central governance standards.

Cloud-native AI will inherit the same identity failures unless teams act now. The conference’s AI theme was not separate from the security theme. AI systems will run on the same clusters, consume the same secrets, and rely on the same trust patterns as everything else. That means existing IAM assumptions will be tested by agents with real execution authority. Practitioners should design NHI controls for agents now, before those agents become operationally normal.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which is why governance models are moving beyond static credentials.
• NHI Lifecycle Management Guide and NIST Cybersecurity Framework 2.0 help teams turn that shift into operational controls.

What this signals

Identity blast radius: as cloud-native platforms absorb more AI and automation, the question is no longer whether identity exists, but how far it can travel before it is constrained. With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the governance gap is now structural. Teams should expect identity policy to become a first-class platform concern, not an application afterthought.

The practical programme shift is toward observable, staged controls that can survive scale. Runtime policy, federated issuance, and lifecycle review need to be treated as a single operating model rather than separate projects. Teams that can prove who issued access, where it was enforced, and how it can be revoked will be better positioned as agentic systems move into production.

For practitioners, the near-term task is to map existing service accounts, automation tokens, and AI-assisted workflows to accountable owners and explicit trust domains. The control environment will be judged less by whether identity exists and more by whether it can be governed under change.

For practitioners

• Standardise workload identity across clusters Bind services to stable workload identities such as service accounts and certificate-based identities, then remove dependence on IP addresses for authorization decisions. This gives you a consistent control point across clusters, service meshes, and multi-account environments.
• Adopt shadow mode for policy rollout Test new authorization rules in shadow mode before enforcement so you can observe impact, tune exceptions, and avoid breaking critical traffic. Use staged rollout for high-value services and keep an immediate rollback path.
• Document trust-domain ownership and revocation paths Assign named owners to each trust domain, define who can issue credentials, and require documented revocation procedures for cross-domain access. Treat delegation as a privileged governance decision, not just an infrastructure setting.
• Review AI and automation access as NHI scope Include AI systems, bots, and automation pipelines in the same identity review process as service accounts and API tokens. Confirm what each non-human identity can reach, and cap access to the smallest set of resources needed for the task.

Key takeaways

• Cloud-native security is moving from network trust to workload identity, which changes how IAM and NHI teams should define the trust boundary.
• Federated trust domains and runtime enforcement improve control, but only if lifecycle ownership and rollout discipline are explicit.
• AI systems will inherit the same identity weaknesses as existing workloads unless practitioners govern them as NHIs now.

Key terms

• Workload Identity: A workload identity is the machine-verifiable identity assigned to a service, pod, or automation process. It lets security teams authenticate and authorize non-human actors based on what they are, not where they run or which network they came from.
• Federated Trust Domain: A federated trust domain is a bounded identity authority that can issue and validate credentials for a defined environment while remaining connected to other domains. It reduces blast radius, but it also requires clear delegation, revocation, and ownership rules across environments.
• Runtime Authorization: Runtime authorization is access control enforced while traffic is flowing, rather than only at deployment or configuration time. In cloud-native systems, it is how identity policy becomes operational, observable, and reversible without requiring every application team to rewrite code.

What's in the full article

GitGuardian's full post covers the operational detail this post intentionally leaves for the source:

• Session-by-session notes from KubeCon talks on SPIFFE, SPIRE, service meshes, and database identity integration.
• Implementation details on how teams staged rollout, used shadow mode, and handled cross-account policy constraints.
• Examples of how Kubernetes workloads, AI systems, and database access are being stitched together with identity controls.
• Conference observations on where cloud-native security practices are converging across infrastructure, runtime, and AI workflows.

👉 GitGuardian's full post includes the conference lessons, implementation patterns, and AI security implications.

Deepen your knowledge

Workload identity, federated trust domains, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from static secrets toward runtime identity controls, this is a practical next step.