KubeCon Europe 2025 shows identity becoming the control plane

At a glance

What this is: This is an analysis of how KubeCon Europe 2025 reframed AI, workload identity, and authorization around identity-first operations.

Why it matters: It matters because IAM, NHI, and platform teams are now being asked to govern services and AI workloads as durable identities, not as incidental infrastructure.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Cerbos's analysis of identity-first cloud-native operations at KubeCon Europe 2025

Context

KubeCon Europe 2025 highlighted a practical shift in cloud-native security: identity for workloads and AI systems is becoming the operational boundary that governs access, auditability, and trust. For platform and IAM teams, the question is no longer whether services need identities, but how to govern them consistently across clusters, APIs, and AI-driven runtime behaviour.

The article argues that stateless services are no longer the dominant design problem. Long-running workloads, policy-driven authorisation, and autonomous agents create a governance model that looks much closer to IAM than to classic infrastructure management. That makes workload identity, policy enforcement, and traceability central to secure platform operations.

For teams already working through service accounts, secrets, and access governance, this is a familiar direction. The difference is that AI workloads increase the stakes because execution paths are less predictable and more stateful, so identity controls need to be designed into the platform rather than bolted on after deployment.

Key questions

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

A: Start by treating every workload as a first-class identity with an owner, an access boundary, and a revocation path. Use federated or workload-native identity instead of shared secrets, enforce least privilege through external policy, and log every authenticated hop so service-to-service access remains auditable.

Q: Why do AI workloads complicate existing IAM and authorisation models?

A: AI workloads can hold state, make runtime decisions, and trigger downstream actions across multiple systems, so they behave more like governed non-human identities than static services. Existing IAM models often assume stable request patterns and bounded execution, which does not hold when the workload can change its path mid-session.

Q: What breaks when authorisation is hardcoded into application logic?

A: Hardcoded access rules become brittle as systems grow, because each code path must be updated and retested whenever permissions change. That creates audit gaps, slows remediation, and makes it difficult to apply consistent policy across clusters, services, and AI-driven workflows.

Q: How do identity teams reduce blast radius for non-human identities?

A: Limit credential scope, separate duties across workloads, and ensure every identity has a clear offboarding path. The goal is to stop one compromised or over-privileged service from becoming the trust bridge into many other systems, which is where many cloud incidents spread.

Technical breakdown

Why workload identity is becoming the baseline for cloud-native systems

Workload identity gives a service, job, or agent a verifiable digital identity so it can authenticate without shared secrets or manually managed credentials. In modern Kubernetes and service mesh environments, that identity can be federated across clusters and cloud services, which reduces reliance on long-lived tokens. The architecture matters because every hop now carries an identity assertion that can be logged, authorised, and revoked. Without that layer, teams fall back to shared credentials and coarse trust boundaries that do not survive real production complexity.

Practical implication: standardise on unique workload identities and eliminate shared service credentials where possible.

How policy-based authorisation replaces brittle cluster rules

Policy-based authorisation externalises access decisions from application code and cluster configuration. Instead of hardcoding RBAC rules or embedding permissions inside admission logic, teams evaluate requests against contextual policies that can factor in identity, request path, environment, and risk. This is why modern authorisation engines are being adopted alongside observability and CI/CD tooling. The key change is operational: access control becomes a managed control plane, not a pile of static YAML. That is the right shape for systems whose runtime behaviour changes continuously.

Practical implication: move privilege decisions into version-controlled policy so access can be reviewed, tested, and changed independently of code.

What makes AI agents different from stateless workloads

AI agents are not just another containerised service. They can hold state across sessions, make decisions at runtime, and alter their execution path based on context, which creates a wider and less predictable access surface than a normal microservice. Even when they are not autonomous in the strictest sense, they still behave like high-value non-human identities because they initiate actions, consume tools, and touch multiple systems. That changes the governance burden from simple authentication to full lifecycle control, traceability, and runtime guardrails.

Practical implication: classify AI workloads as governed identities and require telemetry, policy enforcement, and offboarding controls from day one.

NHI Mgmt Group analysis

Identity is becoming the control plane for cloud-native and AI operations. The article reflects a broader industry shift away from infrastructure-first thinking toward identity-first governance. When services, schedulers, sidecars, and AI agents all need verifiable access, identity stops being a peripheral control and becomes the mechanism that defines safe execution. Practitioners should treat identity design as platform architecture, not just IAM administration.

