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 > >> >> > >> >> > >> >> > >> > > >
