|
| 1 | +# Introduction |
| 2 | + |
| 3 | +The continuous evolution of the AI ecosystem has led to the emergence of agent-based development, a paradigm in which autonomous AI agents execute intricate tasks. This transformation is fostering the development of "AI-first" protocols, such as the Model Context Protocol (MCP) and A2A, which diverge significantly from conventional protocols. |
| 4 | + |
| 5 | +Agents in a sense are microservices for AI. They are self-contained, autonomous units of work that can be composed to build complex applications. These agents, and the tools they use to perform their functions, are becoming ubiquitous. They can run anywhere: on-premises, in traditional hyperscaler cloud environments (like Kubernetes or serverless functions), on new cloud platforms (neoclouds), or across the public internet. |
| 6 | + |
| 7 | +This distributed nature, combined with the new communication patterns of "AI-first" protocols, introduces novel security and governance challenges. Unlike traditional REST APIs, these protocols require integration with AI safety and security models in addition to conventional security measures. This is because agents can act autonomously, potentially with significant impact. It is therefore essential for Kubernetes to provide a consistent API for a well-governed, secure, and auditable flow of communication: |
| 8 | + |
| 9 | +- From agents in Kubernetes to agents in the cluster and remote agents anywhere. |
| 10 | + |
| 11 | +- From agents running anywhere to agents in Kubernetes. |
| 12 | + |
| 13 | +- For agents in Kubernetes to access tools anywhere. |
| 14 | + |
| 15 | +## Goals |
| 16 | + |
| 17 | +This subproject aims to deliver the following: |
| 18 | + |
| 19 | +**Core Capabilities** |
| 20 | + |
| 21 | +- Provide standardized APIs for secure, governed communication between agents, tools, and potentially LLMs across Kubernetes cluster boundaries (ingress, egress, and east-west traffic) |
| 22 | + |
| 23 | +- Attempt to design APIs around user-facing goals (e.g., "Agent A can communicate with Tool B") rather than protocol-specific constructs, ensuring adaptability as new AI-first protocols emerge alongside MCP and A2A |
| 24 | + |
| 25 | +- Enable protocol-aware networking capabilities where necessary (e.g., MCP tool-level authorization) while keeping core APIs protocol-agnostic and future-proof |
| 26 | + |
| 27 | +- Establish agent identity and authentication mechanisms that allow agents to be uniquely identified and verified across network boundaries |
| 28 | + |
| 29 | + |
| 30 | +**Security & Governance** |
| 31 | + |
| 32 | +- Define authorization policies that control which agents can communicate with other agents, tools, and LLMs at a granular level (e.g., specific MCP tool functions) |
| 33 | + |
| 34 | +- Integrate AI safety and security extension points to support external authentication, authorization, and policy enforcement decisions |
| 35 | + |
| 36 | +- Provide auditable traffic management capabilities (rate limiting, access controls) suitable for autonomous agent workloads |
| 37 | + |
| 38 | + |
| 39 | +**Ecosystem Integration** |
| 40 | + |
| 41 | +- Maintain alignment and collaboration with Gateway API, Gateway Inference Extension, WG AI Gateway, and WG AI Integration |
| 42 | + |
| 43 | +- Design APIs extensible enough for diverse implementations (service meshes, gateways, future architectures) |
| 44 | + |
| 45 | +## API Resources |
| 46 | + |
| 47 | +Check back soon for the initial API proposal! |
| 48 | + |
| 49 | +## Who is working on this project? |
| 50 | + |
| 51 | +TODO |
0 commit comments