Replies: 3 comments 1 reply
-
|
I've listed some ideas that EG can do recently. @zhao-kun @xxx7xxxx @suchen-sci |
Beta Was this translation helpful? Give feedback.
-
Sailing to V3: AI Agent Native API GatewayI was thinking of opening an issue until I found this discussion. This is my thought right now. I'd like to do the radical evolution. BackgroundThis is an early and still-raw idea for what Easegress V3 could become. Instead of thinking about an API Gateway only as a proxy or traffic management layer, what if we rethink it as an AI Agent Native API Gateway? Not just “an API gateway with some AI features”, but a gateway designed from the beginning for:
This is not a finalized roadmap proposal. It is an open idea, and I’d love to hear whether the community finds it interesting. The Core ThoughtA future V3 could explore a much more ambitious direction:
In other words, V3 would not just be a gateway that forwards requests. It could become a gateway that people and agents can actively work with. V3 Should Be a Real User of ItselfOne important idea is that Easegress V3 should not only proxy traffic, but also act like a real user of the gateway itself. That could mean users can:
This would make Easegress V3 more than an API Gateway. It could become a gateway-native environment to:
Large models are especially useful here because they are good at generating mock clients, mock servers, API definitions, test cases, failure cases, and even illegal traffic patterns. A Possible First Step:
|
Beta Was this translation helpful? Give feedback.
-
|
We should migrate this discussion to an issue. I completely agree with your perspective. Especially in scenarios like configuration, testing, and verification, using EG can be quite cumbersome. For an AI-native API Gateway, I think it could support natural language–driven deployment and configuration, AI + rule-based security guarantees, traffic-aware auto scaling and failover, as well as AI-powered anomaly detection and alerting. In addition, as a gateway, I believe EG still needs to do a solid job on the cloud-native side—for example, deeper and more seamless integration with Kubernetes. As for whether to rewrite it in Rust, I think it’s worth discussing. The current architecture is already quite mature, and rewriting existing functionality in Rust may not bring significant benefits. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with your opinions. I want to write the new |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Roadmap
This document summarizes the most promising strategic initiatives for Easegress in the AI agent ecosystem.
Priority Summary
1. AI Access Gateway
Priority:
P0Background
Many enterprises do not want employees to use model vendors directly with unmanaged seats, unmanaged API keys, or isolated team-level billing. Instead, they want a central gateway where users authenticate with enterprise identity, request access to approved models, and run all model traffic through one governed path.
Easegress already has a strong starting point here through its existing AI Gateway work, including provider integration, semantic cache, and observability. This makes AI access governance the shortest path from current Easegress capabilities to a differentiated enterprise offering.
Why It Matters
An AI Access Gateway gives the enterprise one place to enforce:
This is also where pooled enterprise access becomes practical. Instead of distributing vendor credentials broadly, the company can expose governed access with clear limits and traceability.
What Easegress Can Build
What Easegress Needs To Develop
ModelCatalogCRD and controller for providers, models, quotas, and tenant-scoped defaults.AIGatewayController, instead of request-count-only governance.AIGatewayController, that evaluates identity, cost, latency, and provider health.AIGatewayProxy, or a new fallback filter, for multi-provider failover behavior.Reference Docs
2. MCP Gateway
Priority:
P0Background
Model Context Protocol (MCP) is quickly becoming the standard way for agents to use tools over a common interface. The protocol surface is maturing around transport, authorization, and server discovery. That solves interoperability, but it does not solve enterprise governance.
What enterprises still need is a secure gateway between agents and MCP servers:
This is where Easegress can add clear value.
Why It Matters
Tool calls are where many of the highest-risk actions happen:
An MCP Gateway lets Easegress sit at the control point for that activity. It can standardize auth, enforce policy, apply rate limits, redact outputs, and provide a consistent audit trail across internal and external tools.
Among all agent-adjacent opportunities, this is likely the most attractive near-term opening because the protocol is gaining adoption while the governance layer is still immature.
What Easegress Can Build
What Easegress Needs To Develop
MCPServerandMCPToolPolicyCRDs with a controller for approved server and tool metadata.Reference Docs
3. Kubernetes-Native Agent Policy Control Plane
Priority:
P0Background
Enterprise agent systems are increasingly deployed on Kubernetes:
If Easegress wants to become the governance layer for agent systems, it cannot treat Kubernetes as a packaging detail. Policy, status, tenancy, and lifecycle must be Kubernetes-native.
This means the product direction should not stop at "runs on Kubernetes." It should define native resources and operational workflows for agent governance in Kubernetes environments.
Why It Matters
Kubernetes-native control is important for several reasons:
Without this, Easegress risks looking like an external gateway that happens to support K8s, rather than a true cloud-native policy layer for agent workloads.
What Easegress Can Build
What Easegress Needs To Develop
ModelAccessPolicy,ToolAccessPolicy,SandboxEgressPolicy, andAgentTrustPolicy.Reference Docs
4. Identity-Aware Audit and Short-Lived Credentials
Priority:
P0Background
Many companies currently solve AI access with a shared provider key behind a gateway. This helps centralize spend, but by itself it does not solve enterprise accountability. If every request looks the same downstream, the organization loses the ability to prove:
That is the gap between central access and governed access.
Why It Matters
Identity-aware audit is the core of enterprise trust in agent systems. It is what allows security, compliance, and platform teams to answer:
Short-lived credentials are equally important. They reduce blast radius and make it possible to bind access to:
Without this capability, Easegress may still proxy traffic, but it will not solve the real governance problem.
What Easegress Can Build
What Easegress Needs To Develop
Reference Docs
5. Sandbox Egress Gateway for Job Centers and Remote Execution
Priority:
P1Background
A growing enterprise pattern is to let users submit tasks to a centralized job center, which then launches a remote sandbox to execute the task. This pattern is attractive because it centralizes compute, cost, and compliance. It also changes the risk model.
Once the sandbox is running, the critical question becomes:
What is this sandbox allowed to reach?
At that point, risk is no longer limited to model access. It includes outbound access to:
Why It Matters
Sandbox egress is where many of the hardest production controls are needed:
This is a particularly strong fit for Easegress because the problem is fundamentally about policy-controlled traffic rather than task scheduling.
Easegress does not need to become the job center. It needs to become the trusted egress and governance layer around the job center.
What Easegress Can Build
What Easegress Needs To Develop
SandboxIdentityorSandboxEgressPolicyCRD and controller that the gateway can trust for workload attestation.Reference Docs
6. Gateway API Completion for Agent Platforms
Priority:
P1Background
Gateway API is the standard Kubernetes direction for gateway and traffic policy. Easegress already supports part of this area, but current support is still centered around HTTP and HTTPS listeners.
For broader cloud-native relevance, especially in enterprise agent environments, Easegress should continue expanding its Gateway API coverage and policy attachment model.
This matters not only for public ingress. Gateway API can also become the standard surface for policy, routing, and resource ownership across agent-related traffic.
Why It Matters
Completing more of the Gateway API surface helps Easegress in several ways:
The most relevant areas are:
GRPCRoute,TLSRoute,TCPRoute,UDPRoute,ReferenceGrant,BackendTLSPolicy.Not every one of these needs to ship first, but the direction should be explicit.
What Easegress Can Build
GRPCRoute,TLSRoute,TCPRoute, andUDPRoutewhere they are relevant to agent traffic.ReferenceGrantandBackendTLSPolicyto enable secure multi-namespace deployments.What Easegress Needs To Develop
GRPCRoute,TLSRoute,TCPRoute, andUDPRoute.ReferenceGrantandBackendTLSPolicy.Reference Docs
7. A2A Gateway
Priority:
P2Background
Agent-to-Agent (A2A) protocols aim to standardize how agents discover each other, exchange tasks, stream results, and handle callbacks or delegated work. This is strategically relevant because enterprise agent systems will eventually need secure interoperability between different agents and vendors.
However, compared with model access and MCP tool access, this area is earlier in its operational maturity for most enterprises.
Why It Matters
Over time, A2A can become another major governance surface:
Easegress can eventually become the policy and traffic layer for this interaction as well. But this should likely follow, not precede, the work on AI access, MCP, identity, and sandbox egress.
What Easegress Can Build
What Easegress Needs To Develop
AgentPeerorAgentTrustPolicyCRDs and controllers for agent identity, domain boundaries, and delegated capabilities.Reference Docs
Beta Was this translation helpful? Give feedback.
All reactions