Eighty feet below Liberty Street, the Federal Reserve Bank of New York holds one of the largest gold vaults in the world. It is the place where central banks, governments, and official organizations place their trust. For the people charged with safekeeping that trust, access routes, authentication, and authorization are very top of mind. It is a fitting neighbor for Kubernetes Community Days New York 2026. A few blocks away from that underground store of value, several hundred cloud-native practitioners gathered to talk about who holds the trust for our critical systems. Who verifies it, and who is accountable when software starts acting on our behalf?

This marked the third edition of the event organized by the local members of the Cloud Native Computing Foundation (CNCF) ecosystem. More than 40 speakers from all over the world came together to give 30+ talks and run 9 roundtable discussions. While Kubernetes was certainly the central technology anchoring all the talks, the sessions addressed a wide variety of topics, from AI to security, scalability to telemetry, and more.

Here are just a few highlights from this year's KCD New York. 

From Perimeter Trust to Service Trust

In “Zero Trust for APIs: From Edge to Mesh with Istio,” Mofesola Babalola, Staff Site Reliability Engineer at Tempo, and Hannah Olukoye, Engineering Manager at DKB Code Factory, used the classic castle-and-moat model to frame a familiar cloud-native problem. Organizations, traditionally, build strong perimeters with firewalls, virtual private networks, and load balancers. These are all still important, but thinking of trust boundaries in terms of "castle walls" leaves a softer center behind them. Once an attacker gains a foothold inside the cluster, even through a non-critical service, trusted east-west traffic can open a path for lateral movement.

Mofesola and Hannah positioned Istio Ambient Mesh as a way to bring zero trust deeper into the service layer without forcing every application team to carry the full burden in code. Instead of attaching an Envoy sidecar to every pod, Ambient uses a shared ztunnel for Layer 4 traffic and Waypoint proxies for Layer 7 controls where they are needed. That enables mTLS, workload identity through SPIFFE, JSON Web Token validation, and policy enforcement to move into the mesh rather than being repeated across application codebases.

The duo emphasized that zero trust depends on verifiable context. A service should be able to prove who it is. A user request should be authenticated. An authorization policy should decide what that identity can do. Istio does not remove the complexity of distributed systems, but it gives teams a clearer place to enforce those questions consistently across service-to-service communication. The payoff is better security, reliability, observability, and velocity, but only if teams are honest about complexity. Perfectly secure systems are easy to imagine. Useful secure systems take iteration.

The Issues With AI And No Single Source of Truth

In the session from Pushkar Joglekar, Principal Security Engineer at Broadcom, called "Who Does AI Trust for K8s CVEs: Maintainers or MITRE?," he used a simple physical-world example to frame a much harder digital-world problem. When returning a rental car, do you trust the overhead airport signs or Google Maps? In his case, the signs were right while the app was wrong. That same tension shows up in vulnerability management: different sources can describe the same Kubernetes Common Vulnerabilities and Exposures (CVEs) in different ways.

For Kubernetes CVEs, the question is not just whether a vulnerability exists. It is whether it affects your version, whether it is fixed, whether it was only mitigated, and who gets to say so. The official CVE records maintained by MITRE, GitHub issues, maintainer comments, and security response discussions can all hold versions of the "truth." Pushkar showed how those, and other records, can diverge, including cases where a CVE appeared fixed in one place while the maintainer's context told a more complicated story. Scanners, dashboards, and increasingly AI systems depend on those records to decide what needs attention.

The bigger concern was not that AI gets things wrong. Humans get things wrong as well, and miscommunications often happen. But Pushkar said that what is different here is that AI often sounds certain while flattening disagreement between sources. When one record says “fixed,” another says “mitigated,” and a maintainer thread adds version-specific context, there may not be one clean answer for the model to retrieve. The work, then, is improving the sources themselves.

We must work towards better CVE feeds, clearer Vulnerability Exploitability eXchange (VEX) data, and cleaner Kubernetes Enhancement Proposals through the Security Special Interest Group (SIG). AI can help reason about vulnerability data, but only if the underlying trust chain is visible, up to date, and maintained.

Remediation Needs a Trust Ladder

In the session by Bruno Chauvet, Head of Compute Platform at ROKT, "No More War Rooms: Kubernetes MCP Servers + Agentic AI for Autonomous Multi-Cluster Remediation," he framed the problem through the lens of a familiar 3 a.m. incident. What do you do when p99 latency spikes, a P1 gets declared, and no one has a complete answer because the data is scattered across tools? Hopefully, not panic. 

Observability, deployment, and infrastructure data do exist, but they rarely share one unified reasoning layer. Bruno proposed a path using Kubernetes Model Context Protocol (MCP) servers in a hub-and-spoke model that provides agents with a single, controlled entry point for actions such as scaling workloads, port forwarding, and Helm operations across complex multi-cluster environments.

