Content-aware egress filtering: should NemoClaw have a hook for PII redaction on allowed traffic?

[Akhilvallala1]

Problem

OpenShell's network policy decides where a sandboxed agent may send bytes. It does not look at what is in those bytes. If an agent has a reasonable allow-list (an inference endpoint and a search API, for example), it can still paste a customer's SSN, claim number, or account number into a search query. The policy allows it because the host is allowed.

For teams that adopt NemoClaw for isolation in regulated settings (insurance, healthcare, finance), host-level egress control alone does not prevent data leaks through approved destinations.

What I built

piiguard (Apache-2.0) is a prototype of this content layer. I built it at the Recursive Agents Hackathon and have kept developing it since.

• A guard proxy sits between the sandbox and allowed egress. It replaces PII in outbound payloads with reversible tokens ([PII_SSN_1]), forwards the request, and restores the values in the response so the agent can still finish its task. Provider keys stay in the proxy, not in the sandbox.
• Detection runs locally by default. It combines regex rules with an optional local GLiNER-PII or Presidio detector. A remote Nemotron classifier is optional, and it is the only path that sends text off the host.
• Rules are learned offline and gated. A batch loop proposes changes to plain YAML rules for organization-specific identifiers. A change is accepted only if it lowers leaks on a validation set without raising false positives. Every accepted change is a reviewable, revertible git commit. Nothing learns from live traffic.

Results so far (with limits)

• Structured identifiers, NVIDIA Nemotron-PII test split: learned rules plus local GLiNER-PII catch 91.0% of spans. Presidio defaults catch 68.5%, and the remote Nemotron classifier catches 92.8%.
• Semantic PII (names, places, companies): Presidio still leads, at 65.9% vs 63.0% entity recall.
• 500 fresh attacks with unseen values and formats: learned rules leak 25.6% [22.0, 29.6], compared with 76.0% for the hand-written starting rules.
• False flags on 1,075 clean samples: 0.3% with rules only, 5.1% with Presidio, and 15.4% with GLiNER-PII. This tradeoff is real.

Questions for maintainers

1. Is content-level egress filtering in scope for NemoClaw, or does it belong in OpenShell or entirely outside both?
2. If it is in scope, would you prefer:
   • (a) a documented extension point, such as routing a policy's allowed egress through a user-supplied filtering proxy,
   • (b) a docs recipe showing how to run a filter like piiguard alongside a sandbox, or
   • (c) listing it as an independent project under Community Solutions?
3. Does a related plan or prior decision already exist that I should align with?

I'm happy to do the implementation and validation for whichever option you prefer, once a maintainer records a scope decision.