Hi Larry, Thank you for reading the code and laying this out so plainly. You asked for my honest thoughts, so here they are.
You are right about the parts that do not scale, and I want to say that clearly before I push back on anything. A hand written adapter for every engine is a treadmill, keeping up with each project's API changes is real work I already feel, and when an engine ships its own MCP server my adapter for it turns into something to track and duplicate. Please note - No Apache project as of now officially released MCP server , correct me if I am wrong.so we have opportunity to fix this area but agreed if the project wants its own MCP server we should not create a blocker. On identity and high availability I am not going to reinvent what Knox already does well. Your token exchange with the actor chain, and the externalized token state, give a stronger attribution and defense story than a single forwarded credential can, because they carry the full record of who is acting for whom all the way through the call. That is exactly the direction I want my next phase to take, the 0.2 work I already have planned, building on what you have proven rather than starting from scratch. Tool and resource level authorization also fits the way the gateway already makes its decisions, so aligning it with the Knox model is a natural step rather than a rebuild, and a discovery catalog sits comfortably on top of that. Those are easy yeses. Where I see it differently is the idea that proxying MCP servers can be the whole story. I have been thinking hard about this and I do not think it can be, for a reason that is central to why the project exists. The moment the gateway only forwards calls to an opaque server, it can no longer reason about what those calls do, and most of the value I care about depends on exactly that reasoning. Deciding that a call is read only, or that a result needs redacting, or that an operation is destructive and needs approval, all need some understanding of the tool, not just its bytes. A pure proxy governs the envelope, not the action. MCP does give us a little to work with, because a tool can advertise hints about whether it is read only or destructive. But those hints come from the very server we are trying to govern, so the safe design is to treat them as claims to verify, not facts to trust. Otherwise a careless or hostile server marks a destructive tool as harmless and walks straight through. That is a governance decision a forwarding proxy cannot make on its own, and I think it is the kind of thing our layer has to own. This is not hypothetical. Tool poisoning is near the top of the OWASP MCP Top 10, and it works by hiding the payload in the tool description or schema that the model reads as trusted instructions, with rug pulls doing the same thing at runtime by mutating the tools list after the server was approved. Those live in the protocol responses, so they slip past static checks entirely, and the only thing that catches them is a layer that pins each tool and rejects it the moment its definition changes. I have been close to this problem at the library level for a while now with the MCP-Bastion packages <https://github.com/vaquarkhan/MCP-Bastion> I maintain, which do injection blocking, supply chain checksums, and redaction around a single server, and Aegis is really the governed, multi engine version of that same thinking. That background is a big part of why I am cautious about treating a plain proxy as enough. There is a second reason proxying and the identity work are really one design and not two, and you know this side far better than I do. A gateway that discovers a server and forwards a caller's token is the classic confused deputy, which is why the MCP spec forbids token passthrough, and doing it safely means re-minting identity at the boundary, which is exactly your token exchange work. So I do not see proxy first and delegated identity as separate tracks. The identity model is what makes proxying safe in the first place, which is one more reason I want to build on yours rather than alongside it. So here is where I land. Proxy first for reach, yes, and I will pull the 20 or 25 or 29 thin adapters out and lead with the proxy. But I want to keep the four deep adapters as more than a break glass fallback. They are the reference for what real governance looks like when the gateway actually understands the tool, and the proxy path should be measured against that bar rather than settling below it. I would also keep the data platform as the proving ground, not because governance is data specific, but because the hardest cases live there: destructive schema changes, bulk data leaving the building, personal data showing up in a query result. If the design holds against those, it holds anywhere. None of this is me digging in. I could be wrong about how much of that semantic depth is worth the cost, and that is genuinely where I would value your judgment most, since you have carried a security gateway through years of this. My next step, if it is useful, is to write up how the governance steps map onto the Knox provider chain and this proxy model, and put it on the dev list so we can pull it apart together. Mostly I want to thank you. This is the most useful feedback the project has had, and having someone who has actually shipped and hardened a gateway is exactly what it needs. Please keep pushing on this. I would rather be corrected now than be polite and wrong. Best regards, Viquar Khan https://www.linkedin.com/in/vaquar-khan-b695577/ On Wed, Aug 12, 2026 at 11:08 PM Chandan Singh S M <[email protected]> wrote: > Please remove me from the general email list > > On Thu, Aug 13, 2026, 07:34 larry mccay <[email protected]> wrote: > >> Hi Vaquar - >> >> I've taken a look at the repo and think you have identified an interesting >> scope for data services and MCP. >> I would like to discuss the technical direction for this work. >> >> At this point, it seems that the project is essentially creating an uber >> MCP Server that includes a separate set of tools and resources for each >> data service built directly into the project. >> There are a couple challenges with this approach: >> 1. Scaling to keep up with any and all changes made to the service APIs >> across the release trains of multiple projects. >> 2. Very real possibility of the data services creating their own MCP >> Servers that we would need to compete with or duplicate and track, etc. >> >> My recommendation is to concentrate on the pure governance and security >> aspects of using MCP Servers in an enterprise setting with things like: >> >> 1. MCP Server Proxy - discover and integrate MCP Servers via the MCP >> protocol itself as the primary target >> * configuration based integration rather than code >> 2. Break glass alternative for creating an MCP Server for services where >> one doesn't exist >> * possible "mashup" MCP Servers for interesting combinations of other >> MCP Servers >> 3. OAuth Discovery and Identity concerns for delegated agentic auth and >> proper attribution to address agentic identity challenges with MCP Servers >> 4. Agentic Authorization - providing fine grained access at the tool and >> resource level rather than the server level for federated/delegated >> identities >> 5. MCP Server Catalog for user level discovery API and UI >> >> Note that I have thought through some of the above but not all of the >> above. :) >> >> These are traditional gateway features that will remove the burden of >> having to maintain bespoke integrations with each service independently. >> They also generically add value to any MCP Server ecosystem whether in the >> data platform or any other. >> >> What are your thoughts on this take? >> >> thanks, >> >> --larry >> >> >> On Sun, Aug 9, 2026 at 10:06 AM larry mccay <[email protected]> wrote: >> >> > > And for anybody at the ASF who *has* >> > > implemented an MCP, or *intends* to implement an MCP, to at least give >> > this >> > > proposal a once-over. >> > >> > I failed to mention that I have created a couple MCPs as well as a POC >> of >> > Knox as an MCP Gateway. :) >> > >> > On Sat, Aug 8, 2026 at 10:25 PM Justin Mclean <[email protected] >> > >> > wrote: >> > >> >> Hi, >> >> , >> >> > I wanted to say a word on project governance. Specifically, how can >> we >> >> > ensure that individuals who are already PPMC members across multiple >> >> > projects don't monopolize leadership roles here? >> >> > >> >> > Are there any existing quotas, guidelines, or best practices >> regarding >> >> the >> >> > number of projects someone can be involved in as a committer or PPMC >> >> > member? >> >> >> >> I suggest you take a look at these documents on mentors: >> >> https://cwiki.apache.org/confluence/x/cQqRFw >> >> https://cwiki.apache.org/confluence/x/cwqRFw >> >> >> >> Re (P)PMC or committers, there are no real limits or advice that I’m >> >> aware of. >> >> A few reasons why: >> >> >> >> Committer and PPMC roles are not a fixed pool of seats. Adding one >> person >> >> doesn't prevent adding another. If several experienced contributors are >> >> eager to step up, the answer is to invite all of them, not to ration >> roles >> >> among them. >> >> >> >> The ASF works on merit within each project. Merit is earned per project >> >> and doesn't carry over, so someone being on five other PPMCs gives >> them no >> >> standing here beyond what they've contributed. Equally, it doesn't >> count >> >> against them. >> >> >> >> People involved in many projects are usually a benefit, not a problem. >> >> They bring experience of how other communities handle releases, votes >> and >> >> governance, which is exactly what a new project needs. >> >> >> >> If your concern behind your question is capacity: can someone spread >> >> across many projects give this one enough attention? That varies >> widely and >> >> on a case-by-case basis. >> >> >> >> Kind Regards, >> >> Justin >> >> >> >> >> >> >> >