Part of this plan was a trust model around the agents, which Bruno described as an agent loop of observe, reason, act, verify, and output. Autonomy is not enough on its own, though. Any system needs a cast of specialized agents, strict permissions, auditable token budgets, and guardrails from day one. Read-only access comes first. Remediation should be opt-in, reversible, and limited to high-confidence cases such as rollback, patch, or scale actions. 

The trust ladder matters: start with recommendations, then move carefully toward dedicated auto-remediation. For agentic operations, identity and role-based access control are not cleanup tasks. They are the foundation.

Community Is the Load-Bearing Layer

In the keynote from Chad M. Crowell, CNCF Ambassador and Principal SRE at Akamai, "Open Source Didn't Build Itself: Community Is the Real Infrastructure," he put numbers behind a truth the cloud-native world often feels but does not always say plainly. Kubernetes and all CNCF projects have over 9000 contributors and over 98,000 total contributions. But it also has a steep dropout rate for contributors; around 83%. Open source may be free to use, but it is not free to sustain. Too often, the system keeps working because enough people keep choosing to give their time, attention, and care.

Chad emphasized that community is not a soft layer around technology, but in fact it is the infrastructure that makes the technology possible. He pointed to work like Kaslin Fields’ New Contributor Orientation program as a practical example. This program guides new contributors to figure out how to belong, never leaving them to fend for themselves. The idea is that the difference between a contributor who stays and one who disappears may be whether someone noticed they arrived, helped them understand the culture, and gave them a reason to come back.

Chad gave us some practical advice if anyone in the audience was thinking about jumping in to contribute: Begin small. Understand the culture. Invest in relationships. Leave things better. Do it consistently. A typo fix, a documentation improvement, a SIG meeting, or one steady pull request a month can matter more than a burst of heroic effort that vanishes. Open source did not build itself. It runs on people, and people stay when the community gives them something sturdier than a backlog.

Trust Is An Execution Problem

Across KCD New York, there was a common thread of trust under execution. Agents are no longer sitting politely beside the workflow, waiting to summarize a log or draft a pull request. They are being pointed at clusters, tools, tickets, policies, and pipelines. That changes the question from “Can this system give a useful answer?” to “What can this system do, who allowed it, and how do we prove it afterward?” 

The talks on agentic engineering, MCP gateways, Claude Code on Kubernetes, and autonomous remediation all circled the same issues. Autonomy is useful only when identity, permissions, auditability, and rollback are built in from the start. Agent Gateway’s focus on securing and governing service, LLM, MCP, and agent-to-agent traffic fits that shift.

The Platform Is the Policy Surface

Kubernetes keeps absorbing more and more responsibility from the application. It is not just running applications anymore; it's becoming the control surface for AI agents, inference workloads, security policy, observability, multi-architecture compute, and even human workflows. That makes platform engineering less about providing clusters and more about encoding judgment into paved roads. 

A good example is how Istio Ambient Mesh was a good example: it separates core Layer 4 security through ztunnel from optional Layer 7 policy through Waypoint proxies, giving teams a way to move trust decisions into the infrastructure without rewriting every service. The same theme showed up in llm-d, which treats distributed large language model inference as a Kubernetes-native scheduling, routing, and cache-management problem rather than a simple HTTP serving problem.

Source of Truth Is Now a Supply Chain Question

The event also kept coming back to evidence. Not dashboards or vibes alone. CVE records, maintainer comments, GitHub issues, software bills of materials, signed artifacts, telemetry pipelines, and evaluation results all became part of the same conversation. But these sources do not always agree. 

That makes source-of-truth work a supply chain problem. The artifact, the record, the evaluation, and the human context all need to travel together. Our success with AI depends on it.

The Real Infrastructure Is Still The Humans

For all the talk about agents, gateways, meshes, and model serving, the people emerged as the most important element in making our Kuberneted projects successful. Open-source communities, security response teams, platform groups, and maintainers are the ones who decide what the system means when the records conflict or the automation gets stuck. Open source runs on people who keep showing up, often without being asked, and the unglamorous work is usually the load-bearing work. 

The future of cloud native is more automated, but not less human. The hard part is building systems where machines can act faster without making it harder for people to understand, govern, and repair what they do.

Trust Has to Survive Contact With Production

KCD New York 2026 made it clear that trust is no longer a static design principle. It is, instead, something teams have to build, test, observe, and repair while systems are running. The work cannot stop at stronger authentication, cleaner policies, or better dashboards. Those all matter. But the deeper challenge is connecting identity, evidence, permissions, and human judgment into systems that can withstand real pressure.

Your author shared that none of our plans matter if attackers can exploit our supply chain and standing privileges. Building on the work of GitGuardian security researchers, many lessons from the Shai Halud and TeamPCP campaigns were shared with the Kubernetes community. Ideally, upstream providers will continue to shift the security burden away from consumers, but until then, we will continue to outline best practices for staying safe.

The future will bring more agents, more abstraction, and more automation. Humans are not just in the loop; they are the reason the loop exists and need to drive it. The teams that succeed will be the ones that know where trust begins, where it breaks, and who is responsible for putting it back together.