Hi Vaquar, Thanks for hanging in there. I see Larry feels good moving forward and Greg suggested copying your proposal into the wiki for review and comment.
PJ, I get your hesitation about single committer projects but in my experience one motivated committer aided by AI tooling can get a lot done. If a small community develops it's low risk to try something out. I'm happy to move this proposal to the wiki and do a review against other solutions out there. Nice work, thanks for your contributions already! Best Andrew On 2026/08/27 19:49:00 vaquar khan wrote: > Hi everyone, > > Just checking in on this thread to see where we stand. I want to make sure > I am not holding anything up. > Greg and Larry, is there anything pending from my side that you need me to > tackle? Just let me know what the next steps are or if you just need me to > sit tight for now. > > Thanks, > Viquar Khan > > On Mon, Aug 17, 2026 at 11:37 AM vaquar khan <[email protected]> wrote: > > > 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 > >>> > >> >> > >>> > >> >> > >>> > >> >> > >>> > >> > >>> > > > >>> > > >>> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
