Addressing the “Agent-Visible Context” leak: How local-first observability can accidentally re-expose secrets through trace history

I've been working on a small project, a transparent stdio proxy for MCP (Model Context Protocol) agents, and a user recently identified a significant trust-boundary issue that I think is relevant to anyone building "local-first" or "on-device" agentic tooling.

The Problem: The Context Bridge

In an observability setup, you typically log tool calls and their arguments to a local database (like SQLite) so the user can audit the agent's behavior. The goal is to keep this data local to the machine for privacy.

However, if the agent itself is given tools to query that trace history (e.g., `trace.search` or `trace.history`), you create a massive vulnerability. If a tool call earlier in the session contains a secret (API key, PII, etc.), that secret is stored in the database. If the agent then uses a trace tool to "look back" at its history, that secret is pulled back into the LLM's context window.

This effectively bridges the "operator-local storage" boundary and the "agent-visible context" boundary.

The Technical Fix: Metadata-Only Tracing

To solve this, we had to move away from a "log everything" model to a "metadata-first" architecture.

1. Filesystem Hardening: We ensured the SQLite DB is strictly created with `0600` permissions. It was defaulting to `0644` via a directory creation call, which meant any other process on the machine could read the raw traces.
2. Decoupling Payloads from Metadata: We modified the trace tools so they return only structured metadata by default: tool name, timestamp, duration, error status, and a SHA-256 hash of the inputs/outputs.
3. Explicit Opt-in for Raw Data: To see actual arguments/results, the user must explicitly enable an environment variable (`OBSERVER_RAW_PAYLOAD=1`). This forces a conscious decision to allow the agent to see its own history.
4. Hashing for Verification: By returning a SHA-256 hash of the arguments instead of the arguments themselves, the agent can still "verify" a specific tool call occurred without actually seeing the sensitive content.
5. Pre-persistence Redaction: We implemented a regex-based redaction layer that runs _before_ anything hits storage, ensuring that even if a user opts into raw payloads, high-entropy secrets are sanitized at the ingestion point.

This case study highlights that for LLM agents, "observability" isn't just about logging; it's about managing a new type of trust boundary between the local system and the agent's context window.

Happy to discuss the implementation details or the edge cases we found during the regression tests.