Git hooks and agent hooks catch problems at commit time and during active tool calls. But a complete governance picture for AI agents also needs visibility into the traffic flowing between the agent and the AI provider – the prompts being sent, the responses coming back, the tool calls being requested. That is the problem the Agent Proxy is designed to address.
The Agent Proxy is a planned runtime boundary in Ethosure, currently in early development. It sits between the agent and everything else – provider APIs, local tools, and repository files – and applies policy to every payload that passes through.
Why a proxy layer matters
AI agents communicate with providers by sending prompts and receiving responses. Those prompts often contain code, file contents, and potentially sensitive context. Responses contain tool call requests – instructions telling the agent which file to edit, which command to run, which repository path to read. If governance only operates on the actions the agent takes locally (via hooks), it misses a significant surface area: what is being sent to the provider, what is coming back, and whether the provider’s tool-call instructions are safe.
The Agent Proxy addresses this by creating a single interception point for all that traffic, applying deterministic policy to it, and recording body-free evidence of every event.
The trust boundary
The proxy boundary includes four categories of traffic:
- Outbound provider requests: prompts, tool definitions, model-selection metadata being sent to the AI provider.
- Inbound provider responses: tool call requests, streaming response chunks, assistant text coming back from the provider.
- Local tool calls and outputs: tool invocations and their results as they flow through the agent’s workflow.
- File operations: reads, directory listings, edit proposals, and patch outcomes.
A core design principle: the proxy treats all payloads as untrusted. It does not assume that the provider’s responses are safe. An inbound tool call that asks the agent to execute a shell command or delete a file is evaluated by policy before the agent acts on it.
Body-free evidence: privacy by design
The proxy records evidence of every event, but with a critical privacy constraint: it never stores prompt or response bodies. Instead, it records:
- The provider, model, event direction, and payload kind.
- The token count and payload hash.
- The tool names involved (argument content is hashed, not stored).
- The policy decision and any DLP (data leakage prevention) findings.
- Cache keys and transform records.
This “body-free” evidence design means the proxy can demonstrate governance – “outbound traffic to provider X was inspected, no DLP violations were found” – without creating a log of confidential prompt and response content. The governance record is complete without being a surveillance record.
Outbound enforcement: catching credential leaks
When TLS interception is enabled (it is opt-in and explicit, never a hidden default), the proxy scans outbound requests for DLP facts before they reach the provider. The scan looks for:
- Secret shapes: AWS credentials, OpenAI API keys, GitHub tokens, Slack tokens, PEM private key headers.
- Credential filenames: `.env`, `id_rsa`, `.netrc`, `credentials`, `*.pem`.
- Protected paths: `.ssh/`, `.aws/`, `secrets/`.
These facts are evaluated by CEL policy. The seed policy `proxy.outbound_exfiltration` denies any outbound request whose DLP facts include a secret, credential file, or protected path finding. The denial is a hard block – the request never reaches the provider – and the evidence record captures the DLP finding without storing the content that triggered it.
Inbound enforcement: unsafe tool calls
The proxy also evaluates inbound provider responses before returning them to the agent. The policy `proxy.inbound_unsafe_tool_call` denies inbound tool calls that ask the agent to invoke unsafe local operations – shells, command execution, file writes, file deletion, patch application, or direct Git calls.
This is significant: prompt injection attacks often work by having a provider’s response instruct the agent to take unsafe actions. By evaluating inbound tool calls through policy before the agent acts on them, the proxy creates a defensive layer against this class of attack.
Token efficiency: output compression
The proxy also applies token-efficiency transforms. When tool output is verbose – long test logs, compiler output with repeated dependency frames, output that is mostly noise – the proxy compresses it before it reaches the model’s context window. The compression preserves the beginning and end of the output (where startup failures and terminal stack traces typically appear), inserts an explicit omission marker, and stores the full original output in a temporary evidence file.
This is not silent truncation. The transform is recorded in the evidence ledger with the omitted line count, the temporary full-output path, and a token measurement. The agent sees a compact representation of the output; the evidence record shows exactly what was omitted and why.
The operator model: explicit, not hidden
A core design constraint of the Agent Proxy: it is not enabled by default and cannot be enabled invisibly. Operators must make explicit decisions about whether outbound traffic may be inspected, whether TLS interception is active, and which providers and tools are routed through the proxy. The coding-ethos documentation is clear: “TLS interception is high risk. It must remain an explicit, documented operator choice and must never be introduced as a hidden fallback.”
Routing is disabled unless specific environment variables are set. When those variables are present, the proxy exports standard `HTTP_PROXY` and `HTTPS_PROXY` variables for child agent processes. The status command reports proxy state – disabled, correctly enabled, or misconfigured – so operators always know whether routing is active.
Current status
The Agent Proxy is in active development. The first live capability is pass-through routing – mechanical forwarding of HTTP provider traffic with body-free event recording, without inspection or mutation. The outbound DLP enforcement, inbound tool-call enforcement, and token compression transforms are progressively being added. The full TLS interception proxy and sandbox trust-store binding are tracked as subsequent milestones.
