Privacy Guard

Proposal

Build Privacy Guard as the OpenShell privacy control plane for outbound sandbox traffic. Privacy Guard runs before credential injection and relay, calls a configurable scanner, applies sandbox policy actions, and records audit evidence without storing raw sensitive values by default.
For model-bound traffic, Privacy Guard findings can also feed a pluggable Model Router so gateway owners can route prompts to approved model endpoints based on sensitivity, cost, latency, residency, model capability, or customer policy.

Problem

AI agents increasingly work with real logs, files, stack traces, source code, customer records, credentials, and business context. OpenShell already reduces credential risk by brokering service credentials at the proxy, so sandboxes do not need raw service credentials. That does not prevent a human or agent from bringing sensitive content into the sandbox and sending it to an external service or frontier model.
Network policy can decide which endpoints are allowed. It cannot, by itself, decide whether a request body contains PII, secrets, customer data, proprietary terms, or content that should only go to an approved enterprise model.

What OpenShell Should Build

OpenShell should own the privacy enforcement architecture, not every privacy detection technique. Privacy Guard should define where scanning happens, when it runs, how policy is enforced, how plugins are called, how failures are handled, and what gets audited.
Scanner plugins should own the detection and transformation intelligence. The built-in scanner should be small and fast. Advanced PII detection, topic classification, anonymization, and synthetic rewriting should be plugin capabilities.
OpenShell Responsibilities

• Policy Semantics: Extend the existing sandbox policy so gateway owners can define privacy actions for detected sensitive content per endpoint. The available actions depend on the configured scanner plugin's capabilities. The default scanner should support observe, block, and redact. Customer scanner plugins may add richer actions such as rewrite, anonymization, or synthetic replacement. Policy should also define scan limits, skipped-scan behavior, audit behavior, and whether scanner findings can feed model-routing decisions.
• Privacy Scanner Plugins: Define a small scanner plugin contract and ship a simple default scanner in OpenShell.
  • Customers can configure their own scanner service when they need advanced detection or transformation.
  • Inputs: payload, content type, endpoint context, policy context, requested actions, and session or tenant context.
  • Outputs: findings, sensitivity labels, confidence, spans, supported action, optional transformed payload, latency, errors, and skipped-scan reasons.
• Pluggable Model Router: Add a pluggable Model Router with a simple default implementation. Customers can bring their own router for privacy, cost, latency, residency, model capability, availability, tenant, or workload-based routing. The router should consume Privacy Guard findings and mitigation status without requiring another scan. Routing should happen after egress policy has run and before credential injection.

Privacy Guard will default to blocking unscanned outbound content. Gateway owners may override this per endpoint with an explicit fallback policy, such as allow, route to an approved local endpoint, or require approval. This keeps the secure default simple: if OpenShell cannot determine whether sensitive data would leave the sandbox, the content should not leave by default.