A special interest group for the AI stack
On July 23, 2026, the CNCF announced an AI Infra SIG under its Japan chapter, and the roster tells you the effort is serious. The organizers come from CyberAgent, IBM Research Tokyo, Preferred Networks, LY Corporation, Fsas Technologies, and the CNCF End User TAB and eBPF Foundation. The stated mission is to share optimization and operational practices for AI infrastructure and to strengthen upstream contributions to AI-related projects across CNCF and the Linux Foundation. The first meetup lands October 1 in Tokyo at Garden Terrace Kioicho, free and live-streamed, with a speaker deadline of August 28.
The more useful artifact is the scope the SIG published, because it doubles as a map of the AI stack on Kubernetes. Scheduling covers Dynamic Resource Allocation, Kueue, and workload-aware scheduling. Orchestration names JobSet, LeaderWorkerSet, and KubeRay. Deployment lists KServe, llm-d, and AIBrix. Networking includes the Gateway API Inference Extension, kgateway, and the Envoy AI Gateway. A fifth category, agent infrastructure and standardization, names agentgateway, Agent Sandbox, and AI Conformance. That last group is the newest, and it marks the moment the community started treating autonomous agents as a first-class infrastructure concern rather than an application detail.
Why agent identity breaks the old model
The framing that dominated KeycloakCon Japan on July 28 was blunt. When an AI agent acts on behalf of a human user, calls downstream APIs, and crosses trust boundaries, traditional authorization boundaries collapse. A service account with broad scope was tolerable when a human clicked the button. An autonomous agent that chains dozens of API calls on its own turns that same account into a standing risk, because the agent can be steered by prompt content into using permissions it was never meant to exercise. The Model Context Protocol made this concrete by giving agents a standard way to reach tools and servers, which is exactly where the authorization question becomes urgent.
The community's answer is to make identity flow with the request rather than sit statically on a token. Keycloak is being positioned as the authorization server for MCP, handling delegation so an agent carries a verifiable claim about the user it represents and the scope it may use. This is the same discipline that OAuth brought to third-party apps, applied to non-human callers that act faster and more opaquely than any human integration. For platform teams, the takeaway is that agent authorization belongs in the identity provider you already run, not in bespoke logic scattered across each MCP server.
Concrete patterns, not slideware
Two sessions moved past principle into mechanism. Yutaka Obuchi of Hitachi and Tatsuya Yano of LY Corporation demonstrated extending Keycloak's Token Exchange Provider to externalize authorization across MCP servers, using Identity Assertion JWT Authorization Grants, known as ID-JAG, to prevent the confused-deputy vulnerability. That attack, where a privileged intermediary is tricked into misusing its authority, is precisely the failure an agent chaining calls can trigger. Encoding the original user's assertion into the grant keeps the downstream server from acting on ambient trust.
Mustafa Dayioglu of TUBITAK showed a keyless MCP workload identity pattern on Kubernetes, using SPIRE to issue runtime identity and DPoP to bind tokens against replay. Keyless matters because long-lived secrets are the thing that leaks, and SPIFFE-style workload identity replaces them with short-lived, attested credentials tied to the pod. Yuxiang Lin of Midships Global argued that purpose-built AI identity vendors are an unnecessary dependency, pointing to Keycloak's production-ready primitives: OAuth 2.0 token delegation, token exchange, and fine-grained scope enforcement. For buyers weighing a new category of agent-identity startups, that is a pointed build-on-what-you-have argument.
Three milestones converge on production AI
KubeCon and CloudNativeCon Japan 2026 ran July 29 to 30 at PACIFICO Yokohama across six tracks including AI, observability, and platform engineering. Organizers framed the event around three milestones landing at once: Dynamic Resource Allocation reaching general availability in Kubernetes 1.34, OpenTelemetry achieving CNCF graduation, and Keycloak-MCP authorization for AI agents. Read together, they close the last major gaps for running agents on Kubernetes. DRA handles how accelerators get scheduled, OpenTelemetry standardizes how the system is observed, and the identity work handles who is allowed to do what.
The convergence narrative is more than conference theater. Each piece was a known weakness a year ago. GPU scheduling relied on integer counting through the old device-plugin model, observability was fragmented across vendor agents, and agent authorization did not exist as a pattern. Having all three reach maturity in the same window is what lets a platform team say yes to a production agent workload without hand-waving the operational questions. It also explains the timing of the AI Infra SIG, which exists to keep these threads coordinated as they evolve across the next several Kubernetes releases.
Japan as a proving ground
The regional detail is worth noting. On July 28 the CNCF and SlashData reported that Japan is home to roughly 950,000 cloud-native developers as of the first quarter of 2026, a base large enough to sustain its own SIG and its own KeycloakCon. Grounding the AI Infra SIG in the Japan chapter puts a concentration of end users and vendors close to the upstream work, and the organizer list, weighted toward operators like CyberAgent, LY Corporation, and Preferred Networks, reflects that. These are companies running real inference and training at scale, not laboratories.
For a CTO outside Japan, the relevance is that the patterns being hardened here will surface upstream in the projects you already consume. agentgateway, Agent Sandbox, and the AI Conformance effort are being shaped by the same maintainers who steer Kubernetes and Envoy, so the choices made in these meetups become the defaults in your cluster later. Tracking a regional SIG feels remote until you realize its output arrives in your next platform upgrade. The practical move is to watch the standardization category, since conformance definitions tend to dictate what portable actually means.
What to do with this now
The signal for engineering leaders is that agent governance on Kubernetes has moved from open question to emerging standard, and the standard leans on identity infrastructure you can already run. If you are piloting MCP-based agents, the responsible next step is to route their authorization through your existing identity provider using token exchange and delegation, rather than granting broad service accounts and hoping prompts stay benign. The confused-deputy and token-replay problems are known, and the mitigations, ID-JAG and DPoP with SPIFFE-style workload identity, are demonstrated rather than theoretical.
The build-versus-buy read is that the agent-identity control plane is consolidating around open primitives, which should make you cautious about locking into a proprietary AI-identity product before the conformance work settles. On the compute side, treat DRA as the supported path for accelerator scheduling and standardize telemetry on OpenTelemetry so your observability survives a vendor change. None of this requires waiting for a new platform. It requires applying disciplines the cloud-native community just certified as production-ready, and doing it before your agents are handling anything that matters.