Workload identity is the only sustainable answer to service-to-service trust at scale. Shared secrets and static RBAC may work in small deployments, but they do not survive the density and churn of modern clusters. The combination of SPIFFE-style identity, federation, and policy-based access control aligns with the operational reality of ephemeral infrastructure. Practitioners should assume that unmanaged workload credentials will become the weakest control in the stack.

AI workloads raise the governance bar because they behave like stateful, decision-making identities. The article correctly distinguishes between ordinary stateless services and AI systems that retain context, trigger downstream actions, and require runtime oversight. That means the authorisation problem is no longer just who can call a service, but what an AI workload is allowed to decide, invoke, and persist. Practitioners should extend identity governance to AI runtime behaviour, not just to model deployment.

Policy needs to be externalised if teams want auditable access decisions. Hardcoded RBAC and ad-hoc admission controls create brittle trust chains that are hard to change and harder to audit. External policy engines make permissions portable across pipelines, clusters, and services, which is essential when systems evolve faster than app releases. Practitioners should move access logic out of code and into governed policy layers.

Identity blast radius: The article points to a familiar but under-managed failure mode, where one over-privileged workload can become the trust bridge into many others. That is not just a permissions problem, it is an architectural assumption that services will remain bounded by local context. The implication is that practitioners should rethink how far any one non-human identity can travel once it is authenticated.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Use the 52 NHI Breaches Analysis to see how exposed credentials turn into real-world compromise patterns.

What this signals

Identity blast radius: cloud-native teams are moving toward a world where one workload identity can expose entire service chains if privileges, trust bindings, and policy boundaries are not tightly scoped. That means platform and IAM teams should expect identity reviews to become part of architecture review, not just a periodic governance task.

The practical signal is that service accounts, AI workloads, and policy engines now need the same lifecycle discipline that enterprises already apply to human access. If offboarding, ownership, and traceability are weak for non-human identities, the control plane will keep expanding faster than the security programme can observe it.

For practitioners

• Inventory all non-human identities across clusters and pipelines Build a single view of service accounts, sidecars, schedulers, API tokens, and AI workloads so access ownership and trust paths are visible. Start with the identities that can reach production data or control planes.
• Replace shared secrets with unique workload identities Use federated identity patterns and short-lived credentials so each workload has a verifiable identity that can be traced and revoked without impacting unrelated systems.
• Externalise authorisation into version-controlled policy Move access rules out of application code and cluster manifests, then test policy changes like any other production control so they can be reviewed before deployment.
• Define runtime guardrails for AI workloads Limit what AI services can call, what data they can reach, and which downstream actions require explicit approval or logging before execution completes.
• Add offboarding steps for workloads and AI agents Treat decommissioning as an identity task, not an infrastructure cleanup step, so credentials, trust bindings, and policy grants are removed when a service or agent is retired.

Key takeaways

• KubeCon Europe 2025 reinforced that identity is no longer a supporting control in cloud-native systems, but the mechanism that governs safe execution.
• The evidence behind the shift is clear: workload identity, policy-based authorisation, and AI runtime control are converging because static secrets and hardcoded rules cannot keep pace.
• Security and platform teams should respond by inventorying non-human identities, externalising policy, and enforcing lifecycle controls for workloads and AI systems.

Key terms

• Workload Identity: A workload identity is a verifiable identity assigned to a service, job, or automated runtime so it can authenticate without relying on shared secrets. In practice, it enables traceable service-to-service access, clearer ownership, and safer revocation across cloud-native environments.
• Policy-based Authorisation: Policy-based authorisation is an access model where decisions are made by external rules rather than embedded application logic. It lets teams evaluate identity, context, and risk in a consistent way across services, clusters, and AI-driven workflows, which improves auditability and control.
• Identity Blast Radius: Identity blast radius is the amount of access, systems, or trust relationships that can be reached if one identity is over-privileged or compromised. The bigger the blast radius, the faster a local access problem can become a platform-wide security issue.
• AI Runtime Guardrails: AI runtime guardrails are controls that limit what an AI workload can access, invoke, or persist while it is running. They combine policy, telemetry, and execution constraints so the system remains governable even when the workload makes context-dependent decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Cerbos: KubeCon Europe 2025 analysis of AI, workload identity, and policy-based access control. Read the original.