Zero trust without lock-in puts control and auditability first

At a glance

What this is: A KubeCon EU 2025 recap showing that European teams want self-hosted, auditable zero trust access built for privacy, sovereignty, and multicloud reality.

Why it matters: It matters because identity teams now need access controls that work across human, NHI, and emerging AI-agent use cases without forcing cloud dependency or opaque control planes.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Pomerium's KubeCon EU 2025 recap on zero trust without lock-in

Context

At KubeCon EU 2025, the core message was not about another access feature. It was about zero trust access that preserves control, auditability, and data locality for teams operating across cloud, on-prem, and airgapped environments.

That is a governance problem as much as an architecture problem. When access policy, protocol support, and observability need to span human users, non-human identities, and emerging AI-driven tooling, the control plane itself becomes part of the trust boundary.

The article also points to a practical shift: teams want systems they can run themselves, inspect directly, and adapt to local regulatory constraints rather than consuming a managed service by default.

Key questions

Q: How should teams govern zero trust access in self-hosted environments?

A: Teams should define the control plane as part of the trust boundary, then verify where policy decisions, logs, and metadata live. Self-hosted zero trust only helps if auditability, data locality, and recovery remain intact when the vendor cloud is absent. The key is operational control, not just deployment style.

Q: Why do non-HTTP protocols complicate zero trust architecture?

A: Because zero trust often starts with web applications and then leaves administrative and operational channels outside policy enforcement. SSH, UDP, DNS, and similar protocols can become exception paths that bypass identity-aware controls. If those paths are not included, the organisation has partial zero trust, not comprehensive zero trust.

Q: When should organisations prioritize self-hosted access control over managed access services?

A: They should prioritise self-hosted control when auditability, data locality, resilience, or regulatory sovereignty are non-negotiable. That is common in banking, healthcare, critical infrastructure, and any environment that must keep operating under restricted connectivity or strict jurisdictional constraints.

Q: How do AI agents change the zero trust access model?

A: AI agents increase the number of runtime decisions that must be governed, because access is no longer only about a user session. The programme has to decide what the agent can reach, under what context, and whether those decisions are traceable enough for audit and containment.

Technical breakdown

Self-hosted zero trust and the trust boundary

Self-hosted zero trust changes where trust is anchored. Instead of pushing identity decisions into a vendor-managed control plane, organisations keep policy enforcement, logging, and routing inside their own infrastructure. That matters for auditability, data residency, and regulated environments where the network path and the decision path must both be visible. In practice, this architecture is closer to an identity-aware policy layer than a simple proxy, because it has to combine user context, workload context, and route-level controls without losing traceability.

Practical implication: treat the access control plane as a regulated system and verify where policy decisions, logs, and metadata are stored.

Why protocol breadth matters for identity-aware access

Zero trust becomes brittle when it only covers HTTP. Real environments still rely on SSH, UDP-based services, DNS, syslog, and other non-web protocols that carry operational traffic and administrative access. If those protocols sit outside the policy layer, teams create exception paths that undermine least privilege and continuous verification. The architectural challenge is to extend identity-based policy to all meaningful transport paths, not just the easiest ones to instrument.

Practical implication: inventory non-HTTP access paths first, then decide which of them must be brought under identity-aware enforcement.

Context-aware access for multicloud and AI agent workflows

Multicloud and AI-mediated access increase the number of decisions that must be made at runtime. A policy layer has to account for identity, device posture, environment, and task scope while still operating consistently across VMs, containers, bare metal, and remote sites. For AI agents, the issue is not only tool access but whether the access model can support dynamic, context-based decisions without creating opaque delegation chains. That is where zero trust moves from a perimeter concept to a runtime governance model.

Practical implication: define which runtime signals must be evaluated before access is granted to users, workloads, and AI-driven tools.

NHI Mgmt Group analysis

Self-hosted access control has become a governance requirement, not a deployment preference. European teams are not simply expressing a taste for on-premises software. They are signalling that auditability, data locality, and operational control now shape whether an access platform is acceptable in regulated environments. The implication is that identity programmes increasingly have to justify the control plane itself, not just the policy inside it.

