Hi everyone, I want to thank you all again for the invaluable feedback and guidance over the past couple of weeks. It sounds like we have a solid consensus on the technical direction ,specifically the shift towards a declarative server definition model for governance context, as Larry suggested( Mentor) . I've also taken note of the feedback regarding growing the committer base, which remains an active priority.
With Greg kindly offering to Champion the effort and the design path looking much clearer, I wanted to check in with the wider group. Is there anything else anyone would like to discuss, review, or clarify before we officially move to the next stage. Thanks again for all the support and insight. Best regards, Viquar Khan On Thu, Aug 13, 2026 at 3:19 PM vaquar khan <[email protected]> wrote: > Hi Larry, > That works for me, and it is the cleaner idea. A declarative server > definition that carries the governance context, following the Knox path > from code to declarative, is exactly the shape I want, and I will write it > up that way for the dev list so we can refine it together in the project. > On next steps, I would value your read on timing. The project is no longer > a single author. A few people have merged code, and there is steady > activity, and I will keep growing that. Do you think we are at a reasonable > point to move toward a vote or would you rather we wait a little. > My honest lean is to start sooner rather than later. Right now, MCP > governance is still greenfield, so we have a rare chance to design the > protocol usage and the governance together from the start. If we come late, > end-to-end governance stops being a design choice and turns into a large > alignment problem across many servers and teams that have already shipped, > which is far harder to land. > I completely defer to you and Greg on when and how to bring this forward. > My only ask is that we keep an eye on the window together, so the project > stays ahead of the curve rather than chasing it. > > Thank you, > Viquar Khan > > On Thu, Aug 13, 2026, 12:40 PM larry mccay <[email protected]> wrote: > >> Thank you for the detailed response. >> >> I'm thinking that the governance context could be captured in more of a >> declarative mcp server definition rather than requiring bespoke code for >> each one. >> This makes for a very flexible and more easily maintainable >> implementation. >> Knox went through a similar migration from requiring code to add a new >> service to dispatch to - to a declarative service definition model. >> >> At any rate, I think that we can move forward based on your response and >> your willingness to revisit some of that. >> >> Thanks again, >> >> --larry >> >> On Thu, Aug 13, 2026 at 12:38 PM vaquar khan <[email protected]> >> wrote: >> >> > 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 >> > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> > >> >
