Vouch request: [huang195]

[huang195]

What do you want to work on?

I work on AuthBridge component of Kagenti. It is a proxy that does token validation, token exchange, OPA authorization, and has a full pipeline that runs things like guardrails for agentic workloads. I'm interested in making the Supervisor's proxy component a pluggable component so external proxies (like AuthBridge) is able to be brought in to do more advanced network observability and enforcement.

Why this change?

Openshell's proxy only deals with HTTP headers, but for agentic workloads, it would need body parsing and processing. Our proxy is specially built for this purpose, and we'd like to explore if we can use the best of both.

Checklist

• I wrote this request myself (not AI-generated)
• I have read CONTRIBUTING.md

[johntmyers]

This seems like something that should work with middleware (#1738). Ideally this is something that you can build and maintain out-of-tree and provide implementation guidance.

[huang195]

Makes sense — building this as an out-of-tree middleware works. The inspection/policy/guardrail parts of what we've prototyped line up with the pre_credentials hook, and we're happy to maintain that out-of-tree and write up guidance for others doing the same.

The part that doesn't fit the hook is credential-owning egress, where the proxy injects the upstream Authorization itself and does on-behalf-of token exchange. OpenShell doesn't do that today (the Router injects a static provider credential), and the contract keeps credentials on the supervisor side on purpose, which we think is right. For inference it doesn't really matter, since the Router already keeps the token out of the sandbox and we can hook in at the route endpoint, so it only comes up for non-inference egress and OBO.

So the main thing I wanted to check: is credential-owning egress out of scope for now? If it is, we're fine staying inside the middleware boundary and putting our effort into the middleware and the guidance.