[GSoC 2026] Proposal Exploration: Network Traffic Proxy & Domain Filtering (Idea 1) #21874
ojaswi1234
started this conversation in
Ideas
Replies: 1 comment
-
|
still improving |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey everyone!
I'm Ojaswi, a 3rd-year CS student, and I've been looking into Idea 1 from the GSoC 2026 list: Network Traffic Proxy and Domain Filtering. I’m really interested in the security aspect of LLM agents, and I’ve spent some time over the last few days building a prototype to see how we can wire this into the existing sandbox.
The Concept
The goal is to add a defense-in-depth layer that catches network traffic at the gateway level. Even if the sandbox is "open," we should be able to audit where the agent is going and block unauthorized domains.
What I’ve Prototyped So Far:
I wanted to validate the "loop" from the proxy script to the Ink UI. Here is the approach I'm testing:
Proxy Layer: A Node.js script that handles requests via GEMINI_SANDBOX_PROXY_COMMAND.
User Consent UI: A new ProxyPermissionDialog component that pops up in the terminal when a new domain is hit.
Communication: Currently using a basic file-based IPC (writing to request.json and reading from response.json). It’s a bit basic, but it proves the UI can successfully "pause" and "resume" network activity based on user input.
This is my PR Gsoc network proxy prototype #21886 and my issue Network Traffic Proxy Prototype & Exploration [ GSOC 2026 ] #21872
Areas for Discussion:
Before I get too deep into the formal proposal, I’d love to get some feedback from @gauravghosh or the other maintainers on a few things:
IPC Mechanism: Using the file system for IPC is definitely going to have race condition issues if the agent makes concurrent calls. Should I look into using Unix domain sockets or Node's process.send() for a more robust connection between the proxy and the UI?
HTTPS Interception: For domain filtering, I'm thinking of parsing the SNI (Server Name Indication) during the TLS handshake so we don't have to deal with full SSL decryption/CA certificates initially. Does that align with the security goals of this project?
Resource Usage: I noticed npm run preflight is pretty heavy on my machine. Is there a specific subset of tests I should focus on while iterating on this feature?
I’d love to discuss the architecture here first, before implementing...
Looking forward to hearing what you think.
Beta Was this translation helpful? Give feedback.
All reactions