TLS proxy Interceptor hook.

[gregwebs]

Currently TLS interception is used for secrets. This could be opened up as an extensibility point.
There is a fork that is doing this:
https://github.com/wirenboard/microsandbox/blob/537fe663bd1875ffd42fdc763392e83fe11016f2/crates/network/lib/tls/proxy.rs#L502

This is used in the fork for

• automatic credential refresh
• to allow list urls (specific github orgs/repos) rather than only filtering at the host level

[appcypher]

this is interesting. we intend to support different kinds of interception scenario when the planned plugin feature lands.

i'm curious, with this work you linked, how the hook works. is it supposed to be supplied by the user? and how would that work from the perspective of an SDK user.

[gregwebs]

In this the user writes an interceptor in Rust. This seems potentially performance sensitive and therefore better off kept in Rust. But you could probably satisfy most use cases by letting users submit a matching string or regex along with the alteration to perform. Just adding HTTP path allow lists to the SDK would satisfy a big use case

…

On Fri, Aug 14, 2026 at 6:32 PM Stephen Akinyemi ***@***.***> wrote: this is interesting. we intend to support different kind of interception concepts when the planned plugin feature lands. i'm curious, with this work you linked, how the hook works. is it supposed to be supplied by the user? and how would that work from the perspective of an SDK user. — Reply to this email directly, view it on GitHub <#1345?email_source=notifications&email_token=AAAAJH6HVLICDISUDWRST3T5J6OR3A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQGIZTEMJSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18023212>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAJH55UZOS7XHDCTTGK235J6OR3AVCNFSNUABIKJSXA33TNF2G64TZHM4DMNZRHEZDMMRVHNCGS43DOVZXG2LPNY5TCMBWGEYDKNRRUF3AE> . You are receiving this because you authored the thread.Message ID: <superradcompany/microsandbox/repo-discussions/1345/comments/18023212@ github.com>

[gregwebs]

Although they write the interceptor here in rust, they then later use it by registering a rule that is (host, method, path). They then send the contents to a hook, a subprocess that takes stdin and replies with stdout. https://github.com/wirenboard/microsandbox/commit/ 35715bc For a simple path rejection use case access to the request isn’t needed. However, their GitHub use case handles lots of edge cases and even graphql. https://github.com/gregwebs/agent-vm/blob/main/crates/agent-vm/src/intercept_hook.rs For the automatic token refresh case, that’s quite involved as well. For an SDK I think this subprocess model is very extensible but difficult for implementers and doesn’t work for interpreted languages that have a high startup overhead. A callback is better. WASM is another option but creates a build process. Building these features in Rust makes more sense to me.

…

On Sat, Aug 15, 2026 at 6:52 AM Greg Weber ***@***.***> wrote: In this the user writes an interceptor in Rust. This seems potentially performance sensitive and therefore better off kept in Rust. But you could probably satisfy most use cases by letting users submit a matching string or regex along with the alteration to perform. Just adding HTTP path allow lists to the SDK would satisfy a big use case On Fri, Aug 14, 2026 at 6:32 PM Stephen Akinyemi ***@***.***> wrote: > this is interesting. we intend to support different kind of interception > concepts when the planned plugin feature lands. > > i'm curious, with this work you linked, how the hook works. is it > supposed to be supplied by the user? and how would that work from the > perspective of an SDK user. > > — > Reply to this email directly, view it on GitHub > <#1345?email_source=notifications&email_token=AAAAJH6HVLICDISUDWRST3T5J6OR3A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQGIZTEMJSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18023212>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAAJH55UZOS7XHDCTTGK235J6OR3AVCNFSNUABIKJSXA33TNF2G64TZHM4DMNZRHEZDMMRVHNCGS43DOVZXG2LPNY5TCMBWGEYDKNRRUF3AE> > . > You are receiving this because you authored the thread.Message ID: > <superradcompany/microsandbox/repo-discussions/1345/comments/18023212@ > github.com> >