You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by vaquar khan <va...@gmail.com> on 2026/08/04 05:18:26 UTC
[DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Hello everyone,
I would like to propose a project called Aegis MCP Governance Gateway for
the Apache Incubator, and start a discussion. It is a working reference
implementation, and I am bringing it here mainly because it needs a
community rather than a single author, which I state plainly in the
proposal.
*In short: *when an AI agent needs to operate data systems like Flink,
Kafka, Spark, or Iceberg, it usually drives each engine control plane
directly or connects to a pile of separate MCP servers, each with its own
security posture, no shared audit, and no common policy. An MCP server that
can reach a control plane is a privileged client, so shipping one safely
means shipping an access-control product. Aegis puts one governed control
plane in front of all of those engines, so every agent action runs through
a single fail-closed chain of identity, scope, policy, approval for
destructive actions, egress and request-forgery defense, rate limiting,
output redaction, and a tamper-evident audit trail. Engines plug in through
a small service provider interface and contribute no policy.
Current state, stated honestly. There is a working Java 21 build: a gateway
core, four in-depth adapters (Flink, Kafka, Spark, Iceberg), thinner
adapters for other Apache systems, and a runnable distribution. It builds
cleanly with 309 tests passing across all modules. A published
design-conformance matrix maps every design claim to Done or Roadmap.
Several capabilities ship as roadmap items and are not sold as done:
externalized high-availability state, CIMD and SPIFFE identity, a full
Cedar runtime, vault-backed credentials, and an OpenTelemetry SDK bridge.
Parts of the code were developed with AI-assisted tools under my direction
and review, which I disclose up front for IP clearance.
*Biggest risk: *The project is currently a single contributor. Growing a
diverse, multi-organization community is the main reason I am bringing it
here. I am currently in active conversations with engineers in the
ecosystem and expect to add a few of them as initial committers in the next
few days, prior to a formal vote
What I am looking for now: a Champion (an ASF Member) and mentors (three or
more IPMC members), ideally including people from the Flink, Kafka, Spark,
or Iceberg communities. The full proposal follows, and the reference
implementation is at https://github.com/vaquarkhan/aegis-mcp-gateway. I
welcome feedback on scope, name (a name search is still to be run), risks,
and anything I have missed.
Thank you,
Viquar Khan
https://www.linkedin.com/in/vaquar-khan-b695577/
Apache Incubator Proposal: Aegis MCP Governance Gateway
This is the proposal for entry into the Apache Incubator, written for
discussion on the Incubator general list. Aegis is a working codename; a
name search will be run and the ASF trademark process followed if the
project is accepted. The document follows the ASF Incubator proposal
template and states the maturity of the code honestly, including what is
implemented and what is deferred to the roadmap.
Field
Value
Proposal name
Aegis MCP Governance Gateway (codename)
Proposed short name
aegis (subject to name search)
Proposal date
to be set at submission
Sponsor
Apache Incubator PMC
Champion
to be identified (ASF Member)
Mentors
to be recruited (three or more IPMC members)
Initial code
Java 21 multi-module reference implementation, 36 Maven modules, 309 tests
passing
Reference repository
https://github.com/vaquarkhan/aegis-mcp-gateway (private for now, access on
request)
License
Apache License 2.0
Discussion list
general at incubator.apache.org
Abstract
Aegis MCP Governance Gateway is a vendor-neutral, secure-by-default Model
Context Protocol (MCP) gateway that puts one governed, auditable control
plane in front of many Apache data and streaming engines, so an AI agent
never talks to Flink, Kafka, Spark, or Iceberg directly. Every agent action
passes one fail-closed governance chain: secure-by-default tool exposure,
per-caller authentication and scope, a policy decision point, approval for
destructive operations, egress and server-side request forgery defense,
rate limiting, circuit breaking, prompt-injection screening, output
bounding and redaction, tool-catalog integrity, and a tamper-evident
hash-chained audit trail. Engines plug in through a small service provider
interface and contribute only tool definitions and backend calls.
Proposal
We propose to develop, under Apache governance, a Layer 7 policy MCP
gateway plus a family of engine adapters. A proxy forwards bytes and a
router dispatches by capability, but neither is a trust boundary. A gateway
is: it knows the tool, the principal, the budget, and the policy for every
call, and it can deny, redact, gate, and record. The gateway core is
stateless at the protocol edge so it can scale behind an ordinary load
balancer once shared governance state is externalized, and it is designed
to align with OAuth 2.1, SPIFFE, SLSA, OpenTelemetry, and the NIST AI Risk
Management Framework and ISO/IEC 42001.
The initial contribution is a working Java reference implementation: a
reusable gateway core, four in-depth engine adapters (Flink, Kafka, Spark,
Iceberg), and a further set of thinner adapters for the wider Apache data
platform. During incubation the priorities are community building, IP
clearance, and promoting the roadmap items to full implementations.
Background
The Model Context Protocol has become a common way for AI agents to reach
tools and data. As organizations connect agents to distributed Apache data
estates, an agent that needs Flink, Kafka, Spark, and Iceberg must either
drive each engine control plane directly or connect to a sprawl of
independent, mostly read-only MCP servers, each with its own security
posture, no shared audit, and no unified policy.
An MCP server that can reach a control plane (a JobManager REST API, a
Kafka AdminClient, a SQL gateway, an Iceberg catalog) is a privileged
client. Shipping one safely is effectively shipping an access-control
product: authentication, authorization, approval for destructive actions,
redaction of secrets and personal data, rate and cost limits, and forensic
audit. Many existing options lack these controls and carry
single-maintainer sustainability risk. A single governed gateway, developed
in the open under neutral governance, gives the ecosystem a shared standard
for how agents operate Apache systems safely.
Rationale
A single governed gateway resolves the problems of the decentralized
approach:
- Security. One place enforces identity, authorization, approval,
redaction, egress, and audit, instead of each server reimplementing or
omitting them.
- Maintainability. Adding an engine is a small adapter, not a new
security model. There is one chain to review and harden, so the security
review surface stays flat as engines are added.
- Governance. One control plane for policy, budget, and provenance, with
a stable deny taxonomy so operators can alert on codes such as
POLICY_DENIED or APPROVAL_REQUIRED across every engine with one rule.
Doing this under Apache governance keeps it neutral across vendors and
engines rather than leaving agent access to fragmented single-vendor
servers.
Initial goals
1. Establish the project and practice the Apache Way: transparency,
consensus, meritocracy, and community over code.
2. Complete IP clearance for the existing code and land it under
Apache-2.0 with correct LICENSE and NOTICE files.
3. Publish and stabilize the adapter service provider interface so
per-engine adapters are small, reviewable contributions.
4. Promote the roadmap items to full implementations: externalized
high-availability state, CIMD and SPIFFE identity, a full Cedar runtime,
vault-backed credential exchange, and an OpenTelemetry SDK bridge.
5. Produce the first Apache source releases and grow a diverse,
multi-organization contributor base.
Current status
Aegis is a new codebase with a working multi-module reference
implementation. It is not yet a community. The design, threat model,
low-level design, and standards research are complete and public. The code
builds green and is tested. A published design-conformance matrix maps
every design claim to Done or Roadmap, so the maturity line is explicit.
Verified build and test state
- 36 Maven modules: a gateway core, adapters for 33 Apache engines (four
in-depth today, Flink, Kafka, Spark, and Iceberg, and 29 thinner
integrations covering Cassandra, HBase, Hive, Pulsar, Airflow, NiFi, Druid,
Pinot, Doris, Impala, Calcite, Hudi, Paimon, Kudu, Ignite, BookKeeper,
Ozone, Hadoop, ZooKeeper, Solr, Superset, Arrow Flight, Beam, Storm, Flume,
ActiveMQ, CouchDB, Ranger, and Atlas), and a shaded runnable distribution.
These are engine adapters the gateway supports, which is distinct from
external adopters.
- Builds with JDK 21 and runs on JDK 17 or newer with Maven 3.9 or newer.
- 309 unit and integration tests across all modules, all passing, zero
failures and zero errors on a clean build.
Implemented in 0.1.0
- The governance chain with ordered steps and first-denial-wins
semantics.
- Identity: shared bearer and a hashed multi-caller token file with
per-caller scope, and an OAuth 2.1 resource-server mode with JWKS
validation. Constant-time secret comparison and fail-closed startup
validation.
- Approvals: HMAC-SHA256 signed, TTL-bounded, single-use,
tool-and-scope-bound tokens with replay rejection.
- Policy: a builtin decision point, a live fail-closed OPA HTTP decision
point, and a Cedar-style deny-file or HTTP delegate.
- Per-caller outbound credential pass-through so a downstream engine can
see a per-caller Authorization value when one was bound at admission.
- Egress and server-side request forgery defense: allow list plus
unconditional deny of cloud metadata and non-routable ranges, including
numeric IP encodings and resolved addresses, with redirects disabled on
outbound clients.
- Rate limiting, circuit breaking, per-tool timeout, read-only SQL
guard, identifier validation, output bounding, and data-loss-prevention
redaction.
- Tool-catalog integrity with durable pins and a fail-closed switch, a
tamper-evident hash-chained audit, Prometheus metrics, and GenAI-shaped
span log lines.
- Two transports: stdio and authenticated Streamable HTTP with TLS, plus
health, readiness, and metrics endpoints. A CycloneDX software bill of
materials is produced at build time.
Deferred to the roadmap (honestly labeled, not sold as implemented)
- CIMD and SPIFFE authentication modes (they refuse to start today).
- A full Cedar policy runtime, and vault-backed or token-exchange
credential resolution.
- Externalized high-availability state (shared nonce, rate, and audit
stores). Until then, run a single replica; multi-replica replay protection
and rate limits require the shared store.
- The MCP Tasks extension for long-running jobs, an OpenTelemetry SDK
bridge, a full Merkle and signature-based reconciliation proof, and true
semantic routing and caching.
These are tracked in the roadmap and the design-conformance matrix that
ship with the code.
Meritocracy, community, core developers, alignment
The project will operate meritocratically from day one, with technical
decisions on the dev list and committership earned through contribution.
The community is currently centered on the initial author, Viquar Khan, who
has around 23 years in software, has worked in the open since 2013, and has
contributed to Apache Spark, Apache Iceberg, Apache Kafka, and other
open-source projects. The author also maintains MCP-related open-source
packages that have together been downloaded on the order of half a million
times, so there is an existing user base to draw contributors from. Growing
a committer base across the Flink, Kafka, Spark, and Iceberg communities
and across employers is the primary goal of incubation. Aegis consumes
public engine interfaces only and does not fork or modify any engine core.
Known risks
Orphaned products
Low to moderate. Agentic access to data systems is a growing need and the
governance gap is real, so demand is unlikely to vanish. The initial author
has maintained open-source projects since 2013 rather than abandoning them,
and the MCP-related packages already have a real user base, which lowers
the abandonment risk. Mitigation: build a multi-organization community,
keep the core small and standards aligned, and keep adapters independent so
the project survives the departure of any single contributor.
Inexperience with open source
Low. This is not the situation here. The initial author has about 23 years
in software, has worked in open source since 2013, and has contributed to
Apache Spark, Apache Iceberg, Apache Kafka, and other projects, so the
norms of public development, code review, and releases are familiar.
Mentors will still help with the ASF-specific mechanics of voting, board
reports, and IP clearance, which are process details rather than a gap in
open-source experience.
Homogenous developers
This is the real risk and we state it plainly: the podling has one
committer today. However, we are in active discussions with potential
co-committers and expect to formally add them to this proposal in the
coming days. What further reduces this risk is that the author is already
embedded in the exact communities this project draws from (Spark, Iceberg,
Kafka) and has an existing user base for the MCP packages, so there is a
concrete pool to recruit from rather than a cold start. Mitigation: recruit
committers from more than one organization before graduation, shape the
adapter contract so per-engine contributions are natural, and use
good-first-issue and adapter-sized work to onboard newcomers. Growing the
committer base is the main reason we are here.
Reliance on salaried developers
Low current reliance; the work to date is largely independent. The project
will attract contributors with varied motivations and employers so no
single company can stall it.
Relationships with other Apache products
Aegis consumes the public interfaces of Flink, Kafka, Spark, Iceberg, and
other Apache data systems and does not fork or modify them. We will
coordinate on the relevant dev lists and will not duplicate or compete with
an engine that ships its own MCP surface; where an engine has one, Aegis
composes with it. Aegis is not proposed for any engine core.
Excessive fascination with the Apache brand
The project seeks Apache governance for its community model and neutrality,
not for the brand. Until and unless accepted, it uses a neutral name and
does not use the Apache marks or the feather. The breadth of engine
adapters reflects a common governance surface, not an attempt to claim the
ecosystem; only four adapters are in-depth today and the rest are
explicitly thin.
Documentation
Public documentation exists and will be maintained in the repository: an
end-to-end design with architecture decision records, a low-level design
with architecture, sequence, and state diagrams, a threat and governance
model, a design-conformance matrix, standards research, and operations and
adapter guides.
Initial source
The initial source is the Java multi-module gateway described above,
currently in a private repository at
https://github.com/vaquarkhan/aegis-mcp-gateway under the initial author.
Access is available on request to anyone reviewing this proposal, and the
author will make it public before the vote if the community prefers to read
the code first. It includes the gateway core, the four in-depth adapters,
the thinner adapters, the shaded distribution, runnable examples, and the
documentation set. On acceptance it will be donated under a Software Grant
and made public.
Source and intellectual property submission plan
The initial author will submit the code under a Software Grant Agreement
and complete IP clearance early in incubation, with ICLAs from every
committer. Every source file will carry the standard Apache-2.0 header with
correct LICENSE and NOTICE files; any premature ASF-ownership wording will
be corrected to the standard header at donation time.
Transparency on tooling: parts of the codebase were developed with
AI-assisted coding tools under the author's direction and review. The
author asserts authorship and the right to contribute the work, and will
confirm provenance and authorship during IP clearance so the grant is
clean. We raise this proactively so the IPMC can review it rather than
discover it.
External dependencies
Runtime dependencies are Apache-2.0 or compatible, including the MCP Java
SDK, a servlet container for the HTTP transport, SLF4J, Logback, and Nimbus
for JOSE and JWT, with JUnit for tests. Per-engine adapters add that engine
to the official client, for example the Kafka clients library. A full
dependency review and a CycloneDX software bill of materials are produced.
No GPL or ASF category X dependency is introduced into the core.
Cryptography
Aegis uses standard, library-based cryptography: HMAC-SHA256 for approval
tokens, TLS for the HTTP transport, and JSON Web Token validation for
OAuth. Signature-based integrity is an optional gate. The project will
comply with ASF export notification requirements.
Required resources
Mailing lists
- private@aegis.incubator.apache.org
- dev@aegis.incubator.apache.org
- commits@aegis.incubator.apache.org
Source control
- A Git repository under the ASF (gitbox with a GitHub mirror).
Issue tracking
- ASF Jira or GitHub issues per current ASF practice.
Other
- Website and wiki space, and continuous integration through ASF
infrastructure.
Initial committers
- Viquar Khan *(Note: We are in active conversations with potential
contributors and expect to add a few additional initial committers here in
the next few days before moving to a formal vote.)*
- To be recruited before and during incubation: committers from the
Flink, Kafka, Spark, and Iceberg communities and from additional
organizations. Adapter-sized work is designed to make these contributions
natural.
Affiliations
To be completed as committers are confirmed. Diversity of affiliation is an
explicit goal; the current single-affiliation status is the main risk being
addressed.
Sponsors
Champion
To be identified. An ASF Member Champion will help finalize this proposal,
recruit mentors, and shepherd the discussion and vote on the Incubator
general list.
Nominated mentors
Three or more IPMC members to be recruited, ideally including participants
from the Flink, Kafka, and Iceberg communities.
Sponsoring entity
The Apache Incubator PMC.
Roadmap during incubation
Phase
Focus
Bootstrap
IP clearance, name search, infra, initial committers, first dev-list
decisions
0.2
Externalized HA state, vault-backed credentials, OAuth multi-issuer, OTel
SDK bridge, supply-chain CI (enforcer, CVE scan, signing)
0.3
CIMD and SPIFFE identity, full Cedar runtime, MCP Tasks, signature-based
reconciliation proof, semantic routing and caching
Graduation readiness
Diverse community, cadence of Apache releases, healthy governance
References
- Apache Incubator proposal guide:
https://incubator.apache.org/guides/proposal.html
- Apache Incubator Cookbook: https://incubator.apache.org/cookbook/
- The Apache Way: https://www.apache.org/theapacheway/
- Model Context Protocol: https://modelcontextprotocol.io/
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
Hi PJ,
Fair point, and thanks for raising it. The "one committer" line is already
out of date. Thank you for your own contributions. We now have four or five
people active on the project, with six stars, two issues, and a few PRs. I
expect the committer base to grow naturally once there is a clear place to
plug in.
Larry, thank you, I would be glad to have you as a mentor and on the PPMC.
Knox is the closest analogue to what I am building for MCP governance, and
I would much rather learn from it than reinvent it. Your two points hit my
roadmap directly. The RFC 8693 token exchange with an actor chain is
exactly the delegation model I want instead of my current per-caller
pass-through, and that is my 0.2 credential work. Knox's shared JDBC token
state is the same gap behind my single-replica limit, which is my 0.2 HA
work. Your Ranger suggestion is worth talking through early. I will write
up a short mapping of the Aegis chain onto Knox's provider chain so we have
something concrete to look at.
Looking forward to working with you and learning from your guidance
Thanks all.
Viquar Khan
On Sat, Aug 8, 2026 at 9:25 PM Justin Mclean <ju...@classsoftware.com>
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
>
>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by PJ Fanning <fa...@apache.org>.
Hi Chandan,
You manage your own subscriptions.
The easiest easy to unsubscribe is
https://whimsy.apache.org/committers/subscribe
On Thu, 13 Aug 2026 at 05:08, Chandan Singh S M
<ch...@gmail.com> wrote:
>
> Please remove me from the general email list
>
> On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org> 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 <ju...@classsoftware.com>
> > > 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Andrew Musselman <ak...@apache.org>.
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 <va...@gmail.com> 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 <va...@gmail.com>
> > 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 <lm...@apache.org> 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 <va...@gmail.com>
> >>> 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 <
> >>> > chandansinghsm@gmail.com>
> >>> > wrote:
> >>> >
> >>> > > Please remove me from the general email list
> >>> > >
> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org>
> >>> 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 <
> >>> > justin@classsoftware.com
> >>> > >> >
> >>> > >> > 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
Hi Yu (and team),
Thanks for following up. To clarify my previous message it was
misunderstood : I haven't been idle or working on something separate , I’ve
been fully focused on this same project! Following guidance from Larry and
working with the team, I took time to review our architecture, implement a
whole new design, and rewrite the codebase.
While we have active contributors actively reviewing the architecture and
code, we really need a *Mentor-level review* at this stage to confirm we
are on the right path before moving further.
Here is a summary of where things stand and the key links for review:
Current Project Status & Aegis 2.0 Overview
-
*Architecture:* Rebuilt Aegis around a declarative MCP proxy with a thin
Knox extension (deployed through /ext) rather than per-service adapters.
-
*Review Branch:* The 2.0 rewrite is on the review branch:
aegis-mcp-gateway-2.0-review-ready
<https://github.com/vaquarkhan/aegis-mcp-gateway/tree/aegis-mcp-gateway-2.0-review-ready>
.
-
*Scope & Features:* Includes 41 feature families, 31 documented security
properties, 25 adapter configuration profiles defining 116 MCP tools, 7
executable reference configurations, and 28 tutorials/guides.
-
*Shared State & Persistence:* Shares approval, rate/budget windows, and
signing state via PostgreSQL when instances share a namespace.
Links for Review & Discussion
-
*GitHub Issue for Discussion:* Issue #34
<https://github.com/vaquarkhan/aegis-mcp-gateway/issues/34>
-
*Google Doc Discussion:* Architecture Discussion Doc
<https://docs.google.com/document/d/1V0Qf4J1bbWxhT9bp7Azvgzlv1LexBuWmPYMyIApVQlA/edit?tab=t.0&authuser=2>
-
*Documentation Site:* Aegis MCP Gateway Docs
<https://vaquarkhan.github.io/aegis-mcp-gateway/>
*In short:* The team is actively reviewing the code and discussing the
design, which you can see in the branch comments, new issues, bugs etc . We
are keeping our internal discussions in a separate group rather than the
incubator list.. We are also waiting for guidance and next steps from
Apache. .
Please take a look at the Google Doc or the GitHub issue and share your
thoughts. Your high-level review and feedback on this direction are greatly
appreciated!
Best regards,
Viquar Khan
On Fri, Oct 23, 2026 at 4:58 AM Yu Xiao <xi...@apache.org> wrote:
> Hi Viquar，
> I’m most interested in learning about this project is its core value
> and whether it will have enough active contributors going forward.
> I’ve been following this project, and as you mentioned, development
> has stalled because you’ve been busy—that’s my biggest concern right
> now.
> Joining the incubator is just the first step.
> Best wishes!
>
> Yu Xiao
> ASF Member
> Apache ShenYu V.P.
>
> vaquar khan <va...@gmail.com> 于2026年10月14日周三 06:11写道：
> >
> > Hi all,
> >
> > Sorry for the short break. I spent the last month on a major
> architectural
> > rewrite of Aegis, and I wanted the code to be ready before replying.
> >
> > Larry, thank you for your guidance. It gave the project its new shape.
> You
> > were right that per-service adapters would not scale and that Knox
> already
> > covered more than I realized. I corrected those assumptions and rebuilt
> > Aegis around a declarative MCP proxy with a thin Knox extension.
> >
> > Thanks also to Greg, Andrew, and Yu Xiao for your questions
> > ,feedback,support and to PJ for active contributions and help to build
> the
> > community and all active contributors .I have added Git issue for review
> > and discussion -
> https://github.com/vaquarkhan/aegis-mcp-gateway/issues/34
> >
> > *Where things are:*
> >
> > - main still has the original 0.1 code. The 2.0 work is on the review
> > branch:
> >
> https://github.com/vaquarkhan/aegis-mcp-gateway/tree/aegis-mcp-gateway-2.0-review-ready
> > - Knox cannot be reused directly because of its heavy dependencies.
> > Instead, Aegis now has two front doors on the same core: its own
> host, and
> > an out-of-tree Knox extension deployed through /ext. It is not a Knox
> fork,
> > and the extension packaging leaves Knox implementation classes.
> > - The per-engine adapters became declarative HTTP profiles.
> >
> >
> > *What is in the branch:*
> >
> > - 41 numbered feature families, plus five lettered subfeatures, and 31
> > documented security properties. These cover identity, authorization,
> > approvals, rate and budget controls, audit records, and protection
> against
> > rollback of signed catalogs and related governance documents.
> > - 25 adapter configuration profiles defining 116 MCP tools. The
> > default-build tests load and count all 25 configurations, exercise
> HTTP
> > tools through governance, and test converter tools separately.
> Live-product
> > evidence varies by profile.
> > - Seven executable reference configurations and one teaching template
> > for creating another configuration.
> > - Historical evidence from 28 earlier runs through both the Aegis own
> > host and its Knox extension. This includes 27 adopter profiles and one
> > Spark and Iceberg scenario. These runs were not repeated against the
> > current review candidate.
> > - Atlas, Cassandra, Impala, and Paimon have contract-tested
> > configurations, but no retained live-product runs.
> > - A step-by-step Hello World guide, 27 project tutorials, and a
> separate
> > Spark and Iceberg tutorial.
> > - Built-in token exchange works only for JWT-authenticated MCP
> requests
> > to the Aegis own host. It fails closed through Knox and for callers
> without
> > a verified JWT.
> > - When Aegis instances use the same PostgreSQL database and namespace,
> > they can share pending approvals, single-use approval and receipt
> state,
> > and rate and budget windows. Using approvals or receipts across
> instances
> > also requires matching gateway identity and signing settings.
> PostgreSQL
> > stores rollback high-water serials for signed server catalogs, catalog
> > manifests, and break-glass orders.
> >
> >
> > Docs: https://vaquarkhan.github.io/aegis-mcp-gateway/
> >
> > I would appreciate any feedback.
> >
> > Thanks,
> > Viquar Khan
> > https://www.linkedin.com/in/vaquar-khan-b695577
> >
> >
> > On Fri, Sep 18, 2026 at 12:53 AM vaquar khan <va...@gmail.com>
> wrote:
> >
> > > Hi Larry,
> > >
> > > Thank you, this was the most useful review the note has had, and it
> > > genuinely reshaped it for the better.
> > >
> > > First, you were right on the Knox conclusions. I went back and
> re-checked
> > > every claim against the Knox source instead of reasoning about it, and
> > > three were wrong, all of them cases where I said Knox lacked something
> it
> > > actually has: rate limiting (the webappsec DoSFilter), failover and
> retry
> > > (the HA dispatch), and per-service gating (the AclsAuthz provider).
> Those
> > > are fixed, and I have marked each correction so the history is clear.
> > >
> > > To make this easier to collaborate on than email threads or GitHub
> PRs, I
> > > have moved the corrected note into a Google Doc, please comment inline:
> > >
> > >
> https://docs.google.com/document/d/1V0Qf4J1bbWxhT9bp7Azvgzlv1LexBuWmPYMyIApVQlA/edit?tab=t.0
> > >
> > > *On your main question, what a separate piece buys over extending Knox,
> > > here is the short version, with the full evidence in the doc.*
> > >
> > > The core reason is that the two systems work on different planes. Knox
> > > authorizes the transport envelope: I checked AclsAuthorizationFilter,
> it
> > > decides on the principal, groups, and remote IP, and never reads the
> > > request body. MCP puts the operation, the tool name, and the arguments
> > > inside the JSON-RPC body on a single endpoint, so tools/list and a
> > > destructive tools/call are the same URL and method. Knox's own routing
> > > primitive, chains.match on the URL template, cannot tell them apart.
> > > Governing MCP means reading and deciding on the body of every call,
> keeping
> > > and checking per-session state, and screening content, which is a
> different
> > > job from routing REST by URL.
> > >
> > > The threat model is also inverted. Knox authenticates a caller and then
> > > trusts it for the route. Aegis has to assume the caller; the model may
> be
> > > manipulated by prompt injection and keep distrusting the content of
> every
> > > tool call, which is why per-request approval and injection screening
> exist.
> > > "Authenticate then trust" is hard to safely retrofit into "authenticate
> > > then keep distrusting each call"; that is a foundational assumption,
> not a
> > > filter you add on top.
> > >
> > > And to be clear, this is not Aegis instead of Knox. Where our needs
> > > overlap I want to consume Knox, not fork it. KnoxIDF is exactly the
> > > identity foundation I want to build on, federated OIDC plus RFC 8693
> token
> > > exchange with nested act claims is precisely what replaces the token
> > > pass-through Aegis does today, so I would love to align on that and on
> the
> > > AAuth and ID-JAG/XAA/EMA direction. The shape I am proposing is a
> portable
> > > governance core with a thin Knox /ext adapter, so Knox operators get
> this
> > > in-process with your deployment base, while teams not on Knox can
> still run
> > > it. That gives you the integration you are pointing at without folding
> a
> > > distinct, fast-moving governance layer into the gateway's release
> train.
> > >
> > > I have kept the doc honest about what the facts do and do not settle:
> they
> > > establish that this governance layer is a distinct data plane, I have
> > > proposed a protocol-fit prototype (mapping the MCP surface onto Knox's
> > > dispatch model) so we decide that on evidence rather than opinion.
> > >
> > > Thanks again for the guidance and for mentoring this. It has made the
> > > direction much sharper, whichever way we land.
> > >
> > > Best regards,
> > > Viquar Khan
> > >
> > >
> > > On Thu, Sep 17, 2026 at 8:27 AM larry mccay <lm...@apache.org> wrote:
> > >
> > >> Hi Viquar -
> > >>
> > >> The note looks good at a high level.
> > >> I wish github allowed comments on things like this without having to
> > >> create
> > >> a PR. :)
> > >> There are a bunch of Knox comparison conclusions that are not actually
> > >> true.
> > >> Most of what is claimed as not supported is actually supported.
> > >>
> > >> The general strategic goals are well defined though.
> > >>
> > >> I'm curious exactly what additional value having a separate server
> from
> > >> Knox brings.
> > >> Maybe we could just use the same server with this as a separate module
> > >> that
> > >> can be added to the /ext directory to extend the server.
> > >> This would buy us a large existing deployment base with all of the
> > >> provider
> > >> and gateway services built in right out of the box.
> > >>
> > >> In addition, maybe I mentioned this before, Knox 3.1.0 will have a new
> > >> service called KnoxIDF that allows for Knox to be a federated OIDC
> > >> provider
> > >> as well as targeting agentic identity related things.
> > >> The federation will allow for native integration with enterprise IDPs
> from
> > >> keycloak to Ping, to Okta and Entra.
> > >> Delegated Authentication provides RFC 8693 token exchange support (as
> your
> > >> note recognizes) with nested act claims for tracking the chain of
> actors
> > >> on
> > >> behalf of some identity.
> > >> There will be closer alignment with emerging standards like AAuth and
> > >> ID-JAG/XAA/EMA for agentic authorization and governance.
> > >>
> > >> Anyway, just a thought.
> > >>
> > >> You are on the right track either way!
> > >>
> > >> thanks,
> > >>
> > >> --larry
> > >>
> > >>
> > >> On Thu, Sep 17, 2026 at 12:41 AM vaquar khan <va...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hello everyone,
> > >> >
> > >> > Quick follow-up on my previous note both items are now complete:
> > >> >
> > >> > ICLA field. I have signed and sent the Individual Contributor
> License
> > >> > Agreement to the ASF Secretary.
> > >> >
> > >> > Knox mapping note published. I have written up the short document
> > >> mapping
> > >> > the Aegis governance steps onto the Apache Knox provider chain. It
> > >> > describes how the two share the same shape (entry point → ordered
> policy
> > >> > chain → backend), where Aegis can reuse Knox concepts, and a phased
> > >> plan.
> > >> > It is in the repo here:
> > >> >
> > >> >
> > >>
> https://github.com/vaquarkhan/aegis-mcp-gateway/blob/main/docs/NOTE-aegis-and-apache-knox.md
> > >> >
> > >> > I would welcome your review of the note whenever you have a chance,
> and
> > >> I
> > >> > am happy to adjust it based on community feedback.
> > >> >
> > >> > Best regards,
> > >> > Viquar Khan
> > >> >
> > >> > On Wed, Sep 9, 2026 at 3:55 AM Yu Xiao <xi...@apache.org> wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > I'm somewhat interested in this project. It does something
> similar to
> > >> > > the MCP plugin for Apache ShenYu.
> > >> > > If you're looking for a mentor, feel free to add me.
> > >> > >
> > >> > > Best wishes!
> > >> > >
> > >> > > Yu Xiao
> > >> > > ASF Member
> > >> > > Apache ShenYu V.P.
> > >> > >
> > >> > > vaquar khan <va...@gmail.com> 于2026年9月9日周三 14:52写道：
> > >> > > >
> > >> > > > Hi Greg,
> > >> > > >
> > >> > > > Thank you for formatting and uploading the proposal to the
> cwiki; it
> > >> > > looks
> > >> > > > great!
> > >> > > >
> > >> > > > I want to acknowledge your message and confirm that I am
> currently
> > >> > > working
> > >> > > > on the next steps:
> > >> > > >
> > >> > > > - I have reviewed the published cwiki proposal and it looks
> > >> awesome.
> > >> > > > - I will file the Individual Contributor License Agreement
> (ICLA)
> > >> as
> > >> > you
> > >> > > > suggested.
> > >> > > > - I am also working on a short document mapping the Aegis
> > >> governance
> > >> > > steps
> > >> > > > onto the Knox provider chain will update in github repo
> documents
> > >> for
> > >> > > > review.
> > >> > > >
> > >> > > > I will follow up once these are completed. Thanks again for your
> > >> > > guidance!
> > >> > > >
> > >> > > > Best regards,
> > >> > > > Viquar Khan
> > >> > > >
> > >> > > > On Tue, Sep 8, 2026 at 8:43 PM Greg Stein <gs...@gmail.com>
> wrote:
> > >> > > >
> > >> > > > > Oooh. It came out nicely. Thank you, Grok.
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > >
> > >> >
> > >>
> https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
> > >> > > > >
> > >> > > > >
> > >> > > > > On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com>
> > >> wrote:
> > >> > > > >
> > >> > > > > > Hey Viquar,
> > >> > > > > >
> > >> > > > > > Apologies for my absence. I've been focused on some
> RAI/LLMAO
> > >> work
> > >> > > over
> > >> > > > > > the past few weeks, getting that project launched.
> > >> > > > > >
> > >> > > > > > Let's get your proposal into cwiki. I'll take your original
> > >> > proposal
> > >> > > and
> > >> > > > > > get it formatted and placed in cwiki. I saw that you've got
> > >> further
> > >> > > > > updates
> > >> > > > > > after the discussion with Larry. We can figure that out as
> Step
> > >> > Two.
> > >> > > > > > Regardless of this process outcome, it would be helpful if
> you
> > >> > could
> > >> > > file
> > >> > > > > > an ICLA [1]. An easy step to grease any future wheels.
> > >> > > > > >
> > >> > > > > > I'll reply once I have a cwiki copy of your proposal.
> > >> > > > > >
> > >> > > > > > Cheers,
> > >> > > > > > -g
> > >> > > > > >
> > >> > > > > > [1]
> https://www.apache.org/licenses/contributor-agreements.html
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <
> > >> > vaquarjsr368@gmail.com>
> > >> > > > > > 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 <
> > >> > > vaquarjsr368@gmail.com>
> > >> > > > > >> 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 <
> > >> > > vaquarjsr368@gmail.com>
> > >> > > > > >> > 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 <
> > >> lmccay@apache.org>
> > >> > > > > 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 <
> > >> > > > > vaquarjsr368@gmail.com>
> > >> > > > > >> >>> 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 <
> > >> > > > > >> >>> > chandansinghsm@gmail.com>
> > >> > > > > >> >>> > wrote:
> > >> > > > > >> >>> >
> > >> > > > > >> >>> > > Please remove me from the general email list
> > >> > > > > >> >>> > >
> > >> > > > > >> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <
> > >> > lmccay@apache.org>
> > >> > > > > >> 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 <
> > >> > > lmccay@apache.org
> > >> > > > > >
> > >> > > > > >> >>> 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 <
> > >> > > > > >> >>> > justin@classsoftware.com
> > >> > > > > >> >>> > >> >
> > >> > > > > >> >>> > >> > 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: general-unsubscribe@incubator.apache.org
> > >> > > For additional commands, e-mail:
> general-help@incubator.apache.org
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Yu Xiao <xi...@apache.org>.
Hi Viquar，
I’m most interested in learning about this project is its core value
and whether it will have enough active contributors going forward.
I’ve been following this project, and as you mentioned, development
has stalled because you’ve been busy—that’s my biggest concern right
now.
Joining the incubator is just the first step.
Best wishes!
Yu Xiao
ASF Member
Apache ShenYu V.P.
vaquar khan <va...@gmail.com> 于2026年10月14日周三 06:11写道：
>
> Hi all,
>
> Sorry for the short break. I spent the last month on a major architectural
> rewrite of Aegis, and I wanted the code to be ready before replying.
>
> Larry, thank you for your guidance. It gave the project its new shape. You
> were right that per-service adapters would not scale and that Knox already
> covered more than I realized. I corrected those assumptions and rebuilt
> Aegis around a declarative MCP proxy with a thin Knox extension.
>
> Thanks also to Greg, Andrew, and Yu Xiao for your questions
> ,feedback,support and to PJ for active contributions and help to build the
> community and all active contributors .I have added Git issue for review
> and discussion - https://github.com/vaquarkhan/aegis-mcp-gateway/issues/34
>
> *Where things are:*
>
> - main still has the original 0.1 code. The 2.0 work is on the review
> branch:
> https://github.com/vaquarkhan/aegis-mcp-gateway/tree/aegis-mcp-gateway-2.0-review-ready
> - Knox cannot be reused directly because of its heavy dependencies.
> Instead, Aegis now has two front doors on the same core: its own host, and
> an out-of-tree Knox extension deployed through /ext. It is not a Knox fork,
> and the extension packaging leaves Knox implementation classes.
> - The per-engine adapters became declarative HTTP profiles.
>
>
> *What is in the branch:*
>
> - 41 numbered feature families, plus five lettered subfeatures, and 31
> documented security properties. These cover identity, authorization,
> approvals, rate and budget controls, audit records, and protection against
> rollback of signed catalogs and related governance documents.
> - 25 adapter configuration profiles defining 116 MCP tools. The
> default-build tests load and count all 25 configurations, exercise HTTP
> tools through governance, and test converter tools separately. Live-product
> evidence varies by profile.
> - Seven executable reference configurations and one teaching template
> for creating another configuration.
> - Historical evidence from 28 earlier runs through both the Aegis own
> host and its Knox extension. This includes 27 adopter profiles and one
> Spark and Iceberg scenario. These runs were not repeated against the
> current review candidate.
> - Atlas, Cassandra, Impala, and Paimon have contract-tested
> configurations, but no retained live-product runs.
> - A step-by-step Hello World guide, 27 project tutorials, and a separate
> Spark and Iceberg tutorial.
> - Built-in token exchange works only for JWT-authenticated MCP requests
> to the Aegis own host. It fails closed through Knox and for callers without
> a verified JWT.
> - When Aegis instances use the same PostgreSQL database and namespace,
> they can share pending approvals, single-use approval and receipt state,
> and rate and budget windows. Using approvals or receipts across instances
> also requires matching gateway identity and signing settings. PostgreSQL
> stores rollback high-water serials for signed server catalogs, catalog
> manifests, and break-glass orders.
>
>
> Docs: https://vaquarkhan.github.io/aegis-mcp-gateway/
>
> I would appreciate any feedback.
>
> Thanks,
> Viquar Khan
> https://www.linkedin.com/in/vaquar-khan-b695577
>
>
> On Fri, Sep 18, 2026 at 12:53 AM vaquar khan <va...@gmail.com> wrote:
>
> > Hi Larry,
> >
> > Thank you, this was the most useful review the note has had, and it
> > genuinely reshaped it for the better.
> >
> > First, you were right on the Knox conclusions. I went back and re-checked
> > every claim against the Knox source instead of reasoning about it, and
> > three were wrong, all of them cases where I said Knox lacked something it
> > actually has: rate limiting (the webappsec DoSFilter), failover and retry
> > (the HA dispatch), and per-service gating (the AclsAuthz provider). Those
> > are fixed, and I have marked each correction so the history is clear.
> >
> > To make this easier to collaborate on than email threads or GitHub PRs, I
> > have moved the corrected note into a Google Doc, please comment inline:
> >
> > https://docs.google.com/document/d/1V0Qf4J1bbWxhT9bp7Azvgzlv1LexBuWmPYMyIApVQlA/edit?tab=t.0
> >
> > *On your main question, what a separate piece buys over extending Knox,
> > here is the short version, with the full evidence in the doc.*
> >
> > The core reason is that the two systems work on different planes. Knox
> > authorizes the transport envelope: I checked AclsAuthorizationFilter, it
> > decides on the principal, groups, and remote IP, and never reads the
> > request body. MCP puts the operation, the tool name, and the arguments
> > inside the JSON-RPC body on a single endpoint, so tools/list and a
> > destructive tools/call are the same URL and method. Knox's own routing
> > primitive, chains.match on the URL template, cannot tell them apart.
> > Governing MCP means reading and deciding on the body of every call, keeping
> > and checking per-session state, and screening content, which is a different
> > job from routing REST by URL.
> >
> > The threat model is also inverted. Knox authenticates a caller and then
> > trusts it for the route. Aegis has to assume the caller; the model may be
> > manipulated by prompt injection and keep distrusting the content of every
> > tool call, which is why per-request approval and injection screening exist.
> > "Authenticate then trust" is hard to safely retrofit into "authenticate
> > then keep distrusting each call"; that is a foundational assumption, not a
> > filter you add on top.
> >
> > And to be clear, this is not Aegis instead of Knox. Where our needs
> > overlap I want to consume Knox, not fork it. KnoxIDF is exactly the
> > identity foundation I want to build on, federated OIDC plus RFC 8693 token
> > exchange with nested act claims is precisely what replaces the token
> > pass-through Aegis does today, so I would love to align on that and on the
> > AAuth and ID-JAG/XAA/EMA direction. The shape I am proposing is a portable
> > governance core with a thin Knox /ext adapter, so Knox operators get this
> > in-process with your deployment base, while teams not on Knox can still run
> > it. That gives you the integration you are pointing at without folding a
> > distinct, fast-moving governance layer into the gateway's release train.
> >
> > I have kept the doc honest about what the facts do and do not settle: they
> > establish that this governance layer is a distinct data plane, I have
> > proposed a protocol-fit prototype (mapping the MCP surface onto Knox's
> > dispatch model) so we decide that on evidence rather than opinion.
> >
> > Thanks again for the guidance and for mentoring this. It has made the
> > direction much sharper, whichever way we land.
> >
> > Best regards,
> > Viquar Khan
> >
> >
> > On Thu, Sep 17, 2026 at 8:27 AM larry mccay <lm...@apache.org> wrote:
> >
> >> Hi Viquar -
> >>
> >> The note looks good at a high level.
> >> I wish github allowed comments on things like this without having to
> >> create
> >> a PR. :)
> >> There are a bunch of Knox comparison conclusions that are not actually
> >> true.
> >> Most of what is claimed as not supported is actually supported.
> >>
> >> The general strategic goals are well defined though.
> >>
> >> I'm curious exactly what additional value having a separate server from
> >> Knox brings.
> >> Maybe we could just use the same server with this as a separate module
> >> that
> >> can be added to the /ext directory to extend the server.
> >> This would buy us a large existing deployment base with all of the
> >> provider
> >> and gateway services built in right out of the box.
> >>
> >> In addition, maybe I mentioned this before, Knox 3.1.0 will have a new
> >> service called KnoxIDF that allows for Knox to be a federated OIDC
> >> provider
> >> as well as targeting agentic identity related things.
> >> The federation will allow for native integration with enterprise IDPs from
> >> keycloak to Ping, to Okta and Entra.
> >> Delegated Authentication provides RFC 8693 token exchange support (as your
> >> note recognizes) with nested act claims for tracking the chain of actors
> >> on
> >> behalf of some identity.
> >> There will be closer alignment with emerging standards like AAuth and
> >> ID-JAG/XAA/EMA for agentic authorization and governance.
> >>
> >> Anyway, just a thought.
> >>
> >> You are on the right track either way!
> >>
> >> thanks,
> >>
> >> --larry
> >>
> >>
> >> On Thu, Sep 17, 2026 at 12:41 AM vaquar khan <va...@gmail.com>
> >> wrote:
> >>
> >> > Hello everyone,
> >> >
> >> > Quick follow-up on my previous note both items are now complete:
> >> >
> >> > ICLA field. I have signed and sent the Individual Contributor License
> >> > Agreement to the ASF Secretary.
> >> >
> >> > Knox mapping note published. I have written up the short document
> >> mapping
> >> > the Aegis governance steps onto the Apache Knox provider chain. It
> >> > describes how the two share the same shape (entry point → ordered policy
> >> > chain → backend), where Aegis can reuse Knox concepts, and a phased
> >> plan.
> >> > It is in the repo here:
> >> >
> >> >
> >> https://github.com/vaquarkhan/aegis-mcp-gateway/blob/main/docs/NOTE-aegis-and-apache-knox.md
> >> >
> >> > I would welcome your review of the note whenever you have a chance, and
> >> I
> >> > am happy to adjust it based on community feedback.
> >> >
> >> > Best regards,
> >> > Viquar Khan
> >> >
> >> > On Wed, Sep 9, 2026 at 3:55 AM Yu Xiao <xi...@apache.org> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I'm somewhat interested in this project. It does something similar to
> >> > > the MCP plugin for Apache ShenYu.
> >> > > If you're looking for a mentor, feel free to add me.
> >> > >
> >> > > Best wishes!
> >> > >
> >> > > Yu Xiao
> >> > > ASF Member
> >> > > Apache ShenYu V.P.
> >> > >
> >> > > vaquar khan <va...@gmail.com> 于2026年9月9日周三 14:52写道：
> >> > > >
> >> > > > Hi Greg,
> >> > > >
> >> > > > Thank you for formatting and uploading the proposal to the cwiki; it
> >> > > looks
> >> > > > great!
> >> > > >
> >> > > > I want to acknowledge your message and confirm that I am currently
> >> > > working
> >> > > > on the next steps:
> >> > > >
> >> > > > - I have reviewed the published cwiki proposal and it looks
> >> awesome.
> >> > > > - I will file the Individual Contributor License Agreement (ICLA)
> >> as
> >> > you
> >> > > > suggested.
> >> > > > - I am also working on a short document mapping the Aegis
> >> governance
> >> > > steps
> >> > > > onto the Knox provider chain will update in github repo documents
> >> for
> >> > > > review.
> >> > > >
> >> > > > I will follow up once these are completed. Thanks again for your
> >> > > guidance!
> >> > > >
> >> > > > Best regards,
> >> > > > Viquar Khan
> >> > > >
> >> > > > On Tue, Sep 8, 2026 at 8:43 PM Greg Stein <gs...@gmail.com> wrote:
> >> > > >
> >> > > > > Oooh. It came out nicely. Thank you, Grok.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > >
> >> >
> >> https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
> >> > > > >
> >> > > > >
> >> > > > > On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com>
> >> wrote:
> >> > > > >
> >> > > > > > Hey Viquar,
> >> > > > > >
> >> > > > > > Apologies for my absence. I've been focused on some RAI/LLMAO
> >> work
> >> > > over
> >> > > > > > the past few weeks, getting that project launched.
> >> > > > > >
> >> > > > > > Let's get your proposal into cwiki. I'll take your original
> >> > proposal
> >> > > and
> >> > > > > > get it formatted and placed in cwiki. I saw that you've got
> >> further
> >> > > > > updates
> >> > > > > > after the discussion with Larry. We can figure that out as Step
> >> > Two.
> >> > > > > > Regardless of this process outcome, it would be helpful if you
> >> > could
> >> > > file
> >> > > > > > an ICLA [1]. An easy step to grease any future wheels.
> >> > > > > >
> >> > > > > > I'll reply once I have a cwiki copy of your proposal.
> >> > > > > >
> >> > > > > > Cheers,
> >> > > > > > -g
> >> > > > > >
> >> > > > > > [1] https://www.apache.org/licenses/contributor-agreements.html
> >> > > > > >
> >> > > > > >
> >> > > > > > On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <
> >> > vaquarjsr368@gmail.com>
> >> > > > > > 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 <
> >> > > vaquarjsr368@gmail.com>
> >> > > > > >> 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 <
> >> > > vaquarjsr368@gmail.com>
> >> > > > > >> > 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 <
> >> lmccay@apache.org>
> >> > > > > 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 <
> >> > > > > vaquarjsr368@gmail.com>
> >> > > > > >> >>> 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 <
> >> > > > > >> >>> > chandansinghsm@gmail.com>
> >> > > > > >> >>> > wrote:
> >> > > > > >> >>> >
> >> > > > > >> >>> > > Please remove me from the general email list
> >> > > > > >> >>> > >
> >> > > > > >> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <
> >> > lmccay@apache.org>
> >> > > > > >> 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 <
> >> > > lmccay@apache.org
> >> > > > > >
> >> > > > > >> >>> 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 <
> >> > > > > >> >>> > justin@classsoftware.com
> >> > > > > >> >>> > >> >
> >> > > > > >> >>> > >> > 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: general-unsubscribe@incubator.apache.org
> >> > > For additional commands, e-mail: general-help@incubator.apache.org
> >> > >
> >> > >
> >> >
> >>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
Hi all,
Sorry for the short break. I spent the last month on a major architectural
rewrite of Aegis, and I wanted the code to be ready before replying.
Larry, thank you for your guidance. It gave the project its new shape. You
were right that per-service adapters would not scale and that Knox already
covered more than I realized. I corrected those assumptions and rebuilt
Aegis around a declarative MCP proxy with a thin Knox extension.
Thanks also to Greg, Andrew, and Yu Xiao for your questions
,feedback,support and to PJ for active contributions and help to build the
community and all active contributors .I have added Git issue for review
and discussion - https://github.com/vaquarkhan/aegis-mcp-gateway/issues/34
*Where things are:*
- main still has the original 0.1 code. The 2.0 work is on the review
branch:
https://github.com/vaquarkhan/aegis-mcp-gateway/tree/aegis-mcp-gateway-2.0-review-ready
- Knox cannot be reused directly because of its heavy dependencies.
Instead, Aegis now has two front doors on the same core: its own host, and
an out-of-tree Knox extension deployed through /ext. It is not a Knox fork,
and the extension packaging leaves Knox implementation classes.
- The per-engine adapters became declarative HTTP profiles.
*What is in the branch:*
- 41 numbered feature families, plus five lettered subfeatures, and 31
documented security properties. These cover identity, authorization,
approvals, rate and budget controls, audit records, and protection against
rollback of signed catalogs and related governance documents.
- 25 adapter configuration profiles defining 116 MCP tools. The
default-build tests load and count all 25 configurations, exercise HTTP
tools through governance, and test converter tools separately. Live-product
evidence varies by profile.
- Seven executable reference configurations and one teaching template
for creating another configuration.
- Historical evidence from 28 earlier runs through both the Aegis own
host and its Knox extension. This includes 27 adopter profiles and one
Spark and Iceberg scenario. These runs were not repeated against the
current review candidate.
- Atlas, Cassandra, Impala, and Paimon have contract-tested
configurations, but no retained live-product runs.
- A step-by-step Hello World guide, 27 project tutorials, and a separate
Spark and Iceberg tutorial.
- Built-in token exchange works only for JWT-authenticated MCP requests
to the Aegis own host. It fails closed through Knox and for callers without
a verified JWT.
- When Aegis instances use the same PostgreSQL database and namespace,
they can share pending approvals, single-use approval and receipt state,
and rate and budget windows. Using approvals or receipts across instances
also requires matching gateway identity and signing settings. PostgreSQL
stores rollback high-water serials for signed server catalogs, catalog
manifests, and break-glass orders.
Docs: https://vaquarkhan.github.io/aegis-mcp-gateway/
I would appreciate any feedback.
Thanks,
Viquar Khan
https://www.linkedin.com/in/vaquar-khan-b695577
On Fri, Sep 18, 2026 at 12:53 AM vaquar khan <va...@gmail.com> wrote:
> Hi Larry,
>
> Thank you, this was the most useful review the note has had, and it
> genuinely reshaped it for the better.
>
> First, you were right on the Knox conclusions. I went back and re-checked
> every claim against the Knox source instead of reasoning about it, and
> three were wrong, all of them cases where I said Knox lacked something it
> actually has: rate limiting (the webappsec DoSFilter), failover and retry
> (the HA dispatch), and per-service gating (the AclsAuthz provider). Those
> are fixed, and I have marked each correction so the history is clear.
>
> To make this easier to collaborate on than email threads or GitHub PRs, I
> have moved the corrected note into a Google Doc, please comment inline:
>
> https://docs.google.com/document/d/1V0Qf4J1bbWxhT9bp7Azvgzlv1LexBuWmPYMyIApVQlA/edit?tab=t.0
>
> *On your main question, what a separate piece buys over extending Knox,
> here is the short version, with the full evidence in the doc.*
>
> The core reason is that the two systems work on different planes. Knox
> authorizes the transport envelope: I checked AclsAuthorizationFilter, it
> decides on the principal, groups, and remote IP, and never reads the
> request body. MCP puts the operation, the tool name, and the arguments
> inside the JSON-RPC body on a single endpoint, so tools/list and a
> destructive tools/call are the same URL and method. Knox's own routing
> primitive, chains.match on the URL template, cannot tell them apart.
> Governing MCP means reading and deciding on the body of every call, keeping
> and checking per-session state, and screening content, which is a different
> job from routing REST by URL.
>
> The threat model is also inverted. Knox authenticates a caller and then
> trusts it for the route. Aegis has to assume the caller; the model may be
> manipulated by prompt injection and keep distrusting the content of every
> tool call, which is why per-request approval and injection screening exist.
> "Authenticate then trust" is hard to safely retrofit into "authenticate
> then keep distrusting each call"; that is a foundational assumption, not a
> filter you add on top.
>
> And to be clear, this is not Aegis instead of Knox. Where our needs
> overlap I want to consume Knox, not fork it. KnoxIDF is exactly the
> identity foundation I want to build on, federated OIDC plus RFC 8693 token
> exchange with nested act claims is precisely what replaces the token
> pass-through Aegis does today, so I would love to align on that and on the
> AAuth and ID-JAG/XAA/EMA direction. The shape I am proposing is a portable
> governance core with a thin Knox /ext adapter, so Knox operators get this
> in-process with your deployment base, while teams not on Knox can still run
> it. That gives you the integration you are pointing at without folding a
> distinct, fast-moving governance layer into the gateway's release train.
>
> I have kept the doc honest about what the facts do and do not settle: they
> establish that this governance layer is a distinct data plane, I have
> proposed a protocol-fit prototype (mapping the MCP surface onto Knox's
> dispatch model) so we decide that on evidence rather than opinion.
>
> Thanks again for the guidance and for mentoring this. It has made the
> direction much sharper, whichever way we land.
>
> Best regards,
> Viquar Khan
>
>
> On Thu, Sep 17, 2026 at 8:27 AM larry mccay <lm...@apache.org> wrote:
>
>> Hi Viquar -
>>
>> The note looks good at a high level.
>> I wish github allowed comments on things like this without having to
>> create
>> a PR. :)
>> There are a bunch of Knox comparison conclusions that are not actually
>> true.
>> Most of what is claimed as not supported is actually supported.
>>
>> The general strategic goals are well defined though.
>>
>> I'm curious exactly what additional value having a separate server from
>> Knox brings.
>> Maybe we could just use the same server with this as a separate module
>> that
>> can be added to the /ext directory to extend the server.
>> This would buy us a large existing deployment base with all of the
>> provider
>> and gateway services built in right out of the box.
>>
>> In addition, maybe I mentioned this before, Knox 3.1.0 will have a new
>> service called KnoxIDF that allows for Knox to be a federated OIDC
>> provider
>> as well as targeting agentic identity related things.
>> The federation will allow for native integration with enterprise IDPs from
>> keycloak to Ping, to Okta and Entra.
>> Delegated Authentication provides RFC 8693 token exchange support (as your
>> note recognizes) with nested act claims for tracking the chain of actors
>> on
>> behalf of some identity.
>> There will be closer alignment with emerging standards like AAuth and
>> ID-JAG/XAA/EMA for agentic authorization and governance.
>>
>> Anyway, just a thought.
>>
>> You are on the right track either way!
>>
>> thanks,
>>
>> --larry
>>
>>
>> On Thu, Sep 17, 2026 at 12:41 AM vaquar khan <va...@gmail.com>
>> wrote:
>>
>> > Hello everyone,
>> >
>> > Quick follow-up on my previous note both items are now complete:
>> >
>> > ICLA field. I have signed and sent the Individual Contributor License
>> > Agreement to the ASF Secretary.
>> >
>> > Knox mapping note published. I have written up the short document
>> mapping
>> > the Aegis governance steps onto the Apache Knox provider chain. It
>> > describes how the two share the same shape (entry point → ordered policy
>> > chain → backend), where Aegis can reuse Knox concepts, and a phased
>> plan.
>> > It is in the repo here:
>> >
>> >
>> https://github.com/vaquarkhan/aegis-mcp-gateway/blob/main/docs/NOTE-aegis-and-apache-knox.md
>> >
>> > I would welcome your review of the note whenever you have a chance, and
>> I
>> > am happy to adjust it based on community feedback.
>> >
>> > Best regards,
>> > Viquar Khan
>> >
>> > On Wed, Sep 9, 2026 at 3:55 AM Yu Xiao <xi...@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > I'm somewhat interested in this project. It does something similar to
>> > > the MCP plugin for Apache ShenYu.
>> > > If you're looking for a mentor, feel free to add me.
>> > >
>> > > Best wishes!
>> > >
>> > > Yu Xiao
>> > > ASF Member
>> > > Apache ShenYu V.P.
>> > >
>> > > vaquar khan <va...@gmail.com> 于2026年9月9日周三 14:52写道：
>> > > >
>> > > > Hi Greg,
>> > > >
>> > > > Thank you for formatting and uploading the proposal to the cwiki; it
>> > > looks
>> > > > great!
>> > > >
>> > > > I want to acknowledge your message and confirm that I am currently
>> > > working
>> > > > on the next steps:
>> > > >
>> > > > - I have reviewed the published cwiki proposal and it looks
>> awesome.
>> > > > - I will file the Individual Contributor License Agreement (ICLA)
>> as
>> > you
>> > > > suggested.
>> > > > - I am also working on a short document mapping the Aegis
>> governance
>> > > steps
>> > > > onto the Knox provider chain will update in github repo documents
>> for
>> > > > review.
>> > > >
>> > > > I will follow up once these are completed. Thanks again for your
>> > > guidance!
>> > > >
>> > > > Best regards,
>> > > > Viquar Khan
>> > > >
>> > > > On Tue, Sep 8, 2026 at 8:43 PM Greg Stein <gs...@gmail.com> wrote:
>> > > >
>> > > > > Oooh. It came out nicely. Thank you, Grok.
>> > > > >
>> > > > >
>> > > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
>> > > > >
>> > > > >
>> > > > > On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com>
>> wrote:
>> > > > >
>> > > > > > Hey Viquar,
>> > > > > >
>> > > > > > Apologies for my absence. I've been focused on some RAI/LLMAO
>> work
>> > > over
>> > > > > > the past few weeks, getting that project launched.
>> > > > > >
>> > > > > > Let's get your proposal into cwiki. I'll take your original
>> > proposal
>> > > and
>> > > > > > get it formatted and placed in cwiki. I saw that you've got
>> further
>> > > > > updates
>> > > > > > after the discussion with Larry. We can figure that out as Step
>> > Two.
>> > > > > > Regardless of this process outcome, it would be helpful if you
>> > could
>> > > file
>> > > > > > an ICLA [1]. An easy step to grease any future wheels.
>> > > > > >
>> > > > > > I'll reply once I have a cwiki copy of your proposal.
>> > > > > >
>> > > > > > Cheers,
>> > > > > > -g
>> > > > > >
>> > > > > > [1] https://www.apache.org/licenses/contributor-agreements.html
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <
>> > vaquarjsr368@gmail.com>
>> > > > > > 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 <
>> > > vaquarjsr368@gmail.com>
>> > > > > >> 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 <
>> > > vaquarjsr368@gmail.com>
>> > > > > >> > 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 <
>> lmccay@apache.org>
>> > > > > 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 <
>> > > > > vaquarjsr368@gmail.com>
>> > > > > >> >>> 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 <
>> > > > > >> >>> > chandansinghsm@gmail.com>
>> > > > > >> >>> > wrote:
>> > > > > >> >>> >
>> > > > > >> >>> > > Please remove me from the general email list
>> > > > > >> >>> > >
>> > > > > >> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <
>> > lmccay@apache.org>
>> > > > > >> 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 <
>> > > lmccay@apache.org
>> > > > > >
>> > > > > >> >>> 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 <
>> > > > > >> >>> > justin@classsoftware.com
>> > > > > >> >>> > >> >
>> > > > > >> >>> > >> > 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: general-unsubscribe@incubator.apache.org
>> > > For additional commands, e-mail: general-help@incubator.apache.org
>> > >
>> > >
>> >
>>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
Hi Larry,
Thank you, this was the most useful review the note has had, and it
genuinely reshaped it for the better.
First, you were right on the Knox conclusions. I went back and re-checked
every claim against the Knox source instead of reasoning about it, and
three were wrong, all of them cases where I said Knox lacked something it
actually has: rate limiting (the webappsec DoSFilter), failover and retry
(the HA dispatch), and per-service gating (the AclsAuthz provider). Those
are fixed, and I have marked each correction so the history is clear.
To make this easier to collaborate on than email threads or GitHub PRs, I
have moved the corrected note into a Google Doc, please comment inline:
https://docs.google.com/document/d/1V0Qf4J1bbWxhT9bp7Azvgzlv1LexBuWmPYMyIApVQlA/edit?tab=t.0
*On your main question, what a separate piece buys over extending Knox,
here is the short version, with the full evidence in the doc.*
The core reason is that the two systems work on different planes. Knox
authorizes the transport envelope: I checked AclsAuthorizationFilter, it
decides on the principal, groups, and remote IP, and never reads the
request body. MCP puts the operation, the tool name, and the arguments
inside the JSON-RPC body on a single endpoint, so tools/list and a
destructive tools/call are the same URL and method. Knox's own routing
primitive, chains.match on the URL template, cannot tell them apart.
Governing MCP means reading and deciding on the body of every call, keeping
and checking per-session state, and screening content, which is a different
job from routing REST by URL.
The threat model is also inverted. Knox authenticates a caller and then
trusts it for the route. Aegis has to assume the caller; the model may be
manipulated by prompt injection and keep distrusting the content of every
tool call, which is why per-request approval and injection screening exist.
"Authenticate then trust" is hard to safely retrofit into "authenticate
then keep distrusting each call"; that is a foundational assumption, not a
filter you add on top.
And to be clear, this is not Aegis instead of Knox. Where our needs overlap
I want to consume Knox, not fork it. KnoxIDF is exactly the identity
foundation I want to build on, federated OIDC plus RFC 8693 token exchange
with nested act claims is precisely what replaces the token pass-through
Aegis does today, so I would love to align on that and on the AAuth and
ID-JAG/XAA/EMA direction. The shape I am proposing is a portable governance
core with a thin Knox /ext adapter, so Knox operators get this in-process
with your deployment base, while teams not on Knox can still run it. That
gives you the integration you are pointing at without folding a distinct,
fast-moving governance layer into the gateway's release train.
I have kept the doc honest about what the facts do and do not settle: they
establish that this governance layer is a distinct data plane, I have
proposed a protocol-fit prototype (mapping the MCP surface onto Knox's
dispatch model) so we decide that on evidence rather than opinion.
Thanks again for the guidance and for mentoring this. It has made the
direction much sharper, whichever way we land.
Best regards,
Viquar Khan
On Thu, Sep 17, 2026 at 8:27 AM larry mccay <lm...@apache.org> wrote:
> Hi Viquar -
>
> The note looks good at a high level.
> I wish github allowed comments on things like this without having to create
> a PR. :)
> There are a bunch of Knox comparison conclusions that are not actually
> true.
> Most of what is claimed as not supported is actually supported.
>
> The general strategic goals are well defined though.
>
> I'm curious exactly what additional value having a separate server from
> Knox brings.
> Maybe we could just use the same server with this as a separate module that
> can be added to the /ext directory to extend the server.
> This would buy us a large existing deployment base with all of the provider
> and gateway services built in right out of the box.
>
> In addition, maybe I mentioned this before, Knox 3.1.0 will have a new
> service called KnoxIDF that allows for Knox to be a federated OIDC provider
> as well as targeting agentic identity related things.
> The federation will allow for native integration with enterprise IDPs from
> keycloak to Ping, to Okta and Entra.
> Delegated Authentication provides RFC 8693 token exchange support (as your
> note recognizes) with nested act claims for tracking the chain of actors on
> behalf of some identity.
> There will be closer alignment with emerging standards like AAuth and
> ID-JAG/XAA/EMA for agentic authorization and governance.
>
> Anyway, just a thought.
>
> You are on the right track either way!
>
> thanks,
>
> --larry
>
>
> On Thu, Sep 17, 2026 at 12:41 AM vaquar khan <va...@gmail.com>
> wrote:
>
> > Hello everyone,
> >
> > Quick follow-up on my previous note both items are now complete:
> >
> > ICLA field. I have signed and sent the Individual Contributor License
> > Agreement to the ASF Secretary.
> >
> > Knox mapping note published. I have written up the short document mapping
> > the Aegis governance steps onto the Apache Knox provider chain. It
> > describes how the two share the same shape (entry point → ordered policy
> > chain → backend), where Aegis can reuse Knox concepts, and a phased plan.
> > It is in the repo here:
> >
> >
> https://github.com/vaquarkhan/aegis-mcp-gateway/blob/main/docs/NOTE-aegis-and-apache-knox.md
> >
> > I would welcome your review of the note whenever you have a chance, and I
> > am happy to adjust it based on community feedback.
> >
> > Best regards,
> > Viquar Khan
> >
> > On Wed, Sep 9, 2026 at 3:55 AM Yu Xiao <xi...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > I'm somewhat interested in this project. It does something similar to
> > > the MCP plugin for Apache ShenYu.
> > > If you're looking for a mentor, feel free to add me.
> > >
> > > Best wishes!
> > >
> > > Yu Xiao
> > > ASF Member
> > > Apache ShenYu V.P.
> > >
> > > vaquar khan <va...@gmail.com> 于2026年9月9日周三 14:52写道：
> > > >
> > > > Hi Greg,
> > > >
> > > > Thank you for formatting and uploading the proposal to the cwiki; it
> > > looks
> > > > great!
> > > >
> > > > I want to acknowledge your message and confirm that I am currently
> > > working
> > > > on the next steps:
> > > >
> > > > - I have reviewed the published cwiki proposal and it looks awesome.
> > > > - I will file the Individual Contributor License Agreement (ICLA) as
> > you
> > > > suggested.
> > > > - I am also working on a short document mapping the Aegis governance
> > > steps
> > > > onto the Knox provider chain will update in github repo documents for
> > > > review.
> > > >
> > > > I will follow up once these are completed. Thanks again for your
> > > guidance!
> > > >
> > > > Best regards,
> > > > Viquar Khan
> > > >
> > > > On Tue, Sep 8, 2026 at 8:43 PM Greg Stein <gs...@gmail.com> wrote:
> > > >
> > > > > Oooh. It came out nicely. Thank you, Grok.
> > > > >
> > > > >
> > > > >
> > >
> >
> https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
> > > > >
> > > > >
> > > > > On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com>
> wrote:
> > > > >
> > > > > > Hey Viquar,
> > > > > >
> > > > > > Apologies for my absence. I've been focused on some RAI/LLMAO
> work
> > > over
> > > > > > the past few weeks, getting that project launched.
> > > > > >
> > > > > > Let's get your proposal into cwiki. I'll take your original
> > proposal
> > > and
> > > > > > get it formatted and placed in cwiki. I saw that you've got
> further
> > > > > updates
> > > > > > after the discussion with Larry. We can figure that out as Step
> > Two.
> > > > > > Regardless of this process outcome, it would be helpful if you
> > could
> > > file
> > > > > > an ICLA [1]. An easy step to grease any future wheels.
> > > > > >
> > > > > > I'll reply once I have a cwiki copy of your proposal.
> > > > > >
> > > > > > Cheers,
> > > > > > -g
> > > > > >
> > > > > > [1] https://www.apache.org/licenses/contributor-agreements.html
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <
> > vaquarjsr368@gmail.com>
> > > > > > 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 <
> > > vaquarjsr368@gmail.com>
> > > > > >> 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 <
> > > vaquarjsr368@gmail.com>
> > > > > >> > 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 <
> lmccay@apache.org>
> > > > > 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 <
> > > > > vaquarjsr368@gmail.com>
> > > > > >> >>> 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 <
> > > > > >> >>> > chandansinghsm@gmail.com>
> > > > > >> >>> > wrote:
> > > > > >> >>> >
> > > > > >> >>> > > Please remove me from the general email list
> > > > > >> >>> > >
> > > > > >> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <
> > lmccay@apache.org>
> > > > > >> 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 <
> > > lmccay@apache.org
> > > > > >
> > > > > >> >>> 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 <
> > > > > >> >>> > justin@classsoftware.com
> > > > > >> >>> > >> >
> > > > > >> >>> > >> > 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: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by larry mccay <lm...@apache.org>.
Hi Viquar -
The note looks good at a high level.
I wish github allowed comments on things like this without having to create
a PR. :)
There are a bunch of Knox comparison conclusions that are not actually true.
Most of what is claimed as not supported is actually supported.
The general strategic goals are well defined though.
I'm curious exactly what additional value having a separate server from
Knox brings.
Maybe we could just use the same server with this as a separate module that
can be added to the /ext directory to extend the server.
This would buy us a large existing deployment base with all of the provider
and gateway services built in right out of the box.
In addition, maybe I mentioned this before, Knox 3.1.0 will have a new
service called KnoxIDF that allows for Knox to be a federated OIDC provider
as well as targeting agentic identity related things.
The federation will allow for native integration with enterprise IDPs from
keycloak to Ping, to Okta and Entra.
Delegated Authentication provides RFC 8693 token exchange support (as your
note recognizes) with nested act claims for tracking the chain of actors on
behalf of some identity.
There will be closer alignment with emerging standards like AAuth and
ID-JAG/XAA/EMA for agentic authorization and governance.
Anyway, just a thought.
You are on the right track either way!
thanks,
--larry
On Thu, Sep 17, 2026 at 12:41 AM vaquar khan <va...@gmail.com> wrote:
> Hello everyone,
>
> Quick follow-up on my previous note both items are now complete:
>
> ICLA field. I have signed and sent the Individual Contributor License
> Agreement to the ASF Secretary.
>
> Knox mapping note published. I have written up the short document mapping
> the Aegis governance steps onto the Apache Knox provider chain. It
> describes how the two share the same shape (entry point → ordered policy
> chain → backend), where Aegis can reuse Knox concepts, and a phased plan.
> It is in the repo here:
>
> https://github.com/vaquarkhan/aegis-mcp-gateway/blob/main/docs/NOTE-aegis-and-apache-knox.md
>
> I would welcome your review of the note whenever you have a chance, and I
> am happy to adjust it based on community feedback.
>
> Best regards,
> Viquar Khan
>
> On Wed, Sep 9, 2026 at 3:55 AM Yu Xiao <xi...@apache.org> wrote:
>
> > Hi,
> >
> > I'm somewhat interested in this project. It does something similar to
> > the MCP plugin for Apache ShenYu.
> > If you're looking for a mentor, feel free to add me.
> >
> > Best wishes!
> >
> > Yu Xiao
> > ASF Member
> > Apache ShenYu V.P.
> >
> > vaquar khan <va...@gmail.com> 于2026年9月9日周三 14:52写道：
> > >
> > > Hi Greg,
> > >
> > > Thank you for formatting and uploading the proposal to the cwiki; it
> > looks
> > > great!
> > >
> > > I want to acknowledge your message and confirm that I am currently
> > working
> > > on the next steps:
> > >
> > > - I have reviewed the published cwiki proposal and it looks awesome.
> > > - I will file the Individual Contributor License Agreement (ICLA) as
> you
> > > suggested.
> > > - I am also working on a short document mapping the Aegis governance
> > steps
> > > onto the Knox provider chain will update in github repo documents for
> > > review.
> > >
> > > I will follow up once these are completed. Thanks again for your
> > guidance!
> > >
> > > Best regards,
> > > Viquar Khan
> > >
> > > On Tue, Sep 8, 2026 at 8:43 PM Greg Stein <gs...@gmail.com> wrote:
> > >
> > > > Oooh. It came out nicely. Thank you, Grok.
> > > >
> > > >
> > > >
> >
> https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
> > > >
> > > >
> > > > On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com> wrote:
> > > >
> > > > > Hey Viquar,
> > > > >
> > > > > Apologies for my absence. I've been focused on some RAI/LLMAO work
> > over
> > > > > the past few weeks, getting that project launched.
> > > > >
> > > > > Let's get your proposal into cwiki. I'll take your original
> proposal
> > and
> > > > > get it formatted and placed in cwiki. I saw that you've got further
> > > > updates
> > > > > after the discussion with Larry. We can figure that out as Step
> Two.
> > > > > Regardless of this process outcome, it would be helpful if you
> could
> > file
> > > > > an ICLA [1]. An easy step to grease any future wheels.
> > > > >
> > > > > I'll reply once I have a cwiki copy of your proposal.
> > > > >
> > > > > Cheers,
> > > > > -g
> > > > >
> > > > > [1] https://www.apache.org/licenses/contributor-agreements.html
> > > > >
> > > > >
> > > > > On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <
> vaquarjsr368@gmail.com>
> > > > > 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 <
> > vaquarjsr368@gmail.com>
> > > > >> 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 <
> > vaquarjsr368@gmail.com>
> > > > >> > 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 <lm...@apache.org>
> > > > 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 <
> > > > vaquarjsr368@gmail.com>
> > > > >> >>> 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 <
> > > > >> >>> > chandansinghsm@gmail.com>
> > > > >> >>> > wrote:
> > > > >> >>> >
> > > > >> >>> > > Please remove me from the general email list
> > > > >> >>> > >
> > > > >> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <
> lmccay@apache.org>
> > > > >> 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 <
> > lmccay@apache.org
> > > > >
> > > > >> >>> 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 <
> > > > >> >>> > justin@classsoftware.com
> > > > >> >>> > >> >
> > > > >> >>> > >> > 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: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
Hello everyone,
Quick follow-up on my previous note both items are now complete:
ICLA field. I have signed and sent the Individual Contributor License
Agreement to the ASF Secretary.
Knox mapping note published. I have written up the short document mapping
the Aegis governance steps onto the Apache Knox provider chain. It
describes how the two share the same shape (entry point → ordered policy
chain → backend), where Aegis can reuse Knox concepts, and a phased plan.
It is in the repo here:
https://github.com/vaquarkhan/aegis-mcp-gateway/blob/main/docs/NOTE-aegis-and-apache-knox.md
I would welcome your review of the note whenever you have a chance, and I
am happy to adjust it based on community feedback.
Best regards,
Viquar Khan
On Wed, Sep 9, 2026 at 3:55 AM Yu Xiao <xi...@apache.org> wrote:
> Hi,
>
> I'm somewhat interested in this project. It does something similar to
> the MCP plugin for Apache ShenYu.
> If you're looking for a mentor, feel free to add me.
>
> Best wishes!
>
> Yu Xiao
> ASF Member
> Apache ShenYu V.P.
>
> vaquar khan <va...@gmail.com> 于2026年9月9日周三 14:52写道：
> >
> > Hi Greg,
> >
> > Thank you for formatting and uploading the proposal to the cwiki; it
> looks
> > great!
> >
> > I want to acknowledge your message and confirm that I am currently
> working
> > on the next steps:
> >
> > - I have reviewed the published cwiki proposal and it looks awesome.
> > - I will file the Individual Contributor License Agreement (ICLA) as you
> > suggested.
> > - I am also working on a short document mapping the Aegis governance
> steps
> > onto the Knox provider chain will update in github repo documents for
> > review.
> >
> > I will follow up once these are completed. Thanks again for your
> guidance!
> >
> > Best regards,
> > Viquar Khan
> >
> > On Tue, Sep 8, 2026 at 8:43 PM Greg Stein <gs...@gmail.com> wrote:
> >
> > > Oooh. It came out nicely. Thank you, Grok.
> > >
> > >
> > >
> https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
> > >
> > >
> > > On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com> wrote:
> > >
> > > > Hey Viquar,
> > > >
> > > > Apologies for my absence. I've been focused on some RAI/LLMAO work
> over
> > > > the past few weeks, getting that project launched.
> > > >
> > > > Let's get your proposal into cwiki. I'll take your original proposal
> and
> > > > get it formatted and placed in cwiki. I saw that you've got further
> > > updates
> > > > after the discussion with Larry. We can figure that out as Step Two.
> > > > Regardless of this process outcome, it would be helpful if you could
> file
> > > > an ICLA [1]. An easy step to grease any future wheels.
> > > >
> > > > I'll reply once I have a cwiki copy of your proposal.
> > > >
> > > > Cheers,
> > > > -g
> > > >
> > > > [1] https://www.apache.org/licenses/contributor-agreements.html
> > > >
> > > >
> > > > On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <va...@gmail.com>
> > > > 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 <
> vaquarjsr368@gmail.com>
> > > >> 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 <
> vaquarjsr368@gmail.com>
> > > >> > 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 <lm...@apache.org>
> > > 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 <
> > > vaquarjsr368@gmail.com>
> > > >> >>> 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 <
> > > >> >>> > chandansinghsm@gmail.com>
> > > >> >>> > wrote:
> > > >> >>> >
> > > >> >>> > > Please remove me from the general email list
> > > >> >>> > >
> > > >> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org>
> > > >> 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 <
> lmccay@apache.org
> > > >
> > > >> >>> 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 <
> > > >> >>> > justin@classsoftware.com
> > > >> >>> > >> >
> > > >> >>> > >> > 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Yu Xiao <xi...@apache.org>.
Hi,
I'm somewhat interested in this project. It does something similar to
the MCP plugin for Apache ShenYu.
If you're looking for a mentor, feel free to add me.
Best wishes!
Yu Xiao
ASF Member
Apache ShenYu V.P.
vaquar khan <va...@gmail.com> 于2026年9月9日周三 14:52写道：
>
> Hi Greg,
>
> Thank you for formatting and uploading the proposal to the cwiki; it looks
> great!
>
> I want to acknowledge your message and confirm that I am currently working
> on the next steps:
>
> - I have reviewed the published cwiki proposal and it looks awesome.
> - I will file the Individual Contributor License Agreement (ICLA) as you
> suggested.
> - I am also working on a short document mapping the Aegis governance steps
> onto the Knox provider chain will update in github repo documents for
> review.
>
> I will follow up once these are completed. Thanks again for your guidance!
>
> Best regards,
> Viquar Khan
>
> On Tue, Sep 8, 2026 at 8:43 PM Greg Stein <gs...@gmail.com> wrote:
>
> > Oooh. It came out nicely. Thank you, Grok.
> >
> >
> > https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
> >
> >
> > On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com> wrote:
> >
> > > Hey Viquar,
> > >
> > > Apologies for my absence. I've been focused on some RAI/LLMAO work over
> > > the past few weeks, getting that project launched.
> > >
> > > Let's get your proposal into cwiki. I'll take your original proposal and
> > > get it formatted and placed in cwiki. I saw that you've got further
> > updates
> > > after the discussion with Larry. We can figure that out as Step Two.
> > > Regardless of this process outcome, it would be helpful if you could file
> > > an ICLA [1]. An easy step to grease any future wheels.
> > >
> > > I'll reply once I have a cwiki copy of your proposal.
> > >
> > > Cheers,
> > > -g
> > >
> > > [1] https://www.apache.org/licenses/contributor-agreements.html
> > >
> > >
> > > On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <va...@gmail.com>
> > > 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 <va...@gmail.com>
> > >> 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 <va...@gmail.com>
> > >> > 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 <lm...@apache.org>
> > 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 <
> > vaquarjsr368@gmail.com>
> > >> >>> 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 <
> > >> >>> > chandansinghsm@gmail.com>
> > >> >>> > wrote:
> > >> >>> >
> > >> >>> > > Please remove me from the general email list
> > >> >>> > >
> > >> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org>
> > >> 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 <lmccay@apache.org
> > >
> > >> >>> 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 <
> > >> >>> > justin@classsoftware.com
> > >> >>> > >> >
> > >> >>> > >> > 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
Hi Greg,
Thank you for formatting and uploading the proposal to the cwiki; it looks
great!
I want to acknowledge your message and confirm that I am currently working
on the next steps:
- I have reviewed the published cwiki proposal and it looks awesome.
- I will file the Individual Contributor License Agreement (ICLA) as you
suggested.
- I am also working on a short document mapping the Aegis governance steps
onto the Knox provider chain will update in github repo documents for
review.
I will follow up once these are completed. Thanks again for your guidance!
Best regards,
Viquar Khan
On Tue, Sep 8, 2026 at 8:43 PM Greg Stein <gs...@gmail.com> wrote:
> Oooh. It came out nicely. Thank you, Grok.
>
>
> https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
>
>
> On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com> wrote:
>
> > Hey Viquar,
> >
> > Apologies for my absence. I've been focused on some RAI/LLMAO work over
> > the past few weeks, getting that project launched.
> >
> > Let's get your proposal into cwiki. I'll take your original proposal and
> > get it formatted and placed in cwiki. I saw that you've got further
> updates
> > after the discussion with Larry. We can figure that out as Step Two.
> > Regardless of this process outcome, it would be helpful if you could file
> > an ICLA [1]. An easy step to grease any future wheels.
> >
> > I'll reply once I have a cwiki copy of your proposal.
> >
> > Cheers,
> > -g
> >
> > [1] https://www.apache.org/licenses/contributor-agreements.html
> >
> >
> > On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <va...@gmail.com>
> > 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 <va...@gmail.com>
> >> 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 <va...@gmail.com>
> >> > 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 <lm...@apache.org>
> 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 <
> vaquarjsr368@gmail.com>
> >> >>> 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 <
> >> >>> > chandansinghsm@gmail.com>
> >> >>> > wrote:
> >> >>> >
> >> >>> > > Please remove me from the general email list
> >> >>> > >
> >> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org>
> >> 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 <lmccay@apache.org
> >
> >> >>> 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 <
> >> >>> > justin@classsoftware.com
> >> >>> > >> >
> >> >>> > >> > 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
> >> >>> > >> >>
> >> >>> > >> >>
> >> >>> > >> >>
> >> >>> > >>
> >> >>> > >
> >> >>> >
> >> >>>
> >> >>
> >>
> >
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Greg Stein <gs...@gmail.com>.
Oooh. It came out nicely. Thank you, Grok.
https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/451974017/AegisProposal
On Tue, Sep 8, 2026 at 8:21 PM Greg Stein <gs...@gmail.com> wrote:
> Hey Viquar,
>
> Apologies for my absence. I've been focused on some RAI/LLMAO work over
> the past few weeks, getting that project launched.
>
> Let's get your proposal into cwiki. I'll take your original proposal and
> get it formatted and placed in cwiki. I saw that you've got further updates
> after the discussion with Larry. We can figure that out as Step Two.
> Regardless of this process outcome, it would be helpful if you could file
> an ICLA [1]. An easy step to grease any future wheels.
>
> I'll reply once I have a cwiki copy of your proposal.
>
> Cheers,
> -g
>
> [1] https://www.apache.org/licenses/contributor-agreements.html
>
>
> On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <va...@gmail.com>
> 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 <va...@gmail.com>
>> 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 <va...@gmail.com>
>> > 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 <lm...@apache.org> 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 <va...@gmail.com>
>> >>> 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 <
>> >>> > chandansinghsm@gmail.com>
>> >>> > wrote:
>> >>> >
>> >>> > > Please remove me from the general email list
>> >>> > >
>> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org>
>> 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 <lm...@apache.org>
>> >>> 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 <
>> >>> > justin@classsoftware.com
>> >>> > >> >
>> >>> > >> > 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
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >>
>> >>> > >
>> >>> >
>> >>>
>> >>
>>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Greg Stein <gs...@gmail.com>.
Hey Viquar,
Apologies for my absence. I've been focused on some RAI/LLMAO work over the
past few weeks, getting that project launched.
Let's get your proposal into cwiki. I'll take your original proposal and
get it formatted and placed in cwiki. I saw that you've got further updates
after the discussion with Larry. We can figure that out as Step Two.
Regardless of this process outcome, it would be helpful if you could file
an ICLA [1]. An easy step to grease any future wheels.
I'll reply once I have a cwiki copy of your proposal.
Cheers,
-g
[1] https://www.apache.org/licenses/contributor-agreements.html
On Thu, Aug 27, 2026 at 2:49 PM vaquar khan <va...@gmail.com> 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 <va...@gmail.com>
> 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 <va...@gmail.com>
> > 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 <lm...@apache.org> 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 <va...@gmail.com>
> >>> 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 <
> >>> > chandansinghsm@gmail.com>
> >>> > wrote:
> >>> >
> >>> > > Please remove me from the general email list
> >>> > >
> >>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org>
> >>> 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 <
> >>> > justin@classsoftware.com
> >>> > >> >
> >>> > >> > 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
> >>> > >> >>
> >>> > >> >>
> >>> > >> >>
> >>> > >>
> >>> > >
> >>> >
> >>>
> >>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
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 <va...@gmail.com> 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 <va...@gmail.com>
> 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 <lm...@apache.org> 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 <va...@gmail.com>
>>> 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 <
>>> > chandansinghsm@gmail.com>
>>> > wrote:
>>> >
>>> > > Please remove me from the general email list
>>> > >
>>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org>
>>> 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 <
>>> > justin@classsoftware.com
>>> > >> >
>>> > >> > 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
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> > >>
>>> > >
>>> >
>>>
>>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
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 <va...@gmail.com> 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 <lm...@apache.org> 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 <va...@gmail.com>
>> 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 <
>> > chandansinghsm@gmail.com>
>> > wrote:
>> >
>> > > Please remove me from the general email list
>> > >
>> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org>
>> 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 <
>> > justin@classsoftware.com
>> > >> >
>> > >> > 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
>> > >> >>
>> > >> >>
>> > >> >>
>> > >>
>> > >
>> >
>>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
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 <lm...@apache.org> 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 <va...@gmail.com>
> 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 <
> > chandansinghsm@gmail.com>
> > wrote:
> >
> > > Please remove me from the general email list
> > >
> > > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org>
> 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 <
> > justin@classsoftware.com
> > >> >
> > >> > 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
> > >> >>
> > >> >>
> > >> >>
> > >>
> > >
> >
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by larry mccay <lm...@apache.org>.
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 <va...@gmail.com> 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 <
> chandansinghsm@gmail.com>
> wrote:
>
> > Please remove me from the general email list
> >
> > On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org> 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 <
> justin@classsoftware.com
> >> >
> >> > 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
> >> >>
> >> >>
> >> >>
> >>
> >
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
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 <ch...@gmail.com>
wrote:
> Please remove me from the general email list
>
> On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org> 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 <justin@classsoftware.com
>> >
>> > 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
>> >>
>> >>
>> >>
>>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Chandan Singh S M <ch...@gmail.com>.
Please remove me from the general email list
On Thu, Aug 13, 2026, 07:34 larry mccay <lm...@apache.org> 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 <lm...@apache.org> 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 <ju...@classsoftware.com>
> > 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
> >>
> >>
> >>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by larry mccay <lm...@apache.org>.
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 <lm...@apache.org> 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 <ju...@classsoftware.com>
> 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
>>
>>
>>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by larry mccay <lm...@apache.org>.
> 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 <ju...@classsoftware.com>
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
>
>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Justin Mclean <ju...@classsoftware.com>.
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
leadership roles, limits, Officers (was: [DISCUSS] Aegis MCP Governance...)
Posted by Greg Stein <gs...@gmail.com>.
[ edited subject: this has nothing to do with the Aegis proposal ]
On Sat, Aug 8, 2026 at 7:15 PM S S <ss...@gmail.com>
wrote:
> Hi everyone,
>
> 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?
>
The premise is incorrect. There are no "leadership roles" within our
technical communities. It is a group of equals.
We do have a finite set of Officers of the Foundation (which is generally
orthogonal to the work done in our communities), but we generally don't
apply limits to the number of offices one can hold. People self-govern to
just a few maximum, based on their time and interests.
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?
There are no limits other than a volunteer's time they are willing to
contribute.
Cheers,
-g
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by S S <ss...@gmail.com>.
Hi everyone,
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? My goal is to make sure we leave room and give a fair chance to
other experienced contributors who are eager to step up and take on new
responsibilities in this project.
Looking forward to hearing your perspectives on this.
Thanks.
On Sun, 9 Aug 2026, 01:04 Greg Stein, <gs...@gmail.com> wrote:
> On Sat, Aug 8, 2026 at 4:48 PM larry mccay <lm...@apache.org> wrote:
> >...
>
> > Since I plan to delve more and more into agentic identity in the coming
> > days, I'd welcome getting involved here.
> > I'd be happy to be a Mentor and initial PPMC member, if you are
> interested
> > and if it helps this proposal.
> >
>
> Your participation would cement the required (3) PPMC members to vote on
> releases (Vaquar, myself, Larry).
>
> I'd like to get the proposal into cwiki and nicely formatted for easier
> reading by the Incubator community. 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.
>
> Cheers,
> -g
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Aug 8, 2026 at 4:48 PM larry mccay <lm...@apache.org> wrote:
>...
> Since I plan to delve more and more into agentic identity in the coming
> days, I'd welcome getting involved here.
> I'd be happy to be a Mentor and initial PPMC member, if you are interested
> and if it helps this proposal.
>
Your participation would cement the required (3) PPMC members to vote on
releases (Vaquar, myself, Larry).
I'd like to get the proposal into cwiki and nicely formatted for easier
reading by the Incubator community. 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.
Cheers,
-g
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by larry mccay <lm...@apache.org>.
I find this really interesting and think that there may actually be some
collaborative opportunities with Apache Knox.
I have been involved with Knox since inception and have been working on a
couple of your roadmap items already.
Background: I've been on Apache Knox since it entered the Incubator, and
Knox is the closest existing ASF analogue to what's proposed here — a Layer
7 security gateway that fronts Hadoop/data-ecosystem services with a
pluggable provider chain for authentication, federation, identity
assertion, authorization, and audit. I mention it not to suggest overlap is
a problem, but because a fair amount of what Aegis has on its roadmap is
ground Knox has already covered, and I'd potentially be able to help you
inherit those lessons than re-derive them.
We have been working on early alignment with some emerging agentic identity
standards and also being used as a Istio external authorizer in kubernetes
deployments where agentic identity is already a first class problem.
Some areas of our existing agentic related work:
- Token-exchange credential resolution. Knox implements RFC 8693 token
exchange with an actor-chain principal model, specifically so a delegated
call preserves who is acting on behalf of whom. This is the crux of agentic
identity: an agent invoking a tool is a delegation chain, and collapsing it
to a single impersonated principal loses the audit property you're trying
to guarantee. This is where most of my recent work has been.
- Externalized HA state. Knox has a JDBC-backed, shared token state with
an abstract persistence layer. Your single-replica constraint until shared
nonce/rate/audit stores exist is exactly the problem it solves
There's also adapter-surface overlap: 16 of the 33 engines in your list
already have Knox service definitions, including all four in-depth ones.
Whether that argues for reuse, for alignment on a shared identity layer, or
simply for coordination, it seems worth a conversation early rather than
after the SPI stabilizes. It may also be interested in considering Ranger
as an authorization provider
Since I plan to delve more and more into agentic identity in the coming
days, I'd welcome getting involved here.
I'd be happy to be a Mentor and initial PPMC member, if you are interested
and if it helps this proposal.
On Fri, Aug 7, 2026 at 2:03 PM PJ Fanning <fa...@apache.org> wrote:
> This project does seem like a good idea but a project with only 1
> committer is not usually regarded as a good fit for the Apache
> Incubator.
> Is there any chance that we could wait until there is a group of
> active committers?
> It takes at least 3 people to vote for releases and to invite extra
> PPMC members. There is a good chance that you can attract the extra
> numbers.
>
> On Fri, 7 Aug 2026 at 18:49, vaquar khan <va...@gmail.com> wrote:
> >
> > Hi Greg,
> >
> > Thank you, this genuinely means a lot. I am glad to accept your offer to
> > Champion the effort, and I appreciate you reaching out to line up
> mentors.
> > Coming from someone with your history and leadership at the Foundation,
> > that is exactly the kind of guidance I was hoping to find here.
> >
> > The repository is public so you and prospective mentors can read the code
> > before any vote: https://github.com/vaquarkhan/aegis-mcp-gateway. It
> builds
> > green on JDK 21 with the full test suite passing, and the
> > design-conformance matrix marks each claim 'Done' or 'Roadmap' so the
> > maturity line stays explicit. To be honest: four adapters (Flink, Kafka,
> > Spark, Iceberg) are in-depth, and the rest are deliberately thin. I am
> > completely open to trimming or quarantining the thin set if the community
> > would rather see a smaller, sharper initial contribution during the
> > bootstrap phase.
> >
> > A few responses to your points:
> >
> > *On your own MCP build*: I would be happy to help on a timeline that
> works
> > for both of us. The gateway core is engine-agnostic, and adapters plug in
> > through a small service provider interface, so bringing up a new MCP
> > surface is mostly mapping tool definitions and backend calls. The core
> > applies the shared governance chain uniformly: identity, scope, policy,
> > approvals, egress defense, rate limiting, redaction, and audit. The repo
> > has a getting-started guide, runnable examples, and an adapters guide to
> > start from.
> >
> > On the Foundation's existing MCP servers: I would welcome composing with
> > those rather than replacing them. Where an engine or server already ships
> > an MCP surface, the intent is for the gateway to sit in front of it for
> > governance rather than reimplement it. If you point me at the ones you
> have
> > in mind, I will take a look and share a short write-up on how they might
> > fit.
> >
> > Since you are stepping in as Champion, I would love to defer to your
> > experience on how best to proceed. Please let me know how you would like
> to
> > handle mentor recruitment, and what you need from me regarding next steps
> > for IP clearance, naming, or codebase scope before we eventually move
> > toward a formal vote.
> >
> > Thanks again for stepping in.
> >
> > Best regards,
> >
> > Viquar Khan
> >
> > https://www.linkedin.com/in/vaquar-khan-b695577/
> >
> >
> > On Thu, Aug 6, 2026 at 1:37 PM Greg Stein <gs...@gmail.com> wrote:
> >
> > > This is great stuff, Viquar! ... I'd be happy to Champion this effort
> > > through the Incubator. I already have a need to build an MCP from
> > > scratch/zero, and would like to use exactly this kind of framework to
> build
> > > that.
> > >
> > > We have a few existing MCP servers at the Foundation today, which
> might be
> > > able to leverage this framework, too.
> > >
> > > I'll poke some people to get some additional Mentors.
> > >
> > > My background: 28 years at Apache, current Director, past Chairman,
> initial
> > > Incubator member, current Apache RAI participant, past Infra,
> Subversion,
> > > HTTPD, and other projects.
> > >
> > > Cheers,
> > > -g
> > >
> > >
> > > On Tue, Aug 4, 2026 at 12:18 AM vaquar khan <va...@gmail.com>
> > > wrote:
> > >
> > > > Hello everyone,
> > > > I would like to propose a project called Aegis MCP Governance
> Gateway for
> > > > the Apache Incubator, and start a discussion. It is a working
> reference
> > > > implementation, and I am bringing it here mainly because it needs a
> > > > community rather than a single author, which I state plainly in the
> > > > proposal.
> > > > *In short: *when an AI agent needs to operate data systems like
> Flink,
> > > > Kafka, Spark, or Iceberg, it usually drives each engine control plane
> > > > directly or connects to a pile of separate MCP servers, each with
> its own
> > > > security posture, no shared audit, and no common policy. An MCP
> server
> > > that
> > > > can reach a control plane is a privileged client, so shipping one
> safely
> > > > means shipping an access-control product. Aegis puts one governed
> control
> > > > plane in front of all of those engines, so every agent action runs
> > > through
> > > > a single fail-closed chain of identity, scope, policy, approval for
> > > > destructive actions, egress and request-forgery defense, rate
> limiting,
> > > > output redaction, and a tamper-evident audit trail. Engines plug in
> > > through
> > > > a small service provider interface and contribute no policy.
> > > > Current state, stated honestly. There is a working Java 21 build: a
> > > gateway
> > > > core, four in-depth adapters (Flink, Kafka, Spark, Iceberg), thinner
> > > > adapters for other Apache systems, and a runnable distribution. It
> builds
> > > > cleanly with 309 tests passing across all modules. A published
> > > > design-conformance matrix maps every design claim to Done or Roadmap.
> > > > Several capabilities ship as roadmap items and are not sold as done:
> > > > externalized high-availability state, CIMD and SPIFFE identity, a
> full
> > > > Cedar runtime, vault-backed credentials, and an OpenTelemetry SDK
> bridge.
> > > > Parts of the code were developed with AI-assisted tools under my
> > > direction
> > > > and review, which I disclose up front for IP clearance.
> > > > *Biggest risk: *The project is currently a single contributor.
> Growing a
> > > > diverse, multi-organization community is the main reason I am
> bringing it
> > > > here. I am currently in active conversations with engineers in the
> > > > ecosystem and expect to add a few of them as initial committers in
> the
> > > next
> > > > few days, prior to a formal vote
> > > > What I am looking for now: a Champion (an ASF Member) and mentors
> (three
> > > or
> > > > more IPMC members), ideally including people from the Flink, Kafka,
> > > Spark,
> > > > or Iceberg communities. The full proposal follows, and the reference
> > > > implementation is at https://github.com/vaquarkhan/aegis-mcp-gateway.
> I
> > > > welcome feedback on scope, name (a name search is still to be run),
> > > risks,
> > > > and anything I have missed.
> > > > Thank you,
> > > > Viquar Khan
> > > > https://www.linkedin.com/in/vaquar-khan-b695577/
> > > >
> > > > Apache Incubator Proposal: Aegis MCP Governance Gateway
> > > > This is the proposal for entry into the Apache Incubator, written for
> > > > discussion on the Incubator general list. Aegis is a working
> codename; a
> > > > name search will be run and the ASF trademark process followed if the
> > > > project is accepted. The document follows the ASF Incubator proposal
> > > > template and states the maturity of the code honestly, including
> what is
> > > > implemented and what is deferred to the roadmap.
> > > > Field
> > > > Value
> > > > Proposal name
> > > > Aegis MCP Governance Gateway (codename)
> > > > Proposed short name
> > > > aegis (subject to name search)
> > > > Proposal date
> > > > to be set at submission
> > > > Sponsor
> > > > Apache Incubator PMC
> > > > Champion
> > > > to be identified (ASF Member)
> > > > Mentors
> > > > to be recruited (three or more IPMC members)
> > > > Initial code
> > > > Java 21 multi-module reference implementation, 36 Maven modules, 309
> > > tests
> > > > passing
> > > > Reference repository
> > > > https://github.com/vaquarkhan/aegis-mcp-gateway (private for now,
> access
> > > > on
> > > > request)
> > > > License
> > > > Apache License 2.0
> > > > Discussion list
> > > > general at incubator.apache.org
> > > > Abstract
> > > > Aegis MCP Governance Gateway is a vendor-neutral, secure-by-default
> Model
> > > > Context Protocol (MCP) gateway that puts one governed, auditable
> control
> > > > plane in front of many Apache data and streaming engines, so an AI
> agent
> > > > never talks to Flink, Kafka, Spark, or Iceberg directly. Every agent
> > > action
> > > > passes one fail-closed governance chain: secure-by-default tool
> exposure,
> > > > per-caller authentication and scope, a policy decision point,
> approval
> > > for
> > > > destructive operations, egress and server-side request forgery
> defense,
> > > > rate limiting, circuit breaking, prompt-injection screening, output
> > > > bounding and redaction, tool-catalog integrity, and a tamper-evident
> > > > hash-chained audit trail. Engines plug in through a small service
> > > provider
> > > > interface and contribute only tool definitions and backend calls.
> > > > Proposal
> > > > We propose to develop, under Apache governance, a Layer 7 policy MCP
> > > > gateway plus a family of engine adapters. A proxy forwards bytes and
> a
> > > > router dispatches by capability, but neither is a trust boundary. A
> > > gateway
> > > > is: it knows the tool, the principal, the budget, and the policy for
> > > every
> > > > call, and it can deny, redact, gate, and record. The gateway core is
> > > > stateless at the protocol edge so it can scale behind an ordinary
> load
> > > > balancer once shared governance state is externalized, and it is
> designed
> > > > to align with OAuth 2.1, SPIFFE, SLSA, OpenTelemetry, and the NIST AI
> > > Risk
> > > > Management Framework and ISO/IEC 42001.
> > > > The initial contribution is a working Java reference implementation:
> a
> > > > reusable gateway core, four in-depth engine adapters (Flink, Kafka,
> > > Spark,
> > > > Iceberg), and a further set of thinner adapters for the wider Apache
> data
> > > > platform. During incubation the priorities are community building, IP
> > > > clearance, and promoting the roadmap items to full implementations.
> > > > Background
> > > > The Model Context Protocol has become a common way for AI agents to
> reach
> > > > tools and data. As organizations connect agents to distributed Apache
> > > data
> > > > estates, an agent that needs Flink, Kafka, Spark, and Iceberg must
> either
> > > > drive each engine control plane directly or connect to a sprawl of
> > > > independent, mostly read-only MCP servers, each with its own security
> > > > posture, no shared audit, and no unified policy.
> > > > An MCP server that can reach a control plane (a JobManager REST API,
> a
> > > > Kafka AdminClient, a SQL gateway, an Iceberg catalog) is a privileged
> > > > client. Shipping one safely is effectively shipping an access-control
> > > > product: authentication, authorization, approval for destructive
> actions,
> > > > redaction of secrets and personal data, rate and cost limits, and
> > > forensic
> > > > audit. Many existing options lack these controls and carry
> > > > single-maintainer sustainability risk. A single governed gateway,
> > > developed
> > > > in the open under neutral governance, gives the ecosystem a shared
> > > standard
> > > > for how agents operate Apache systems safely.
> > > > Rationale
> > > > A single governed gateway resolves the problems of the decentralized
> > > > approach:
> > > >
> > > > - Security. One place enforces identity, authorization, approval,
> > > > redaction, egress, and audit, instead of each server
> reimplementing or
> > > > omitting them.
> > > > - Maintainability. Adding an engine is a small adapter, not a new
> > > > security model. There is one chain to review and harden, so the
> > > security
> > > > review surface stays flat as engines are added.
> > > > - Governance. One control plane for policy, budget, and
> provenance,
> > > with
> > > > a stable deny taxonomy so operators can alert on codes such as
> > > > POLICY_DENIED or APPROVAL_REQUIRED across every engine with one
> rule.
> > > >
> > > > Doing this under Apache governance keeps it neutral across vendors
> and
> > > > engines rather than leaving agent access to fragmented single-vendor
> > > > servers.
> > > > Initial goals
> > > >
> > > > 1. Establish the project and practice the Apache Way:
> transparency,
> > > > consensus, meritocracy, and community over code.
> > > > 2. Complete IP clearance for the existing code and land it under
> > > > Apache-2.0 with correct LICENSE and NOTICE files.
> > > > 3. Publish and stabilize the adapter service provider interface so
> > > > per-engine adapters are small, reviewable contributions.
> > > > 4. Promote the roadmap items to full implementations: externalized
> > > > high-availability state, CIMD and SPIFFE identity, a full Cedar
> > > runtime,
> > > > vault-backed credential exchange, and an OpenTelemetry SDK bridge.
> > > > 5. Produce the first Apache source releases and grow a diverse,
> > > > multi-organization contributor base.
> > > >
> > > > Current status
> > > > Aegis is a new codebase with a working multi-module reference
> > > > implementation. It is not yet a community. The design, threat model,
> > > > low-level design, and standards research are complete and public. The
> > > code
> > > > builds green and is tested. A published design-conformance matrix
> maps
> > > > every design claim to Done or Roadmap, so the maturity line is
> explicit.
> > > > Verified build and test state
> > > >
> > > > - 36 Maven modules: a gateway core, adapters for 33 Apache engines
> > > (four
> > > > in-depth today, Flink, Kafka, Spark, and Iceberg, and 29 thinner
> > > > integrations covering Cassandra, HBase, Hive, Pulsar, Airflow,
> NiFi,
> > > > Druid,
> > > > Pinot, Doris, Impala, Calcite, Hudi, Paimon, Kudu, Ignite,
> BookKeeper,
> > > > Ozone, Hadoop, ZooKeeper, Solr, Superset, Arrow Flight, Beam,
> Storm,
> > > > Flume,
> > > > ActiveMQ, CouchDB, Ranger, and Atlas), and a shaded runnable
> > > > distribution.
> > > > These are engine adapters the gateway supports, which is distinct
> from
> > > > external adopters.
> > > > - Builds with JDK 21 and runs on JDK 17 or newer with Maven 3.9 or
> > > > newer.
> > > > - 309 unit and integration tests across all modules, all passing,
> zero
> > > > failures and zero errors on a clean build.
> > > >
> > > > Implemented in 0.1.0
> > > >
> > > > - The governance chain with ordered steps and first-denial-wins
> > > > semantics.
> > > > - Identity: shared bearer and a hashed multi-caller token file
> with
> > > > per-caller scope, and an OAuth 2.1 resource-server mode with JWKS
> > > > validation. Constant-time secret comparison and fail-closed
> startup
> > > > validation.
> > > > - Approvals: HMAC-SHA256 signed, TTL-bounded, single-use,
> > > > tool-and-scope-bound tokens with replay rejection.
> > > > - Policy: a builtin decision point, a live fail-closed OPA HTTP
> > > decision
> > > > point, and a Cedar-style deny-file or HTTP delegate.
> > > > - Per-caller outbound credential pass-through so a downstream
> engine
> > > can
> > > > see a per-caller Authorization value when one was bound at
> admission.
> > > > - Egress and server-side request forgery defense: allow list plus
> > > > unconditional deny of cloud metadata and non-routable ranges,
> > > including
> > > > numeric IP encodings and resolved addresses, with redirects
> disabled
> > > on
> > > > outbound clients.
> > > > - Rate limiting, circuit breaking, per-tool timeout, read-only SQL
> > > > guard, identifier validation, output bounding, and
> > > data-loss-prevention
> > > > redaction.
> > > > - Tool-catalog integrity with durable pins and a fail-closed
> switch, a
> > > > tamper-evident hash-chained audit, Prometheus metrics, and
> > > GenAI-shaped
> > > > span log lines.
> > > > - Two transports: stdio and authenticated Streamable HTTP with
> TLS,
> > > plus
> > > > health, readiness, and metrics endpoints. A CycloneDX software
> bill of
> > > > materials is produced at build time.
> > > >
> > > > Deferred to the roadmap (honestly labeled, not sold as implemented)
> > > >
> > > > - CIMD and SPIFFE authentication modes (they refuse to start
> today).
> > > > - A full Cedar policy runtime, and vault-backed or token-exchange
> > > > credential resolution.
> > > > - Externalized high-availability state (shared nonce, rate, and
> audit
> > > > stores). Until then, run a single replica; multi-replica replay
> > > > protection
> > > > and rate limits require the shared store.
> > > > - The MCP Tasks extension for long-running jobs, an OpenTelemetry
> SDK
> > > > bridge, a full Merkle and signature-based reconciliation proof,
> and
> > > true
> > > > semantic routing and caching.
> > > >
> > > > These are tracked in the roadmap and the design-conformance matrix
> that
> > > > ship with the code.
> > > > Meritocracy, community, core developers, alignment
> > > > The project will operate meritocratically from day one, with
> technical
> > > > decisions on the dev list and committership earned through
> contribution.
> > > > The community is currently centered on the initial author, Viquar
> Khan,
> > > who
> > > > has around 23 years in software, has worked in the open since 2013,
> and
> > > has
> > > > contributed to Apache Spark, Apache Iceberg, Apache Kafka, and other
> > > > open-source projects. The author also maintains MCP-related
> open-source
> > > > packages that have together been downloaded on the order of half a
> > > million
> > > > times, so there is an existing user base to draw contributors from.
> > > Growing
> > > > a committer base across the Flink, Kafka, Spark, and Iceberg
> communities
> > > > and across employers is the primary goal of incubation. Aegis
> consumes
> > > > public engine interfaces only and does not fork or modify any engine
> > > core.
> > > > Known risks
> > > > Orphaned products
> > > > Low to moderate. Agentic access to data systems is a growing need
> and the
> > > > governance gap is real, so demand is unlikely to vanish. The initial
> > > author
> > > > has maintained open-source projects since 2013 rather than abandoning
> > > them,
> > > > and the MCP-related packages already have a real user base, which
> lowers
> > > > the abandonment risk. Mitigation: build a multi-organization
> community,
> > > > keep the core small and standards aligned, and keep adapters
> independent
> > > so
> > > > the project survives the departure of any single contributor.
> > > > Inexperience with open source
> > > > Low. This is not the situation here. The initial author has about 23
> > > years
> > > > in software, has worked in open source since 2013, and has
> contributed to
> > > > Apache Spark, Apache Iceberg, Apache Kafka, and other projects, so
> the
> > > > norms of public development, code review, and releases are familiar.
> > > > Mentors will still help with the ASF-specific mechanics of voting,
> board
> > > > reports, and IP clearance, which are process details rather than a
> gap in
> > > > open-source experience.
> > > > Homogenous developers
> > > > This is the real risk and we state it plainly: the podling has one
> > > > committer today. However, we are in active discussions with potential
> > > > co-committers and expect to formally add them to this proposal in the
> > > > coming days. What further reduces this risk is that the author is
> > > already
> > > > embedded in the exact communities this project draws from (Spark,
> > > Iceberg,
> > > > Kafka) and has an existing user base for the MCP packages, so there
> is a
> > > > concrete pool to recruit from rather than a cold start. Mitigation:
> > > recruit
> > > > committers from more than one organization before graduation, shape
> the
> > > > adapter contract so per-engine contributions are natural, and use
> > > > good-first-issue and adapter-sized work to onboard newcomers.
> Growing the
> > > > committer base is the main reason we are here.
> > > > Reliance on salaried developers
> > > > Low current reliance; the work to date is largely independent. The
> > > project
> > > > will attract contributors with varied motivations and employers so no
> > > > single company can stall it.
> > > > Relationships with other Apache products
> > > > Aegis consumes the public interfaces of Flink, Kafka, Spark,
> Iceberg, and
> > > > other Apache data systems and does not fork or modify them. We will
> > > > coordinate on the relevant dev lists and will not duplicate or
> compete
> > > with
> > > > an engine that ships its own MCP surface; where an engine has one,
> Aegis
> > > > composes with it. Aegis is not proposed for any engine core.
> > > > Excessive fascination with the Apache brand
> > > > The project seeks Apache governance for its community model and
> > > neutrality,
> > > > not for the brand. Until and unless accepted, it uses a neutral name
> and
> > > > does not use the Apache marks or the feather. The breadth of engine
> > > > adapters reflects a common governance surface, not an attempt to
> claim
> > > the
> > > > ecosystem; only four adapters are in-depth today and the rest are
> > > > explicitly thin.
> > > > Documentation
> > > > Public documentation exists and will be maintained in the
> repository: an
> > > > end-to-end design with architecture decision records, a low-level
> design
> > > > with architecture, sequence, and state diagrams, a threat and
> governance
> > > > model, a design-conformance matrix, standards research, and
> operations
> > > and
> > > > adapter guides.
> > > > Initial source
> > > > The initial source is the Java multi-module gateway described above,
> > > > currently in a private repository at
> > > > https://github.com/vaquarkhan/aegis-mcp-gateway under the initial
> > > author.
> > > > Access is available on request to anyone reviewing this proposal,
> and the
> > > > author will make it public before the vote if the community prefers
> to
> > > read
> > > > the code first. It includes the gateway core, the four in-depth
> adapters,
> > > > the thinner adapters, the shaded distribution, runnable examples,
> and the
> > > > documentation set. On acceptance it will be donated under a Software
> > > Grant
> > > > and made public.
> > > > Source and intellectual property submission plan
> > > > The initial author will submit the code under a Software Grant
> Agreement
> > > > and complete IP clearance early in incubation, with ICLAs from every
> > > > committer. Every source file will carry the standard Apache-2.0
> header
> > > with
> > > > correct LICENSE and NOTICE files; any premature ASF-ownership wording
> > > will
> > > > be corrected to the standard header at donation time.
> > > > Transparency on tooling: parts of the codebase were developed with
> > > > AI-assisted coding tools under the author's direction and review. The
> > > > author asserts authorship and the right to contribute the work, and
> will
> > > > confirm provenance and authorship during IP clearance so the grant is
> > > > clean. We raise this proactively so the IPMC can review it rather
> than
> > > > discover it.
> > > > External dependencies
> > > > Runtime dependencies are Apache-2.0 or compatible, including the MCP
> Java
> > > > SDK, a servlet container for the HTTP transport, SLF4J, Logback, and
> > > Nimbus
> > > > for JOSE and JWT, with JUnit for tests. Per-engine adapters add that
> > > engine
> > > > to the official client, for example the Kafka clients library. A full
> > > > dependency review and a CycloneDX software bill of materials are
> > > produced.
> > > > No GPL or ASF category X dependency is introduced into the core.
> > > > Cryptography
> > > > Aegis uses standard, library-based cryptography: HMAC-SHA256 for
> approval
> > > > tokens, TLS for the HTTP transport, and JSON Web Token validation for
> > > > OAuth. Signature-based integrity is an optional gate. The project
> will
> > > > comply with ASF export notification requirements.
> > > > Required resources
> > > > Mailing lists
> > > >
> > > > - private@aegis.incubator.apache.org
> > > > - dev@aegis.incubator.apache.org
> > > > - commits@aegis.incubator.apache.org
> > > >
> > > > Source control
> > > >
> > > > - A Git repository under the ASF (gitbox with a GitHub mirror).
> > > >
> > > > Issue tracking
> > > >
> > > > - ASF Jira or GitHub issues per current ASF practice.
> > > >
> > > > Other
> > > >
> > > > - Website and wiki space, and continuous integration through ASF
> > > > infrastructure.
> > > >
> > > > Initial committers
> > > >
> > > > - Viquar Khan *(Note: We are in active conversations with
> potential
> > > > contributors and expect to add a few additional initial committers
> > > here
> > > > in
> > > > the next few days before moving to a formal vote.)*
> > > >
> > > > - To be recruited before and during incubation: committers from
> the
> > > > Flink, Kafka, Spark, and Iceberg communities and from additional
> > > > organizations. Adapter-sized work is designed to make these
> > > > contributions
> > > > natural.
> > > >
> > > > Affiliations
> > > > To be completed as committers are confirmed. Diversity of
> affiliation is
> > > an
> > > > explicit goal; the current single-affiliation status is the main risk
> > > being
> > > > addressed.
> > > > Sponsors
> > > > Champion
> > > > To be identified. An ASF Member Champion will help finalize this
> > > proposal,
> > > > recruit mentors, and shepherd the discussion and vote on the
> Incubator
> > > > general list.
> > > > Nominated mentors
> > > > Three or more IPMC members to be recruited, ideally including
> > > participants
> > > > from the Flink, Kafka, and Iceberg communities.
> > > > Sponsoring entity
> > > > The Apache Incubator PMC.
> > > > Roadmap during incubation
> > > > Phase
> > > > Focus
> > > > Bootstrap
> > > > IP clearance, name search, infra, initial committers, first dev-list
> > > > decisions
> > > > 0.2
> > > > Externalized HA state, vault-backed credentials, OAuth multi-issuer,
> OTel
> > > > SDK bridge, supply-chain CI (enforcer, CVE scan, signing)
> > > > 0.3
> > > > CIMD and SPIFFE identity, full Cedar runtime, MCP Tasks,
> signature-based
> > > > reconciliation proof, semantic routing and caching
> > > > Graduation readiness
> > > > Diverse community, cadence of Apache releases, healthy governance
> > > > References
> > > >
> > > > - Apache Incubator proposal guide:
> > > > https://incubator.apache.org/guides/proposal.html
> > > > - Apache Incubator Cookbook:
> https://incubator.apache.org/cookbook/
> > > > - The Apache Way: https://www.apache.org/theapacheway/
> > > > - Model Context Protocol: https://modelcontextprotocol.io/
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by PJ Fanning <fa...@apache.org>.
This project does seem like a good idea but a project with only 1
committer is not usually regarded as a good fit for the Apache
Incubator.
Is there any chance that we could wait until there is a group of
active committers?
It takes at least 3 people to vote for releases and to invite extra
PPMC members. There is a good chance that you can attract the extra
numbers.
On Fri, 7 Aug 2026 at 18:49, vaquar khan <va...@gmail.com> wrote:
>
> Hi Greg,
>
> Thank you, this genuinely means a lot. I am glad to accept your offer to
> Champion the effort, and I appreciate you reaching out to line up mentors.
> Coming from someone with your history and leadership at the Foundation,
> that is exactly the kind of guidance I was hoping to find here.
>
> The repository is public so you and prospective mentors can read the code
> before any vote: https://github.com/vaquarkhan/aegis-mcp-gateway. It builds
> green on JDK 21 with the full test suite passing, and the
> design-conformance matrix marks each claim 'Done' or 'Roadmap' so the
> maturity line stays explicit. To be honest: four adapters (Flink, Kafka,
> Spark, Iceberg) are in-depth, and the rest are deliberately thin. I am
> completely open to trimming or quarantining the thin set if the community
> would rather see a smaller, sharper initial contribution during the
> bootstrap phase.
>
> A few responses to your points:
>
> *On your own MCP build*: I would be happy to help on a timeline that works
> for both of us. The gateway core is engine-agnostic, and adapters plug in
> through a small service provider interface, so bringing up a new MCP
> surface is mostly mapping tool definitions and backend calls. The core
> applies the shared governance chain uniformly: identity, scope, policy,
> approvals, egress defense, rate limiting, redaction, and audit. The repo
> has a getting-started guide, runnable examples, and an adapters guide to
> start from.
>
> On the Foundation's existing MCP servers: I would welcome composing with
> those rather than replacing them. Where an engine or server already ships
> an MCP surface, the intent is for the gateway to sit in front of it for
> governance rather than reimplement it. If you point me at the ones you have
> in mind, I will take a look and share a short write-up on how they might
> fit.
>
> Since you are stepping in as Champion, I would love to defer to your
> experience on how best to proceed. Please let me know how you would like to
> handle mentor recruitment, and what you need from me regarding next steps
> for IP clearance, naming, or codebase scope before we eventually move
> toward a formal vote.
>
> Thanks again for stepping in.
>
> Best regards,
>
> Viquar Khan
>
> https://www.linkedin.com/in/vaquar-khan-b695577/
>
>
> On Thu, Aug 6, 2026 at 1:37 PM Greg Stein <gs...@gmail.com> wrote:
>
> > This is great stuff, Viquar! ... I'd be happy to Champion this effort
> > through the Incubator. I already have a need to build an MCP from
> > scratch/zero, and would like to use exactly this kind of framework to build
> > that.
> >
> > We have a few existing MCP servers at the Foundation today, which might be
> > able to leverage this framework, too.
> >
> > I'll poke some people to get some additional Mentors.
> >
> > My background: 28 years at Apache, current Director, past Chairman, initial
> > Incubator member, current Apache RAI participant, past Infra, Subversion,
> > HTTPD, and other projects.
> >
> > Cheers,
> > -g
> >
> >
> > On Tue, Aug 4, 2026 at 12:18 AM vaquar khan <va...@gmail.com>
> > wrote:
> >
> > > Hello everyone,
> > > I would like to propose a project called Aegis MCP Governance Gateway for
> > > the Apache Incubator, and start a discussion. It is a working reference
> > > implementation, and I am bringing it here mainly because it needs a
> > > community rather than a single author, which I state plainly in the
> > > proposal.
> > > *In short: *when an AI agent needs to operate data systems like Flink,
> > > Kafka, Spark, or Iceberg, it usually drives each engine control plane
> > > directly or connects to a pile of separate MCP servers, each with its own
> > > security posture, no shared audit, and no common policy. An MCP server
> > that
> > > can reach a control plane is a privileged client, so shipping one safely
> > > means shipping an access-control product. Aegis puts one governed control
> > > plane in front of all of those engines, so every agent action runs
> > through
> > > a single fail-closed chain of identity, scope, policy, approval for
> > > destructive actions, egress and request-forgery defense, rate limiting,
> > > output redaction, and a tamper-evident audit trail. Engines plug in
> > through
> > > a small service provider interface and contribute no policy.
> > > Current state, stated honestly. There is a working Java 21 build: a
> > gateway
> > > core, four in-depth adapters (Flink, Kafka, Spark, Iceberg), thinner
> > > adapters for other Apache systems, and a runnable distribution. It builds
> > > cleanly with 309 tests passing across all modules. A published
> > > design-conformance matrix maps every design claim to Done or Roadmap.
> > > Several capabilities ship as roadmap items and are not sold as done:
> > > externalized high-availability state, CIMD and SPIFFE identity, a full
> > > Cedar runtime, vault-backed credentials, and an OpenTelemetry SDK bridge.
> > > Parts of the code were developed with AI-assisted tools under my
> > direction
> > > and review, which I disclose up front for IP clearance.
> > > *Biggest risk: *The project is currently a single contributor. Growing a
> > > diverse, multi-organization community is the main reason I am bringing it
> > > here. I am currently in active conversations with engineers in the
> > > ecosystem and expect to add a few of them as initial committers in the
> > next
> > > few days, prior to a formal vote
> > > What I am looking for now: a Champion (an ASF Member) and mentors (three
> > or
> > > more IPMC members), ideally including people from the Flink, Kafka,
> > Spark,
> > > or Iceberg communities. The full proposal follows, and the reference
> > > implementation is at https://github.com/vaquarkhan/aegis-mcp-gateway. I
> > > welcome feedback on scope, name (a name search is still to be run),
> > risks,
> > > and anything I have missed.
> > > Thank you,
> > > Viquar Khan
> > > https://www.linkedin.com/in/vaquar-khan-b695577/
> > >
> > > Apache Incubator Proposal: Aegis MCP Governance Gateway
> > > This is the proposal for entry into the Apache Incubator, written for
> > > discussion on the Incubator general list. Aegis is a working codename; a
> > > name search will be run and the ASF trademark process followed if the
> > > project is accepted. The document follows the ASF Incubator proposal
> > > template and states the maturity of the code honestly, including what is
> > > implemented and what is deferred to the roadmap.
> > > Field
> > > Value
> > > Proposal name
> > > Aegis MCP Governance Gateway (codename)
> > > Proposed short name
> > > aegis (subject to name search)
> > > Proposal date
> > > to be set at submission
> > > Sponsor
> > > Apache Incubator PMC
> > > Champion
> > > to be identified (ASF Member)
> > > Mentors
> > > to be recruited (three or more IPMC members)
> > > Initial code
> > > Java 21 multi-module reference implementation, 36 Maven modules, 309
> > tests
> > > passing
> > > Reference repository
> > > https://github.com/vaquarkhan/aegis-mcp-gateway (private for now, access
> > > on
> > > request)
> > > License
> > > Apache License 2.0
> > > Discussion list
> > > general at incubator.apache.org
> > > Abstract
> > > Aegis MCP Governance Gateway is a vendor-neutral, secure-by-default Model
> > > Context Protocol (MCP) gateway that puts one governed, auditable control
> > > plane in front of many Apache data and streaming engines, so an AI agent
> > > never talks to Flink, Kafka, Spark, or Iceberg directly. Every agent
> > action
> > > passes one fail-closed governance chain: secure-by-default tool exposure,
> > > per-caller authentication and scope, a policy decision point, approval
> > for
> > > destructive operations, egress and server-side request forgery defense,
> > > rate limiting, circuit breaking, prompt-injection screening, output
> > > bounding and redaction, tool-catalog integrity, and a tamper-evident
> > > hash-chained audit trail. Engines plug in through a small service
> > provider
> > > interface and contribute only tool definitions and backend calls.
> > > Proposal
> > > We propose to develop, under Apache governance, a Layer 7 policy MCP
> > > gateway plus a family of engine adapters. A proxy forwards bytes and a
> > > router dispatches by capability, but neither is a trust boundary. A
> > gateway
> > > is: it knows the tool, the principal, the budget, and the policy for
> > every
> > > call, and it can deny, redact, gate, and record. The gateway core is
> > > stateless at the protocol edge so it can scale behind an ordinary load
> > > balancer once shared governance state is externalized, and it is designed
> > > to align with OAuth 2.1, SPIFFE, SLSA, OpenTelemetry, and the NIST AI
> > Risk
> > > Management Framework and ISO/IEC 42001.
> > > The initial contribution is a working Java reference implementation: a
> > > reusable gateway core, four in-depth engine adapters (Flink, Kafka,
> > Spark,
> > > Iceberg), and a further set of thinner adapters for the wider Apache data
> > > platform. During incubation the priorities are community building, IP
> > > clearance, and promoting the roadmap items to full implementations.
> > > Background
> > > The Model Context Protocol has become a common way for AI agents to reach
> > > tools and data. As organizations connect agents to distributed Apache
> > data
> > > estates, an agent that needs Flink, Kafka, Spark, and Iceberg must either
> > > drive each engine control plane directly or connect to a sprawl of
> > > independent, mostly read-only MCP servers, each with its own security
> > > posture, no shared audit, and no unified policy.
> > > An MCP server that can reach a control plane (a JobManager REST API, a
> > > Kafka AdminClient, a SQL gateway, an Iceberg catalog) is a privileged
> > > client. Shipping one safely is effectively shipping an access-control
> > > product: authentication, authorization, approval for destructive actions,
> > > redaction of secrets and personal data, rate and cost limits, and
> > forensic
> > > audit. Many existing options lack these controls and carry
> > > single-maintainer sustainability risk. A single governed gateway,
> > developed
> > > in the open under neutral governance, gives the ecosystem a shared
> > standard
> > > for how agents operate Apache systems safely.
> > > Rationale
> > > A single governed gateway resolves the problems of the decentralized
> > > approach:
> > >
> > > - Security. One place enforces identity, authorization, approval,
> > > redaction, egress, and audit, instead of each server reimplementing or
> > > omitting them.
> > > - Maintainability. Adding an engine is a small adapter, not a new
> > > security model. There is one chain to review and harden, so the
> > security
> > > review surface stays flat as engines are added.
> > > - Governance. One control plane for policy, budget, and provenance,
> > with
> > > a stable deny taxonomy so operators can alert on codes such as
> > > POLICY_DENIED or APPROVAL_REQUIRED across every engine with one rule.
> > >
> > > Doing this under Apache governance keeps it neutral across vendors and
> > > engines rather than leaving agent access to fragmented single-vendor
> > > servers.
> > > Initial goals
> > >
> > > 1. Establish the project and practice the Apache Way: transparency,
> > > consensus, meritocracy, and community over code.
> > > 2. Complete IP clearance for the existing code and land it under
> > > Apache-2.0 with correct LICENSE and NOTICE files.
> > > 3. Publish and stabilize the adapter service provider interface so
> > > per-engine adapters are small, reviewable contributions.
> > > 4. Promote the roadmap items to full implementations: externalized
> > > high-availability state, CIMD and SPIFFE identity, a full Cedar
> > runtime,
> > > vault-backed credential exchange, and an OpenTelemetry SDK bridge.
> > > 5. Produce the first Apache source releases and grow a diverse,
> > > multi-organization contributor base.
> > >
> > > Current status
> > > Aegis is a new codebase with a working multi-module reference
> > > implementation. It is not yet a community. The design, threat model,
> > > low-level design, and standards research are complete and public. The
> > code
> > > builds green and is tested. A published design-conformance matrix maps
> > > every design claim to Done or Roadmap, so the maturity line is explicit.
> > > Verified build and test state
> > >
> > > - 36 Maven modules: a gateway core, adapters for 33 Apache engines
> > (four
> > > in-depth today, Flink, Kafka, Spark, and Iceberg, and 29 thinner
> > > integrations covering Cassandra, HBase, Hive, Pulsar, Airflow, NiFi,
> > > Druid,
> > > Pinot, Doris, Impala, Calcite, Hudi, Paimon, Kudu, Ignite, BookKeeper,
> > > Ozone, Hadoop, ZooKeeper, Solr, Superset, Arrow Flight, Beam, Storm,
> > > Flume,
> > > ActiveMQ, CouchDB, Ranger, and Atlas), and a shaded runnable
> > > distribution.
> > > These are engine adapters the gateway supports, which is distinct from
> > > external adopters.
> > > - Builds with JDK 21 and runs on JDK 17 or newer with Maven 3.9 or
> > > newer.
> > > - 309 unit and integration tests across all modules, all passing, zero
> > > failures and zero errors on a clean build.
> > >
> > > Implemented in 0.1.0
> > >
> > > - The governance chain with ordered steps and first-denial-wins
> > > semantics.
> > > - Identity: shared bearer and a hashed multi-caller token file with
> > > per-caller scope, and an OAuth 2.1 resource-server mode with JWKS
> > > validation. Constant-time secret comparison and fail-closed startup
> > > validation.
> > > - Approvals: HMAC-SHA256 signed, TTL-bounded, single-use,
> > > tool-and-scope-bound tokens with replay rejection.
> > > - Policy: a builtin decision point, a live fail-closed OPA HTTP
> > decision
> > > point, and a Cedar-style deny-file or HTTP delegate.
> > > - Per-caller outbound credential pass-through so a downstream engine
> > can
> > > see a per-caller Authorization value when one was bound at admission.
> > > - Egress and server-side request forgery defense: allow list plus
> > > unconditional deny of cloud metadata and non-routable ranges,
> > including
> > > numeric IP encodings and resolved addresses, with redirects disabled
> > on
> > > outbound clients.
> > > - Rate limiting, circuit breaking, per-tool timeout, read-only SQL
> > > guard, identifier validation, output bounding, and
> > data-loss-prevention
> > > redaction.
> > > - Tool-catalog integrity with durable pins and a fail-closed switch, a
> > > tamper-evident hash-chained audit, Prometheus metrics, and
> > GenAI-shaped
> > > span log lines.
> > > - Two transports: stdio and authenticated Streamable HTTP with TLS,
> > plus
> > > health, readiness, and metrics endpoints. A CycloneDX software bill of
> > > materials is produced at build time.
> > >
> > > Deferred to the roadmap (honestly labeled, not sold as implemented)
> > >
> > > - CIMD and SPIFFE authentication modes (they refuse to start today).
> > > - A full Cedar policy runtime, and vault-backed or token-exchange
> > > credential resolution.
> > > - Externalized high-availability state (shared nonce, rate, and audit
> > > stores). Until then, run a single replica; multi-replica replay
> > > protection
> > > and rate limits require the shared store.
> > > - The MCP Tasks extension for long-running jobs, an OpenTelemetry SDK
> > > bridge, a full Merkle and signature-based reconciliation proof, and
> > true
> > > semantic routing and caching.
> > >
> > > These are tracked in the roadmap and the design-conformance matrix that
> > > ship with the code.
> > > Meritocracy, community, core developers, alignment
> > > The project will operate meritocratically from day one, with technical
> > > decisions on the dev list and committership earned through contribution.
> > > The community is currently centered on the initial author, Viquar Khan,
> > who
> > > has around 23 years in software, has worked in the open since 2013, and
> > has
> > > contributed to Apache Spark, Apache Iceberg, Apache Kafka, and other
> > > open-source projects. The author also maintains MCP-related open-source
> > > packages that have together been downloaded on the order of half a
> > million
> > > times, so there is an existing user base to draw contributors from.
> > Growing
> > > a committer base across the Flink, Kafka, Spark, and Iceberg communities
> > > and across employers is the primary goal of incubation. Aegis consumes
> > > public engine interfaces only and does not fork or modify any engine
> > core.
> > > Known risks
> > > Orphaned products
> > > Low to moderate. Agentic access to data systems is a growing need and the
> > > governance gap is real, so demand is unlikely to vanish. The initial
> > author
> > > has maintained open-source projects since 2013 rather than abandoning
> > them,
> > > and the MCP-related packages already have a real user base, which lowers
> > > the abandonment risk. Mitigation: build a multi-organization community,
> > > keep the core small and standards aligned, and keep adapters independent
> > so
> > > the project survives the departure of any single contributor.
> > > Inexperience with open source
> > > Low. This is not the situation here. The initial author has about 23
> > years
> > > in software, has worked in open source since 2013, and has contributed to
> > > Apache Spark, Apache Iceberg, Apache Kafka, and other projects, so the
> > > norms of public development, code review, and releases are familiar.
> > > Mentors will still help with the ASF-specific mechanics of voting, board
> > > reports, and IP clearance, which are process details rather than a gap in
> > > open-source experience.
> > > Homogenous developers
> > > This is the real risk and we state it plainly: the podling has one
> > > committer today. However, we are in active discussions with potential
> > > co-committers and expect to formally add them to this proposal in the
> > > coming days. What further reduces this risk is that the author is
> > already
> > > embedded in the exact communities this project draws from (Spark,
> > Iceberg,
> > > Kafka) and has an existing user base for the MCP packages, so there is a
> > > concrete pool to recruit from rather than a cold start. Mitigation:
> > recruit
> > > committers from more than one organization before graduation, shape the
> > > adapter contract so per-engine contributions are natural, and use
> > > good-first-issue and adapter-sized work to onboard newcomers. Growing the
> > > committer base is the main reason we are here.
> > > Reliance on salaried developers
> > > Low current reliance; the work to date is largely independent. The
> > project
> > > will attract contributors with varied motivations and employers so no
> > > single company can stall it.
> > > Relationships with other Apache products
> > > Aegis consumes the public interfaces of Flink, Kafka, Spark, Iceberg, and
> > > other Apache data systems and does not fork or modify them. We will
> > > coordinate on the relevant dev lists and will not duplicate or compete
> > with
> > > an engine that ships its own MCP surface; where an engine has one, Aegis
> > > composes with it. Aegis is not proposed for any engine core.
> > > Excessive fascination with the Apache brand
> > > The project seeks Apache governance for its community model and
> > neutrality,
> > > not for the brand. Until and unless accepted, it uses a neutral name and
> > > does not use the Apache marks or the feather. The breadth of engine
> > > adapters reflects a common governance surface, not an attempt to claim
> > the
> > > ecosystem; only four adapters are in-depth today and the rest are
> > > explicitly thin.
> > > Documentation
> > > Public documentation exists and will be maintained in the repository: an
> > > end-to-end design with architecture decision records, a low-level design
> > > with architecture, sequence, and state diagrams, a threat and governance
> > > model, a design-conformance matrix, standards research, and operations
> > and
> > > adapter guides.
> > > Initial source
> > > The initial source is the Java multi-module gateway described above,
> > > currently in a private repository at
> > > https://github.com/vaquarkhan/aegis-mcp-gateway under the initial
> > author.
> > > Access is available on request to anyone reviewing this proposal, and the
> > > author will make it public before the vote if the community prefers to
> > read
> > > the code first. It includes the gateway core, the four in-depth adapters,
> > > the thinner adapters, the shaded distribution, runnable examples, and the
> > > documentation set. On acceptance it will be donated under a Software
> > Grant
> > > and made public.
> > > Source and intellectual property submission plan
> > > The initial author will submit the code under a Software Grant Agreement
> > > and complete IP clearance early in incubation, with ICLAs from every
> > > committer. Every source file will carry the standard Apache-2.0 header
> > with
> > > correct LICENSE and NOTICE files; any premature ASF-ownership wording
> > will
> > > be corrected to the standard header at donation time.
> > > Transparency on tooling: parts of the codebase were developed with
> > > AI-assisted coding tools under the author's direction and review. The
> > > author asserts authorship and the right to contribute the work, and will
> > > confirm provenance and authorship during IP clearance so the grant is
> > > clean. We raise this proactively so the IPMC can review it rather than
> > > discover it.
> > > External dependencies
> > > Runtime dependencies are Apache-2.0 or compatible, including the MCP Java
> > > SDK, a servlet container for the HTTP transport, SLF4J, Logback, and
> > Nimbus
> > > for JOSE and JWT, with JUnit for tests. Per-engine adapters add that
> > engine
> > > to the official client, for example the Kafka clients library. A full
> > > dependency review and a CycloneDX software bill of materials are
> > produced.
> > > No GPL or ASF category X dependency is introduced into the core.
> > > Cryptography
> > > Aegis uses standard, library-based cryptography: HMAC-SHA256 for approval
> > > tokens, TLS for the HTTP transport, and JSON Web Token validation for
> > > OAuth. Signature-based integrity is an optional gate. The project will
> > > comply with ASF export notification requirements.
> > > Required resources
> > > Mailing lists
> > >
> > > - private@aegis.incubator.apache.org
> > > - dev@aegis.incubator.apache.org
> > > - commits@aegis.incubator.apache.org
> > >
> > > Source control
> > >
> > > - A Git repository under the ASF (gitbox with a GitHub mirror).
> > >
> > > Issue tracking
> > >
> > > - ASF Jira or GitHub issues per current ASF practice.
> > >
> > > Other
> > >
> > > - Website and wiki space, and continuous integration through ASF
> > > infrastructure.
> > >
> > > Initial committers
> > >
> > > - Viquar Khan *(Note: We are in active conversations with potential
> > > contributors and expect to add a few additional initial committers
> > here
> > > in
> > > the next few days before moving to a formal vote.)*
> > >
> > > - To be recruited before and during incubation: committers from the
> > > Flink, Kafka, Spark, and Iceberg communities and from additional
> > > organizations. Adapter-sized work is designed to make these
> > > contributions
> > > natural.
> > >
> > > Affiliations
> > > To be completed as committers are confirmed. Diversity of affiliation is
> > an
> > > explicit goal; the current single-affiliation status is the main risk
> > being
> > > addressed.
> > > Sponsors
> > > Champion
> > > To be identified. An ASF Member Champion will help finalize this
> > proposal,
> > > recruit mentors, and shepherd the discussion and vote on the Incubator
> > > general list.
> > > Nominated mentors
> > > Three or more IPMC members to be recruited, ideally including
> > participants
> > > from the Flink, Kafka, and Iceberg communities.
> > > Sponsoring entity
> > > The Apache Incubator PMC.
> > > Roadmap during incubation
> > > Phase
> > > Focus
> > > Bootstrap
> > > IP clearance, name search, infra, initial committers, first dev-list
> > > decisions
> > > 0.2
> > > Externalized HA state, vault-backed credentials, OAuth multi-issuer, OTel
> > > SDK bridge, supply-chain CI (enforcer, CVE scan, signing)
> > > 0.3
> > > CIMD and SPIFFE identity, full Cedar runtime, MCP Tasks, signature-based
> > > reconciliation proof, semantic routing and caching
> > > Graduation readiness
> > > Diverse community, cadence of Apache releases, healthy governance
> > > References
> > >
> > > - Apache Incubator proposal guide:
> > > https://incubator.apache.org/guides/proposal.html
> > > - Apache Incubator Cookbook: https://incubator.apache.org/cookbook/
> > > - The Apache Way: https://www.apache.org/theapacheway/
> > > - Model Context Protocol: https://modelcontextprotocol.io/
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by vaquar khan <va...@gmail.com>.
Hi Greg,
Thank you, this genuinely means a lot. I am glad to accept your offer to
Champion the effort, and I appreciate you reaching out to line up mentors.
Coming from someone with your history and leadership at the Foundation,
that is exactly the kind of guidance I was hoping to find here.
The repository is public so you and prospective mentors can read the code
before any vote: https://github.com/vaquarkhan/aegis-mcp-gateway. It builds
green on JDK 21 with the full test suite passing, and the
design-conformance matrix marks each claim 'Done' or 'Roadmap' so the
maturity line stays explicit. To be honest: four adapters (Flink, Kafka,
Spark, Iceberg) are in-depth, and the rest are deliberately thin. I am
completely open to trimming or quarantining the thin set if the community
would rather see a smaller, sharper initial contribution during the
bootstrap phase.
A few responses to your points:
*On your own MCP build*: I would be happy to help on a timeline that works
for both of us. The gateway core is engine-agnostic, and adapters plug in
through a small service provider interface, so bringing up a new MCP
surface is mostly mapping tool definitions and backend calls. The core
applies the shared governance chain uniformly: identity, scope, policy,
approvals, egress defense, rate limiting, redaction, and audit. The repo
has a getting-started guide, runnable examples, and an adapters guide to
start from.
On the Foundation's existing MCP servers: I would welcome composing with
those rather than replacing them. Where an engine or server already ships
an MCP surface, the intent is for the gateway to sit in front of it for
governance rather than reimplement it. If you point me at the ones you have
in mind, I will take a look and share a short write-up on how they might
fit.
Since you are stepping in as Champion, I would love to defer to your
experience on how best to proceed. Please let me know how you would like to
handle mentor recruitment, and what you need from me regarding next steps
for IP clearance, naming, or codebase scope before we eventually move
toward a formal vote.
Thanks again for stepping in.
Best regards,
Viquar Khan
https://www.linkedin.com/in/vaquar-khan-b695577/
On Thu, Aug 6, 2026 at 1:37 PM Greg Stein <gs...@gmail.com> wrote:
> This is great stuff, Viquar! ... I'd be happy to Champion this effort
> through the Incubator. I already have a need to build an MCP from
> scratch/zero, and would like to use exactly this kind of framework to build
> that.
>
> We have a few existing MCP servers at the Foundation today, which might be
> able to leverage this framework, too.
>
> I'll poke some people to get some additional Mentors.
>
> My background: 28 years at Apache, current Director, past Chairman, initial
> Incubator member, current Apache RAI participant, past Infra, Subversion,
> HTTPD, and other projects.
>
> Cheers,
> -g
>
>
> On Tue, Aug 4, 2026 at 12:18 AM vaquar khan <va...@gmail.com>
> wrote:
>
> > Hello everyone,
> > I would like to propose a project called Aegis MCP Governance Gateway for
> > the Apache Incubator, and start a discussion. It is a working reference
> > implementation, and I am bringing it here mainly because it needs a
> > community rather than a single author, which I state plainly in the
> > proposal.
> > *In short: *when an AI agent needs to operate data systems like Flink,
> > Kafka, Spark, or Iceberg, it usually drives each engine control plane
> > directly or connects to a pile of separate MCP servers, each with its own
> > security posture, no shared audit, and no common policy. An MCP server
> that
> > can reach a control plane is a privileged client, so shipping one safely
> > means shipping an access-control product. Aegis puts one governed control
> > plane in front of all of those engines, so every agent action runs
> through
> > a single fail-closed chain of identity, scope, policy, approval for
> > destructive actions, egress and request-forgery defense, rate limiting,
> > output redaction, and a tamper-evident audit trail. Engines plug in
> through
> > a small service provider interface and contribute no policy.
> > Current state, stated honestly. There is a working Java 21 build: a
> gateway
> > core, four in-depth adapters (Flink, Kafka, Spark, Iceberg), thinner
> > adapters for other Apache systems, and a runnable distribution. It builds
> > cleanly with 309 tests passing across all modules. A published
> > design-conformance matrix maps every design claim to Done or Roadmap.
> > Several capabilities ship as roadmap items and are not sold as done:
> > externalized high-availability state, CIMD and SPIFFE identity, a full
> > Cedar runtime, vault-backed credentials, and an OpenTelemetry SDK bridge.
> > Parts of the code were developed with AI-assisted tools under my
> direction
> > and review, which I disclose up front for IP clearance.
> > *Biggest risk: *The project is currently a single contributor. Growing a
> > diverse, multi-organization community is the main reason I am bringing it
> > here. I am currently in active conversations with engineers in the
> > ecosystem and expect to add a few of them as initial committers in the
> next
> > few days, prior to a formal vote
> > What I am looking for now: a Champion (an ASF Member) and mentors (three
> or
> > more IPMC members), ideally including people from the Flink, Kafka,
> Spark,
> > or Iceberg communities. The full proposal follows, and the reference
> > implementation is at https://github.com/vaquarkhan/aegis-mcp-gateway. I
> > welcome feedback on scope, name (a name search is still to be run),
> risks,
> > and anything I have missed.
> > Thank you,
> > Viquar Khan
> > https://www.linkedin.com/in/vaquar-khan-b695577/
> >
> > Apache Incubator Proposal: Aegis MCP Governance Gateway
> > This is the proposal for entry into the Apache Incubator, written for
> > discussion on the Incubator general list. Aegis is a working codename; a
> > name search will be run and the ASF trademark process followed if the
> > project is accepted. The document follows the ASF Incubator proposal
> > template and states the maturity of the code honestly, including what is
> > implemented and what is deferred to the roadmap.
> > Field
> > Value
> > Proposal name
> > Aegis MCP Governance Gateway (codename)
> > Proposed short name
> > aegis (subject to name search)
> > Proposal date
> > to be set at submission
> > Sponsor
> > Apache Incubator PMC
> > Champion
> > to be identified (ASF Member)
> > Mentors
> > to be recruited (three or more IPMC members)
> > Initial code
> > Java 21 multi-module reference implementation, 36 Maven modules, 309
> tests
> > passing
> > Reference repository
> > https://github.com/vaquarkhan/aegis-mcp-gateway (private for now, access
> > on
> > request)
> > License
> > Apache License 2.0
> > Discussion list
> > general at incubator.apache.org
> > Abstract
> > Aegis MCP Governance Gateway is a vendor-neutral, secure-by-default Model
> > Context Protocol (MCP) gateway that puts one governed, auditable control
> > plane in front of many Apache data and streaming engines, so an AI agent
> > never talks to Flink, Kafka, Spark, or Iceberg directly. Every agent
> action
> > passes one fail-closed governance chain: secure-by-default tool exposure,
> > per-caller authentication and scope, a policy decision point, approval
> for
> > destructive operations, egress and server-side request forgery defense,
> > rate limiting, circuit breaking, prompt-injection screening, output
> > bounding and redaction, tool-catalog integrity, and a tamper-evident
> > hash-chained audit trail. Engines plug in through a small service
> provider
> > interface and contribute only tool definitions and backend calls.
> > Proposal
> > We propose to develop, under Apache governance, a Layer 7 policy MCP
> > gateway plus a family of engine adapters. A proxy forwards bytes and a
> > router dispatches by capability, but neither is a trust boundary. A
> gateway
> > is: it knows the tool, the principal, the budget, and the policy for
> every
> > call, and it can deny, redact, gate, and record. The gateway core is
> > stateless at the protocol edge so it can scale behind an ordinary load
> > balancer once shared governance state is externalized, and it is designed
> > to align with OAuth 2.1, SPIFFE, SLSA, OpenTelemetry, and the NIST AI
> Risk
> > Management Framework and ISO/IEC 42001.
> > The initial contribution is a working Java reference implementation: a
> > reusable gateway core, four in-depth engine adapters (Flink, Kafka,
> Spark,
> > Iceberg), and a further set of thinner adapters for the wider Apache data
> > platform. During incubation the priorities are community building, IP
> > clearance, and promoting the roadmap items to full implementations.
> > Background
> > The Model Context Protocol has become a common way for AI agents to reach
> > tools and data. As organizations connect agents to distributed Apache
> data
> > estates, an agent that needs Flink, Kafka, Spark, and Iceberg must either
> > drive each engine control plane directly or connect to a sprawl of
> > independent, mostly read-only MCP servers, each with its own security
> > posture, no shared audit, and no unified policy.
> > An MCP server that can reach a control plane (a JobManager REST API, a
> > Kafka AdminClient, a SQL gateway, an Iceberg catalog) is a privileged
> > client. Shipping one safely is effectively shipping an access-control
> > product: authentication, authorization, approval for destructive actions,
> > redaction of secrets and personal data, rate and cost limits, and
> forensic
> > audit. Many existing options lack these controls and carry
> > single-maintainer sustainability risk. A single governed gateway,
> developed
> > in the open under neutral governance, gives the ecosystem a shared
> standard
> > for how agents operate Apache systems safely.
> > Rationale
> > A single governed gateway resolves the problems of the decentralized
> > approach:
> >
> > - Security. One place enforces identity, authorization, approval,
> > redaction, egress, and audit, instead of each server reimplementing or
> > omitting them.
> > - Maintainability. Adding an engine is a small adapter, not a new
> > security model. There is one chain to review and harden, so the
> security
> > review surface stays flat as engines are added.
> > - Governance. One control plane for policy, budget, and provenance,
> with
> > a stable deny taxonomy so operators can alert on codes such as
> > POLICY_DENIED or APPROVAL_REQUIRED across every engine with one rule.
> >
> > Doing this under Apache governance keeps it neutral across vendors and
> > engines rather than leaving agent access to fragmented single-vendor
> > servers.
> > Initial goals
> >
> > 1. Establish the project and practice the Apache Way: transparency,
> > consensus, meritocracy, and community over code.
> > 2. Complete IP clearance for the existing code and land it under
> > Apache-2.0 with correct LICENSE and NOTICE files.
> > 3. Publish and stabilize the adapter service provider interface so
> > per-engine adapters are small, reviewable contributions.
> > 4. Promote the roadmap items to full implementations: externalized
> > high-availability state, CIMD and SPIFFE identity, a full Cedar
> runtime,
> > vault-backed credential exchange, and an OpenTelemetry SDK bridge.
> > 5. Produce the first Apache source releases and grow a diverse,
> > multi-organization contributor base.
> >
> > Current status
> > Aegis is a new codebase with a working multi-module reference
> > implementation. It is not yet a community. The design, threat model,
> > low-level design, and standards research are complete and public. The
> code
> > builds green and is tested. A published design-conformance matrix maps
> > every design claim to Done or Roadmap, so the maturity line is explicit.
> > Verified build and test state
> >
> > - 36 Maven modules: a gateway core, adapters for 33 Apache engines
> (four
> > in-depth today, Flink, Kafka, Spark, and Iceberg, and 29 thinner
> > integrations covering Cassandra, HBase, Hive, Pulsar, Airflow, NiFi,
> > Druid,
> > Pinot, Doris, Impala, Calcite, Hudi, Paimon, Kudu, Ignite, BookKeeper,
> > Ozone, Hadoop, ZooKeeper, Solr, Superset, Arrow Flight, Beam, Storm,
> > Flume,
> > ActiveMQ, CouchDB, Ranger, and Atlas), and a shaded runnable
> > distribution.
> > These are engine adapters the gateway supports, which is distinct from
> > external adopters.
> > - Builds with JDK 21 and runs on JDK 17 or newer with Maven 3.9 or
> > newer.
> > - 309 unit and integration tests across all modules, all passing, zero
> > failures and zero errors on a clean build.
> >
> > Implemented in 0.1.0
> >
> > - The governance chain with ordered steps and first-denial-wins
> > semantics.
> > - Identity: shared bearer and a hashed multi-caller token file with
> > per-caller scope, and an OAuth 2.1 resource-server mode with JWKS
> > validation. Constant-time secret comparison and fail-closed startup
> > validation.
> > - Approvals: HMAC-SHA256 signed, TTL-bounded, single-use,
> > tool-and-scope-bound tokens with replay rejection.
> > - Policy: a builtin decision point, a live fail-closed OPA HTTP
> decision
> > point, and a Cedar-style deny-file or HTTP delegate.
> > - Per-caller outbound credential pass-through so a downstream engine
> can
> > see a per-caller Authorization value when one was bound at admission.
> > - Egress and server-side request forgery defense: allow list plus
> > unconditional deny of cloud metadata and non-routable ranges,
> including
> > numeric IP encodings and resolved addresses, with redirects disabled
> on
> > outbound clients.
> > - Rate limiting, circuit breaking, per-tool timeout, read-only SQL
> > guard, identifier validation, output bounding, and
> data-loss-prevention
> > redaction.
> > - Tool-catalog integrity with durable pins and a fail-closed switch, a
> > tamper-evident hash-chained audit, Prometheus metrics, and
> GenAI-shaped
> > span log lines.
> > - Two transports: stdio and authenticated Streamable HTTP with TLS,
> plus
> > health, readiness, and metrics endpoints. A CycloneDX software bill of
> > materials is produced at build time.
> >
> > Deferred to the roadmap (honestly labeled, not sold as implemented)
> >
> > - CIMD and SPIFFE authentication modes (they refuse to start today).
> > - A full Cedar policy runtime, and vault-backed or token-exchange
> > credential resolution.
> > - Externalized high-availability state (shared nonce, rate, and audit
> > stores). Until then, run a single replica; multi-replica replay
> > protection
> > and rate limits require the shared store.
> > - The MCP Tasks extension for long-running jobs, an OpenTelemetry SDK
> > bridge, a full Merkle and signature-based reconciliation proof, and
> true
> > semantic routing and caching.
> >
> > These are tracked in the roadmap and the design-conformance matrix that
> > ship with the code.
> > Meritocracy, community, core developers, alignment
> > The project will operate meritocratically from day one, with technical
> > decisions on the dev list and committership earned through contribution.
> > The community is currently centered on the initial author, Viquar Khan,
> who
> > has around 23 years in software, has worked in the open since 2013, and
> has
> > contributed to Apache Spark, Apache Iceberg, Apache Kafka, and other
> > open-source projects. The author also maintains MCP-related open-source
> > packages that have together been downloaded on the order of half a
> million
> > times, so there is an existing user base to draw contributors from.
> Growing
> > a committer base across the Flink, Kafka, Spark, and Iceberg communities
> > and across employers is the primary goal of incubation. Aegis consumes
> > public engine interfaces only and does not fork or modify any engine
> core.
> > Known risks
> > Orphaned products
> > Low to moderate. Agentic access to data systems is a growing need and the
> > governance gap is real, so demand is unlikely to vanish. The initial
> author
> > has maintained open-source projects since 2013 rather than abandoning
> them,
> > and the MCP-related packages already have a real user base, which lowers
> > the abandonment risk. Mitigation: build a multi-organization community,
> > keep the core small and standards aligned, and keep adapters independent
> so
> > the project survives the departure of any single contributor.
> > Inexperience with open source
> > Low. This is not the situation here. The initial author has about 23
> years
> > in software, has worked in open source since 2013, and has contributed to
> > Apache Spark, Apache Iceberg, Apache Kafka, and other projects, so the
> > norms of public development, code review, and releases are familiar.
> > Mentors will still help with the ASF-specific mechanics of voting, board
> > reports, and IP clearance, which are process details rather than a gap in
> > open-source experience.
> > Homogenous developers
> > This is the real risk and we state it plainly: the podling has one
> > committer today. However, we are in active discussions with potential
> > co-committers and expect to formally add them to this proposal in the
> > coming days. What further reduces this risk is that the author is
> already
> > embedded in the exact communities this project draws from (Spark,
> Iceberg,
> > Kafka) and has an existing user base for the MCP packages, so there is a
> > concrete pool to recruit from rather than a cold start. Mitigation:
> recruit
> > committers from more than one organization before graduation, shape the
> > adapter contract so per-engine contributions are natural, and use
> > good-first-issue and adapter-sized work to onboard newcomers. Growing the
> > committer base is the main reason we are here.
> > Reliance on salaried developers
> > Low current reliance; the work to date is largely independent. The
> project
> > will attract contributors with varied motivations and employers so no
> > single company can stall it.
> > Relationships with other Apache products
> > Aegis consumes the public interfaces of Flink, Kafka, Spark, Iceberg, and
> > other Apache data systems and does not fork or modify them. We will
> > coordinate on the relevant dev lists and will not duplicate or compete
> with
> > an engine that ships its own MCP surface; where an engine has one, Aegis
> > composes with it. Aegis is not proposed for any engine core.
> > Excessive fascination with the Apache brand
> > The project seeks Apache governance for its community model and
> neutrality,
> > not for the brand. Until and unless accepted, it uses a neutral name and
> > does not use the Apache marks or the feather. The breadth of engine
> > adapters reflects a common governance surface, not an attempt to claim
> the
> > ecosystem; only four adapters are in-depth today and the rest are
> > explicitly thin.
> > Documentation
> > Public documentation exists and will be maintained in the repository: an
> > end-to-end design with architecture decision records, a low-level design
> > with architecture, sequence, and state diagrams, a threat and governance
> > model, a design-conformance matrix, standards research, and operations
> and
> > adapter guides.
> > Initial source
> > The initial source is the Java multi-module gateway described above,
> > currently in a private repository at
> > https://github.com/vaquarkhan/aegis-mcp-gateway under the initial
> author.
> > Access is available on request to anyone reviewing this proposal, and the
> > author will make it public before the vote if the community prefers to
> read
> > the code first. It includes the gateway core, the four in-depth adapters,
> > the thinner adapters, the shaded distribution, runnable examples, and the
> > documentation set. On acceptance it will be donated under a Software
> Grant
> > and made public.
> > Source and intellectual property submission plan
> > The initial author will submit the code under a Software Grant Agreement
> > and complete IP clearance early in incubation, with ICLAs from every
> > committer. Every source file will carry the standard Apache-2.0 header
> with
> > correct LICENSE and NOTICE files; any premature ASF-ownership wording
> will
> > be corrected to the standard header at donation time.
> > Transparency on tooling: parts of the codebase were developed with
> > AI-assisted coding tools under the author's direction and review. The
> > author asserts authorship and the right to contribute the work, and will
> > confirm provenance and authorship during IP clearance so the grant is
> > clean. We raise this proactively so the IPMC can review it rather than
> > discover it.
> > External dependencies
> > Runtime dependencies are Apache-2.0 or compatible, including the MCP Java
> > SDK, a servlet container for the HTTP transport, SLF4J, Logback, and
> Nimbus
> > for JOSE and JWT, with JUnit for tests. Per-engine adapters add that
> engine
> > to the official client, for example the Kafka clients library. A full
> > dependency review and a CycloneDX software bill of materials are
> produced.
> > No GPL or ASF category X dependency is introduced into the core.
> > Cryptography
> > Aegis uses standard, library-based cryptography: HMAC-SHA256 for approval
> > tokens, TLS for the HTTP transport, and JSON Web Token validation for
> > OAuth. Signature-based integrity is an optional gate. The project will
> > comply with ASF export notification requirements.
> > Required resources
> > Mailing lists
> >
> > - private@aegis.incubator.apache.org
> > - dev@aegis.incubator.apache.org
> > - commits@aegis.incubator.apache.org
> >
> > Source control
> >
> > - A Git repository under the ASF (gitbox with a GitHub mirror).
> >
> > Issue tracking
> >
> > - ASF Jira or GitHub issues per current ASF practice.
> >
> > Other
> >
> > - Website and wiki space, and continuous integration through ASF
> > infrastructure.
> >
> > Initial committers
> >
> > - Viquar Khan *(Note: We are in active conversations with potential
> > contributors and expect to add a few additional initial committers
> here
> > in
> > the next few days before moving to a formal vote.)*
> >
> > - To be recruited before and during incubation: committers from the
> > Flink, Kafka, Spark, and Iceberg communities and from additional
> > organizations. Adapter-sized work is designed to make these
> > contributions
> > natural.
> >
> > Affiliations
> > To be completed as committers are confirmed. Diversity of affiliation is
> an
> > explicit goal; the current single-affiliation status is the main risk
> being
> > addressed.
> > Sponsors
> > Champion
> > To be identified. An ASF Member Champion will help finalize this
> proposal,
> > recruit mentors, and shepherd the discussion and vote on the Incubator
> > general list.
> > Nominated mentors
> > Three or more IPMC members to be recruited, ideally including
> participants
> > from the Flink, Kafka, and Iceberg communities.
> > Sponsoring entity
> > The Apache Incubator PMC.
> > Roadmap during incubation
> > Phase
> > Focus
> > Bootstrap
> > IP clearance, name search, infra, initial committers, first dev-list
> > decisions
> > 0.2
> > Externalized HA state, vault-backed credentials, OAuth multi-issuer, OTel
> > SDK bridge, supply-chain CI (enforcer, CVE scan, signing)
> > 0.3
> > CIMD and SPIFFE identity, full Cedar runtime, MCP Tasks, signature-based
> > reconciliation proof, semantic routing and caching
> > Graduation readiness
> > Diverse community, cadence of Apache releases, healthy governance
> > References
> >
> > - Apache Incubator proposal guide:
> > https://incubator.apache.org/guides/proposal.html
> > - Apache Incubator Cookbook: https://incubator.apache.org/cookbook/
> > - The Apache Way: https://www.apache.org/theapacheway/
> > - Model Context Protocol: https://modelcontextprotocol.io/
> >
>
Re: [DISCUSS] Aegis MCP Governance Gateway Incubator Proposal
Posted by Greg Stein <gs...@gmail.com>.
This is great stuff, Viquar! ... I'd be happy to Champion this effort
through the Incubator. I already have a need to build an MCP from
scratch/zero, and would like to use exactly this kind of framework to build
that.
We have a few existing MCP servers at the Foundation today, which might be
able to leverage this framework, too.
I'll poke some people to get some additional Mentors.
My background: 28 years at Apache, current Director, past Chairman, initial
Incubator member, current Apache RAI participant, past Infra, Subversion,
HTTPD, and other projects.
Cheers,
-g
On Tue, Aug 4, 2026 at 12:18 AM vaquar khan <va...@gmail.com> wrote:
> Hello everyone,
> I would like to propose a project called Aegis MCP Governance Gateway for
> the Apache Incubator, and start a discussion. It is a working reference
> implementation, and I am bringing it here mainly because it needs a
> community rather than a single author, which I state plainly in the
> proposal.
> *In short: *when an AI agent needs to operate data systems like Flink,
> Kafka, Spark, or Iceberg, it usually drives each engine control plane
> directly or connects to a pile of separate MCP servers, each with its own
> security posture, no shared audit, and no common policy. An MCP server that
> can reach a control plane is a privileged client, so shipping one safely
> means shipping an access-control product. Aegis puts one governed control
> plane in front of all of those engines, so every agent action runs through
> a single fail-closed chain of identity, scope, policy, approval for
> destructive actions, egress and request-forgery defense, rate limiting,
> output redaction, and a tamper-evident audit trail. Engines plug in through
> a small service provider interface and contribute no policy.
> Current state, stated honestly. There is a working Java 21 build: a gateway
> core, four in-depth adapters (Flink, Kafka, Spark, Iceberg), thinner
> adapters for other Apache systems, and a runnable distribution. It builds
> cleanly with 309 tests passing across all modules. A published
> design-conformance matrix maps every design claim to Done or Roadmap.
> Several capabilities ship as roadmap items and are not sold as done:
> externalized high-availability state, CIMD and SPIFFE identity, a full
> Cedar runtime, vault-backed credentials, and an OpenTelemetry SDK bridge.
> Parts of the code were developed with AI-assisted tools under my direction
> and review, which I disclose up front for IP clearance.
> *Biggest risk: *The project is currently a single contributor. Growing a
> diverse, multi-organization community is the main reason I am bringing it
> here. I am currently in active conversations with engineers in the
> ecosystem and expect to add a few of them as initial committers in the next
> few days, prior to a formal vote
> What I am looking for now: a Champion (an ASF Member) and mentors (three or
> more IPMC members), ideally including people from the Flink, Kafka, Spark,
> or Iceberg communities. The full proposal follows, and the reference
> implementation is at https://github.com/vaquarkhan/aegis-mcp-gateway. I
> welcome feedback on scope, name (a name search is still to be run), risks,
> and anything I have missed.
> Thank you,
> Viquar Khan
> https://www.linkedin.com/in/vaquar-khan-b695577/
>
> Apache Incubator Proposal: Aegis MCP Governance Gateway
> This is the proposal for entry into the Apache Incubator, written for
> discussion on the Incubator general list. Aegis is a working codename; a
> name search will be run and the ASF trademark process followed if the
> project is accepted. The document follows the ASF Incubator proposal
> template and states the maturity of the code honestly, including what is
> implemented and what is deferred to the roadmap.
> Field
> Value
> Proposal name
> Aegis MCP Governance Gateway (codename)
> Proposed short name
> aegis (subject to name search)
> Proposal date
> to be set at submission
> Sponsor
> Apache Incubator PMC
> Champion
> to be identified (ASF Member)
> Mentors
> to be recruited (three or more IPMC members)
> Initial code
> Java 21 multi-module reference implementation, 36 Maven modules, 309 tests
> passing
> Reference repository
> https://github.com/vaquarkhan/aegis-mcp-gateway (private for now, access
> on
> request)
> License
> Apache License 2.0
> Discussion list
> general at incubator.apache.org
> Abstract
> Aegis MCP Governance Gateway is a vendor-neutral, secure-by-default Model
> Context Protocol (MCP) gateway that puts one governed, auditable control
> plane in front of many Apache data and streaming engines, so an AI agent
> never talks to Flink, Kafka, Spark, or Iceberg directly. Every agent action
> passes one fail-closed governance chain: secure-by-default tool exposure,
> per-caller authentication and scope, a policy decision point, approval for
> destructive operations, egress and server-side request forgery defense,
> rate limiting, circuit breaking, prompt-injection screening, output
> bounding and redaction, tool-catalog integrity, and a tamper-evident
> hash-chained audit trail. Engines plug in through a small service provider
> interface and contribute only tool definitions and backend calls.
> Proposal
> We propose to develop, under Apache governance, a Layer 7 policy MCP
> gateway plus a family of engine adapters. A proxy forwards bytes and a
> router dispatches by capability, but neither is a trust boundary. A gateway
> is: it knows the tool, the principal, the budget, and the policy for every
> call, and it can deny, redact, gate, and record. The gateway core is
> stateless at the protocol edge so it can scale behind an ordinary load
> balancer once shared governance state is externalized, and it is designed
> to align with OAuth 2.1, SPIFFE, SLSA, OpenTelemetry, and the NIST AI Risk
> Management Framework and ISO/IEC 42001.
> The initial contribution is a working Java reference implementation: a
> reusable gateway core, four in-depth engine adapters (Flink, Kafka, Spark,
> Iceberg), and a further set of thinner adapters for the wider Apache data
> platform. During incubation the priorities are community building, IP
> clearance, and promoting the roadmap items to full implementations.
> Background
> The Model Context Protocol has become a common way for AI agents to reach
> tools and data. As organizations connect agents to distributed Apache data
> estates, an agent that needs Flink, Kafka, Spark, and Iceberg must either
> drive each engine control plane directly or connect to a sprawl of
> independent, mostly read-only MCP servers, each with its own security
> posture, no shared audit, and no unified policy.
> An MCP server that can reach a control plane (a JobManager REST API, a
> Kafka AdminClient, a SQL gateway, an Iceberg catalog) is a privileged
> client. Shipping one safely is effectively shipping an access-control
> product: authentication, authorization, approval for destructive actions,
> redaction of secrets and personal data, rate and cost limits, and forensic
> audit. Many existing options lack these controls and carry
> single-maintainer sustainability risk. A single governed gateway, developed
> in the open under neutral governance, gives the ecosystem a shared standard
> for how agents operate Apache systems safely.
> Rationale
> A single governed gateway resolves the problems of the decentralized
> approach:
>
> - Security. One place enforces identity, authorization, approval,
> redaction, egress, and audit, instead of each server reimplementing or
> omitting them.
> - Maintainability. Adding an engine is a small adapter, not a new
> security model. There is one chain to review and harden, so the security
> review surface stays flat as engines are added.
> - Governance. One control plane for policy, budget, and provenance, with
> a stable deny taxonomy so operators can alert on codes such as
> POLICY_DENIED or APPROVAL_REQUIRED across every engine with one rule.
>
> Doing this under Apache governance keeps it neutral across vendors and
> engines rather than leaving agent access to fragmented single-vendor
> servers.
> Initial goals
>
> 1. Establish the project and practice the Apache Way: transparency,
> consensus, meritocracy, and community over code.
> 2. Complete IP clearance for the existing code and land it under
> Apache-2.0 with correct LICENSE and NOTICE files.
> 3. Publish and stabilize the adapter service provider interface so
> per-engine adapters are small, reviewable contributions.
> 4. Promote the roadmap items to full implementations: externalized
> high-availability state, CIMD and SPIFFE identity, a full Cedar runtime,
> vault-backed credential exchange, and an OpenTelemetry SDK bridge.
> 5. Produce the first Apache source releases and grow a diverse,
> multi-organization contributor base.
>
> Current status
> Aegis is a new codebase with a working multi-module reference
> implementation. It is not yet a community. The design, threat model,
> low-level design, and standards research are complete and public. The code
> builds green and is tested. A published design-conformance matrix maps
> every design claim to Done or Roadmap, so the maturity line is explicit.
> Verified build and test state
>
> - 36 Maven modules: a gateway core, adapters for 33 Apache engines (four
> in-depth today, Flink, Kafka, Spark, and Iceberg, and 29 thinner
> integrations covering Cassandra, HBase, Hive, Pulsar, Airflow, NiFi,
> Druid,
> Pinot, Doris, Impala, Calcite, Hudi, Paimon, Kudu, Ignite, BookKeeper,
> Ozone, Hadoop, ZooKeeper, Solr, Superset, Arrow Flight, Beam, Storm,
> Flume,
> ActiveMQ, CouchDB, Ranger, and Atlas), and a shaded runnable
> distribution.
> These are engine adapters the gateway supports, which is distinct from
> external adopters.
> - Builds with JDK 21 and runs on JDK 17 or newer with Maven 3.9 or
> newer.
> - 309 unit and integration tests across all modules, all passing, zero
> failures and zero errors on a clean build.
>
> Implemented in 0.1.0
>
> - The governance chain with ordered steps and first-denial-wins
> semantics.
> - Identity: shared bearer and a hashed multi-caller token file with
> per-caller scope, and an OAuth 2.1 resource-server mode with JWKS
> validation. Constant-time secret comparison and fail-closed startup
> validation.
> - Approvals: HMAC-SHA256 signed, TTL-bounded, single-use,
> tool-and-scope-bound tokens with replay rejection.
> - Policy: a builtin decision point, a live fail-closed OPA HTTP decision
> point, and a Cedar-style deny-file or HTTP delegate.
> - Per-caller outbound credential pass-through so a downstream engine can
> see a per-caller Authorization value when one was bound at admission.
> - Egress and server-side request forgery defense: allow list plus
> unconditional deny of cloud metadata and non-routable ranges, including
> numeric IP encodings and resolved addresses, with redirects disabled on
> outbound clients.
> - Rate limiting, circuit breaking, per-tool timeout, read-only SQL
> guard, identifier validation, output bounding, and data-loss-prevention
> redaction.
> - Tool-catalog integrity with durable pins and a fail-closed switch, a
> tamper-evident hash-chained audit, Prometheus metrics, and GenAI-shaped
> span log lines.
> - Two transports: stdio and authenticated Streamable HTTP with TLS, plus
> health, readiness, and metrics endpoints. A CycloneDX software bill of
> materials is produced at build time.
>
> Deferred to the roadmap (honestly labeled, not sold as implemented)
>
> - CIMD and SPIFFE authentication modes (they refuse to start today).
> - A full Cedar policy runtime, and vault-backed or token-exchange
> credential resolution.
> - Externalized high-availability state (shared nonce, rate, and audit
> stores). Until then, run a single replica; multi-replica replay
> protection
> and rate limits require the shared store.
> - The MCP Tasks extension for long-running jobs, an OpenTelemetry SDK
> bridge, a full Merkle and signature-based reconciliation proof, and true
> semantic routing and caching.
>
> These are tracked in the roadmap and the design-conformance matrix that
> ship with the code.
> Meritocracy, community, core developers, alignment
> The project will operate meritocratically from day one, with technical
> decisions on the dev list and committership earned through contribution.
> The community is currently centered on the initial author, Viquar Khan, who
> has around 23 years in software, has worked in the open since 2013, and has
> contributed to Apache Spark, Apache Iceberg, Apache Kafka, and other
> open-source projects. The author also maintains MCP-related open-source
> packages that have together been downloaded on the order of half a million
> times, so there is an existing user base to draw contributors from. Growing
> a committer base across the Flink, Kafka, Spark, and Iceberg communities
> and across employers is the primary goal of incubation. Aegis consumes
> public engine interfaces only and does not fork or modify any engine core.
> Known risks
> Orphaned products
> Low to moderate. Agentic access to data systems is a growing need and the
> governance gap is real, so demand is unlikely to vanish. The initial author
> has maintained open-source projects since 2013 rather than abandoning them,
> and the MCP-related packages already have a real user base, which lowers
> the abandonment risk. Mitigation: build a multi-organization community,
> keep the core small and standards aligned, and keep adapters independent so
> the project survives the departure of any single contributor.
> Inexperience with open source
> Low. This is not the situation here. The initial author has about 23 years
> in software, has worked in open source since 2013, and has contributed to
> Apache Spark, Apache Iceberg, Apache Kafka, and other projects, so the
> norms of public development, code review, and releases are familiar.
> Mentors will still help with the ASF-specific mechanics of voting, board
> reports, and IP clearance, which are process details rather than a gap in
> open-source experience.
> Homogenous developers
> This is the real risk and we state it plainly: the podling has one
> committer today. However, we are in active discussions with potential
> co-committers and expect to formally add them to this proposal in the
> coming days. What further reduces this risk is that the author is already
> embedded in the exact communities this project draws from (Spark, Iceberg,
> Kafka) and has an existing user base for the MCP packages, so there is a
> concrete pool to recruit from rather than a cold start. Mitigation: recruit
> committers from more than one organization before graduation, shape the
> adapter contract so per-engine contributions are natural, and use
> good-first-issue and adapter-sized work to onboard newcomers. Growing the
> committer base is the main reason we are here.
> Reliance on salaried developers
> Low current reliance; the work to date is largely independent. The project
> will attract contributors with varied motivations and employers so no
> single company can stall it.
> Relationships with other Apache products
> Aegis consumes the public interfaces of Flink, Kafka, Spark, Iceberg, and
> other Apache data systems and does not fork or modify them. We will
> coordinate on the relevant dev lists and will not duplicate or compete with
> an engine that ships its own MCP surface; where an engine has one, Aegis
> composes with it. Aegis is not proposed for any engine core.
> Excessive fascination with the Apache brand
> The project seeks Apache governance for its community model and neutrality,
> not for the brand. Until and unless accepted, it uses a neutral name and
> does not use the Apache marks or the feather. The breadth of engine
> adapters reflects a common governance surface, not an attempt to claim the
> ecosystem; only four adapters are in-depth today and the rest are
> explicitly thin.
> Documentation
> Public documentation exists and will be maintained in the repository: an
> end-to-end design with architecture decision records, a low-level design
> with architecture, sequence, and state diagrams, a threat and governance
> model, a design-conformance matrix, standards research, and operations and
> adapter guides.
> Initial source
> The initial source is the Java multi-module gateway described above,
> currently in a private repository at
> https://github.com/vaquarkhan/aegis-mcp-gateway under the initial author.
> Access is available on request to anyone reviewing this proposal, and the
> author will make it public before the vote if the community prefers to read
> the code first. It includes the gateway core, the four in-depth adapters,
> the thinner adapters, the shaded distribution, runnable examples, and the
> documentation set. On acceptance it will be donated under a Software Grant
> and made public.
> Source and intellectual property submission plan
> The initial author will submit the code under a Software Grant Agreement
> and complete IP clearance early in incubation, with ICLAs from every
> committer. Every source file will carry the standard Apache-2.0 header with
> correct LICENSE and NOTICE files; any premature ASF-ownership wording will
> be corrected to the standard header at donation time.
> Transparency on tooling: parts of the codebase were developed with
> AI-assisted coding tools under the author's direction and review. The
> author asserts authorship and the right to contribute the work, and will
> confirm provenance and authorship during IP clearance so the grant is
> clean. We raise this proactively so the IPMC can review it rather than
> discover it.
> External dependencies
> Runtime dependencies are Apache-2.0 or compatible, including the MCP Java
> SDK, a servlet container for the HTTP transport, SLF4J, Logback, and Nimbus
> for JOSE and JWT, with JUnit for tests. Per-engine adapters add that engine
> to the official client, for example the Kafka clients library. A full
> dependency review and a CycloneDX software bill of materials are produced.
> No GPL or ASF category X dependency is introduced into the core.
> Cryptography
> Aegis uses standard, library-based cryptography: HMAC-SHA256 for approval
> tokens, TLS for the HTTP transport, and JSON Web Token validation for
> OAuth. Signature-based integrity is an optional gate. The project will
> comply with ASF export notification requirements.
> Required resources
> Mailing lists
>
> - private@aegis.incubator.apache.org
> - dev@aegis.incubator.apache.org
> - commits@aegis.incubator.apache.org
>
> Source control
>
> - A Git repository under the ASF (gitbox with a GitHub mirror).
>
> Issue tracking
>
> - ASF Jira or GitHub issues per current ASF practice.
>
> Other
>
> - Website and wiki space, and continuous integration through ASF
> infrastructure.
>
> Initial committers
>
> - Viquar Khan *(Note: We are in active conversations with potential
> contributors and expect to add a few additional initial committers here
> in
> the next few days before moving to a formal vote.)*
>
> - To be recruited before and during incubation: committers from the
> Flink, Kafka, Spark, and Iceberg communities and from additional
> organizations. Adapter-sized work is designed to make these
> contributions
> natural.
>
> Affiliations
> To be completed as committers are confirmed. Diversity of affiliation is an
> explicit goal; the current single-affiliation status is the main risk being
> addressed.
> Sponsors
> Champion
> To be identified. An ASF Member Champion will help finalize this proposal,
> recruit mentors, and shepherd the discussion and vote on the Incubator
> general list.
> Nominated mentors
> Three or more IPMC members to be recruited, ideally including participants
> from the Flink, Kafka, and Iceberg communities.
> Sponsoring entity
> The Apache Incubator PMC.
> Roadmap during incubation
> Phase
> Focus
> Bootstrap
> IP clearance, name search, infra, initial committers, first dev-list
> decisions
> 0.2
> Externalized HA state, vault-backed credentials, OAuth multi-issuer, OTel
> SDK bridge, supply-chain CI (enforcer, CVE scan, signing)
> 0.3
> CIMD and SPIFFE identity, full Cedar runtime, MCP Tasks, signature-based
> reconciliation proof, semantic routing and caching
> Graduation readiness
> Diverse community, cadence of Apache releases, healthy governance
> References
>
> - Apache Incubator proposal guide:
> https://incubator.apache.org/guides/proposal.html
> - Apache Incubator Cookbook: https://incubator.apache.org/cookbook/
> - The Apache Way: https://www.apache.org/theapacheway/
> - Model Context Protocol: https://modelcontextprotocol.io/
>