Zero trust without protocol coverage creates an incomplete identity boundary. If SSH, UDP, DNS, and other non-HTTP paths sit outside policy enforcement, the programme still contains blind spots that attackers and operators can exploit. That is not a feature gap, it is a boundary failure. Practitioners should read this as a reminder that control coverage must match the full protocol mix, not the easiest subset.

Runtime access for AI-driven systems needs the same scrutiny as human and workload access. The article’s reference to AI agents matters because it points to a coming expansion of the identity surface, not a separate problem domain. Once task execution becomes dynamic, the governance question shifts from who logged in to what was allowed to act, where, and under what contextual constraints. Practitioners should prepare to apply the same access logic across all actor types.

Portable zero trust is becoming part of resilience planning. Teams running banking, healthcare, critical infrastructure, or airgapped systems cannot rely on a cloud-dependent access model and still claim operational sovereignty. That makes portability, inspectability, and local control central design criteria for modern IAM and NHI programmes. The practical conclusion is that architecture choices now have compliance and continuity consequences, not just usability trade-offs.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why zero trust programmes fail when non-human access remains opaque.
• That same visibility gap is why practitioners should also review the Ultimate Guide to NHIs , Standards for control mapping and governance alignment.

What this signals

Portable zero trust is becoming a baseline requirement for regulated identity programmes. As access control extends beyond the browser and into SSH, UDP, and machine workflows, teams need architectures that survive constrained networks and local compliance demands. The next planning question is not whether zero trust exists, but whether it still functions when cloud dependency is removed.

The practical signal for IAM and NHI teams is that observability, policy locality, and protocol coverage now belong in the same architectural conversation. A system that cannot prove who accessed what, from where, and under which context will struggle in regulated environments, even if it markets itself as zero trust.

Identity-aware access is expanding into AI-mediated execution. Once agents begin selecting tools dynamically, the governance model must cover runtime context rather than fixed session assumptions. That means programme owners should begin testing access policy against emerging agentic workflows before those workflows become production dependencies.

For practitioners

• Map every access path outside HTTP Inventory SSH, DNS, syslog, UDP, and any other non-web protocol that bypasses your current policy layer. Prioritise the paths that carry administrative or machine-to-machine access, then decide whether they require the same identity checks as web traffic.
• Separate policy enforcement from vendor dependency Document where access decisions are made, where logs are retained, and which controls fail if the control plane becomes unavailable. For regulated or sovereignty-sensitive environments, require a deployment model that keeps policy and evidence within your own operational boundary.
• Extend zero trust to workload and AI-driven access Treat AI agents and workloads as distinct actor types that still need contextual policy evaluation. Define which signals must be present before runtime access is granted, and do not allow dynamic tool use to sit outside the governance model.
• Test portability under constrained environments Validate whether the access architecture still works in airgapped, offline, or constrained network conditions. If it cannot operate without cloud reachability, it is not yet a complete option for high-assurance environments.

Key takeaways

• Zero trust is shifting from a product label to a governance requirement centred on control, observability, and data locality.
• Incomplete protocol coverage undermines identity-aware access because exception paths recreate the very trust gaps zero trust is meant to remove.
• IAM teams should test whether their architecture still works when cloud dependency disappears and when AI-driven access enters the path.

Key terms

• Self-hosted zero trust: An access architecture where policy enforcement, telemetry, and governance run inside the organisation's own infrastructure rather than a vendor-managed service. It matters because trust, auditability, and data locality stay under direct operational control, which is often required in regulated or sovereign environments.
• Protocol coverage: The extent to which identity-aware access controls apply across all relevant network protocols, not only web traffic. In practice, weak protocol coverage creates exception paths for SSH, UDP, DNS, and similar channels, which can undermine least privilege and continuous verification.
• Context-aware access: A policy model that evaluates identity, device, location, environment, and task context before granting access. For modern identity programmes, it is the difference between static permissioning and runtime governance that can adapt to changing operational conditions and actor types.

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.

This post draws on content published by Pomerium: Zero Trust Without Lock-In: What We Heard at KubeCon EU 2025. Read the original.