Develop nexus-sidecar for Zero-Knowledge, Polyglot Agent Integration

[sangalo20]

What?

We need to build nexus-sidecar, a standalone proxy service designed to be deployed alongside an AI Agent (e.g., as a Kubernetes sidecar container or a local background process).

Currently, our token retrieval and cryptographic request signing logic is embedded in nexus-bridge, which is a Go library. The sidecar will encapsulate this logic into an independent proxy, allowing agents written in any language to leverage Nexus without needing language-specific SDKs.

Why?

1. Polyglot Support (Python & Node.js First): The AI ecosystem is heavily dominated by Python and TypeScript. Building and maintaining complex, secure cryptographic middleware (like handling DPoP, mTLS, or OAuth 1.0a signatures) natively in every language is prone to bugs and massive maintenance overhead. The sidecar allows developers to use standard HTTP clients (requests, axios) to make API calls, while the sidecar handles the complex auth injection.
2. Zero-Knowledge Agent Architecture: AI agents are highly susceptible to novel attack vectors like Prompt Injection leading to Remote Code Execution (RCE). If an agent is compromised and it holds API access tokens in its memory (RAM), those tokens can be exfiltrated. By moving the signing logic out-of-process into the sidecar, the agent never actually sees the raw access tokens. Even a fully compromised agent yields no long-term credentials to an attacker.

Sample Approach (The "How")

1. The Request: A Python agent wants to fetch data from GitHub. Instead of calling api.github.com directly, it makes an unauthenticated HTTP request to the local sidecar:

   GET http://localhost:8080/user/repos
   X-Nexus-Provider: github
   X-Nexus-Tenant: tenant_123

2. Interception & Credential Fetching: The sidecar (running on localhost:8080) intercepts the request. It identifies the target provider and tenant, then communicates securely with nexus-gateway / nexus-broker to retrieve a fresh, valid access token for that specific connection.
3. Cryptographic Signing: The sidecar modifies the outgoing request, injecting the necessary Authorization: Bearer <token> headers, calculating any required cryptographic signatures, or applying mTLS certificates.
4. Forwarding: The sidecar acts as a transparent reverse proxy, forwarding the newly authenticated request to api.github.com.
5. Response: The sidecar receives the response from GitHub and passes it back to the Python agent.

Where to Begin

1. Scaffold the Service: Create a new top-level directory nexus-sidecar and initialize a Go module.
2. Reverse Proxy Foundation: Utilize Go's net/http/httputil.ReverseProxy to build a robust foundation capable of intercepting and rewriting HTTP requests.
3. Integrate nexus-bridge: Import the existing nexus-bridge library into the sidecar. Use it as middleware to handle the heavy lifting of token retrieval and request modification.
4. Configuration & Routing: Define a clean way for the proxy to know where to route traffic (e.g., mapping X-Nexus-Provider: github to https://api.github.com).
5. Proof of Concept: Write a simple Python script using the requests library that successfully queries an upstream API through the sidecar without knowing any secrets.