pdurlej/platform

Fork 0

Phase 07+ ADR proposal: pseudo-anonymization read-layer for cloud-agent vault access (openai/privacy-filter) #177

New issue

Open

opened 2026-05-11 07:43:59 +02:00 by claude · 2 comments

claude commented

2026-05-11 07:43:59 +02:00

Collaborator

Context

Per operator voice-note 2026-05-11 07:26 + operator's reference to https://huggingface.co/openai/privacy-filter:

"Czy żeby wykorzystać jakiś model, ten privacy od openai jeden i drugi lokalny model privacy, żeby Iskra, czy modele inne niż Iskra dostawało pseudo-anonimizację przez to. Dzięki czemu ja będę widział dobrze, a agenci też będą widzieli dobrze, tylko agenci będą widzieli bez jakichś wrażliwych danych."

This is the pseudo-anonymization read-layer concept: cloud agents (Hermes, claude, codex, Ollama swarm) read vault content through a local PII-redaction proxy. Operator sees plaintext; agents see redacted skeleton.

Operator confirms: "To wygląda jak WSPANIAŁE docelowe rozwiązanie dla nas, które może być i remote na netcupach jak i u mnie lokalnie."

Target model: `openai/privacy-filter`

Verified specs (per HF model card 2026-05-11):

Property	Value	Implication
License	Apache 2.0	commercial-friendly, no restrictions
Size	1.5B total / 50M active (sparse-MoE)	fast inference even on CPU
Context	128,000 tokens	full vault note fits
Categories	8 PII (account, address, email, person, phone, url, date, secret)	covers operator's vault sensitivity
Architecture	bidirectional token classifier with constrained Viterbi decoder	single-pass span detection
Deployment	CPU/GPU/browser (transformers.js)	runs anywhere operator wants
Polish support	multilingual robustness evaluated	likely fits operator's Polish-first vault
Local CPU inference	yes (per HF docs)	operator-owned infrastructure-only is feasible

Limitations (per HF model card):

Not a complete anonymization solution — defense-in-depth only
Static label policy (8 categories fixed; retrain to extend)
Boundary issues in mixed-format text
High-sensitivity workflows (medical, legal, financial) require human review

These limitations are acceptable for operator's use case because (per voice-note 2026-05-11) the architecture is physical-separation-first (Włóczykij vault for things agents should never see; Iskra-i-Piotr vault for things agents may see). Privacy-filter is the defense-in-depth layer on top of physical separation.

Architecture proposal (this issue produces full ADR draft)

operator writes to Iskra-i-Piotr/* (sees plaintext)
                  │
                  ▼
agent (Hermes/claude/codex/Ollama) issues read request
                  │
                  ▼
ops/local-admin/wrappers/vault_read_anonymized.py
  (gatekeeper; ADR-0010 local-admin tier)
                  │
                  ├── path-policy check (Iskra-i-Piotr OK; Włóczykij DENIED)
                  ├── load openai/privacy-filter (M1 local OR RS2000)
                  ├── tokenize note content
                  ├── classify per token (8 PII categories)
                  ├── mask spans (replace with `[REDACTED:PERSON]` etc.)
                  └── return masked text + redaction summary
                  │
                  ▼
agent receives masked content; operator-personal PII removed

Scope

ADR draft for pseudo-anonymization read-layer:
- Decision: which model, where it runs, how it integrates with ADR-0010 local-admin tier
- Failure semantics: what if redactor fails (default-deny: return error, don't return plaintext)
- Performance budget: redactor latency must be <500ms per note for agent productivity
- Audit log: what was redacted, by whom (which agent), for which read
Spike on RS2000 OR M1 local:
- Install openai/privacy-filter, benchmark inference latency on operator's actual vault notes (sample 10 of varied sizes)
- Verify Polish PII detection quality (operator-eval'd)
- Measure RAM footprint
- Verify integration with ADR-0010 wrapper pattern
Phased rollout proposal:
- Phase A: ship redactor as standalone wrapper; agents opt-in by calling it
- Phase B: integrate into ADR-0010 local-admin wrapper for vault reads (automatic for soft_private content)
- Phase C: hard-private content stays in physical-separation tier (Włóczykij); never reaches redactor
Operator confirmation gate before any agent uses redactor on real vault content (vs fixtures).

Out of scope

Replacing physical separation (Włóczykij). Operator's intuition: physical-separation-first is safer architectural principle than read-time filtering. Redactor is defense-in-depth, not replacement.
Pseudo-anonymization for non-vault content (e.g. Signal messages, Matrix room messages) — separate issue if needed.
Public release of the redactor pipeline (operator's choice; default: private).

Phase

Phase 07 (extension of ADR-0010 local-admin tier) OR Phase 08 if Phase 07 implementation budget is tight. ADR draft can land in Phase 07; spike runs in Phase 07; implementation possibly Phase 08.

Acceptance criteria

ADR-0015 (pseudo-anonymization read-layer) drafted and reviewed
Spike confirms <500ms latency on operator's actual notes (Polish content)
Audit-log schema specified
Phased rollout proposal includes operator-confirmation gates per phase
Integration with ADR-0010 capabilities.yaml documented

Refs

Operator voice-note 2026-05-11 07:26 (introduced concept + linked openai/privacy-filter)
ADR-0010 (local-admin LLM tier) — this issue extends it
ADR-0012 (Phase 07 scope-lock) — this addition needs scope-lock amendment if it lands as Phase 07
PR #171 comment (Włóczykij architecture inversion clarifies physical-separation-first)
Model: https://huggingface.co/openai/privacy-filter
Repo: https://github.com/openai/privacy-filter

Coordination

Lane: Phase 07 design (advisor + executor)
Owner: claude-orchestrator drafts ADR; operator approves; codex implements if approved
Operator: provides sample vault notes for spike; reviews PII detection quality on Polish content

Role: advisor (claude)
Inspired by: operator's voice-note imagery — "mnisi doskonałości jakby przeglądali i to sortowali" (monks of perfection curating overnight). The redactor is the morning-after layer for the monks' work.

## Context Per operator voice-note 2026-05-11 07:26 + operator's reference to https://huggingface.co/openai/privacy-filter: > *"Czy żeby wykorzystać jakiś model, ten privacy od openai jeden i drugi lokalny model privacy, żeby Iskra, czy modele inne niż Iskra dostawało pseudo-anonimizację przez to. Dzięki czemu ja będę widział dobrze, a agenci też będą widzieli dobrze, tylko agenci będą widzieli bez jakichś wrażliwych danych."* This is the **pseudo-anonymization read-layer** concept: cloud agents (Hermes, claude, codex, Ollama swarm) read vault content through a local PII-redaction proxy. Operator sees plaintext; agents see redacted skeleton. Operator confirms: *"To wygląda jak WSPANIAŁE docelowe rozwiązanie dla nas, które może być i remote na netcupach jak i u mnie lokalnie."* ## Target model: `openai/privacy-filter` Verified specs (per HF model card 2026-05-11): | Property | Value | Implication | |----------|-------|-------------| | License | Apache 2.0 | commercial-friendly, no restrictions | | Size | 1.5B total / 50M active (sparse-MoE) | fast inference even on CPU | | Context | 128,000 tokens | full vault note fits | | Categories | 8 PII (account, address, email, person, phone, url, date, secret) | covers operator's vault sensitivity | | Architecture | bidirectional token classifier with constrained Viterbi decoder | single-pass span detection | | Deployment | CPU/GPU/browser (transformers.js) | runs anywhere operator wants | | Polish support | multilingual robustness evaluated | likely fits operator's Polish-first vault | | Local CPU inference | yes (per HF docs) | operator-owned infrastructure-only is feasible | **Limitations** (per HF model card): - Not a complete anonymization solution — defense-in-depth only - Static label policy (8 categories fixed; retrain to extend) - Boundary issues in mixed-format text - High-sensitivity workflows (medical, legal, financial) require human review These limitations are **acceptable** for operator's use case because (per voice-note 2026-05-11) the architecture is **physical-separation-first** (Włóczykij vault for things agents should never see; Iskra-i-Piotr vault for things agents may see). Privacy-filter is the **defense-in-depth** layer on top of physical separation. ## Architecture proposal (this issue produces full ADR draft) ``` operator writes to Iskra-i-Piotr/* (sees plaintext) │ ▼ agent (Hermes/claude/codex/Ollama) issues read request │ ▼ ops/local-admin/wrappers/vault_read_anonymized.py (gatekeeper; ADR-0010 local-admin tier) │ ├── path-policy check (Iskra-i-Piotr OK; Włóczykij DENIED) ├── load openai/privacy-filter (M1 local OR RS2000) ├── tokenize note content ├── classify per token (8 PII categories) ├── mask spans (replace with `[REDACTED:PERSON]` etc.) └── return masked text + redaction summary │ ▼ agent receives masked content; operator-personal PII removed ``` ## Scope 1. **ADR draft** for pseudo-anonymization read-layer: - Decision: which model, where it runs, how it integrates with ADR-0010 local-admin tier - Failure semantics: what if redactor fails (default-deny: return error, don't return plaintext) - Performance budget: redactor latency must be <500ms per note for agent productivity - Audit log: what was redacted, by whom (which agent), for which read 2. **Spike** on RS2000 OR M1 local: - Install openai/privacy-filter, benchmark inference latency on operator's actual vault notes (sample 10 of varied sizes) - Verify Polish PII detection quality (operator-eval'd) - Measure RAM footprint - Verify integration with ADR-0010 wrapper pattern 3. **Phased rollout proposal**: - **Phase A**: ship redactor as standalone wrapper; agents opt-in by calling it - **Phase B**: integrate into ADR-0010 local-admin wrapper for vault reads (automatic for soft_private content) - **Phase C**: hard-private content stays in physical-separation tier (Włóczykij); never reaches redactor 4. **Operator confirmation gate** before any agent uses redactor on real vault content (vs fixtures). ## Out of scope - Replacing physical separation (Włóczykij). Operator's intuition: physical-separation-first is safer architectural principle than read-time filtering. Redactor is defense-in-depth, not replacement. - Pseudo-anonymization for non-vault content (e.g. Signal messages, Matrix room messages) — separate issue if needed. - Public release of the redactor pipeline (operator's choice; default: private). ## Phase Phase 07 (extension of ADR-0010 local-admin tier) OR Phase 08 if Phase 07 implementation budget is tight. ADR draft can land in Phase 07; spike runs in Phase 07; implementation possibly Phase 08. ## Acceptance criteria - [ ] ADR-0015 (pseudo-anonymization read-layer) drafted and reviewed - [ ] Spike confirms <500ms latency on operator's actual notes (Polish content) - [ ] Audit-log schema specified - [ ] Phased rollout proposal includes operator-confirmation gates per phase - [ ] Integration with ADR-0010 capabilities.yaml documented ## Refs - Operator voice-note 2026-05-11 07:26 (introduced concept + linked openai/privacy-filter) - ADR-0010 (local-admin LLM tier) — this issue extends it - ADR-0012 (Phase 07 scope-lock) — this addition needs scope-lock amendment if it lands as Phase 07 - PR #171 comment (Włóczykij architecture inversion clarifies physical-separation-first) - Model: https://huggingface.co/openai/privacy-filter - Repo: https://github.com/openai/privacy-filter ## Coordination - Lane: Phase 07 design (advisor + executor) - Owner: claude-orchestrator drafts ADR; operator approves; codex implements if approved - Operator: provides sample vault notes for spike; reviews PII detection quality on Polish content **Role:** advisor (claude) **Inspired by**: operator's voice-note imagery — *"mnisi doskonałości jakby przeglądali i to sortowali"* (monks of perfection curating overnight). The redactor is the morning-after layer for the monks' work.

claude referenced this issue

2026-05-17 18:11:53 +02:00

docs(specs): secrets-pipeline-foundation-v0 prebuild (#237) #335

claude referenced this issue from a commit

2026-05-17 18:15:07 +02:00

docs(specs): vault-to-infisical-migration-v0 prebuild (#64)

claude referenced this issue

2026-05-17 18:15:19 +02:00

docs(specs): vault-to-infisical-migration-v0 prebuild (#64) #336

claude referenced this issue from a commit

2026-05-17 18:19:03 +02:00

docs(specs): vault-tier-3-architecture-v0 prebuild (#178 + #180)

claude referenced this issue

2026-05-17 18:19:18 +02:00

docs(specs): vault-tier-3-architecture-v0 prebuild (#178 + #180) #337

claude referenced this issue from a commit

2026-05-17 18:22:20 +02:00

docs(specs): pseudo-anonymization-readlayer-v0 prebuild (#177)

claude referenced this issue

2026-05-17 18:22:40 +02:00

docs(specs): pseudo-anonymization-readlayer-v0 prebuild (#177) #338

claude referenced this issue from a commit

2026-05-17 21:28:58 +02:00

docs(specs): secrets-pipeline-foundation-v0 prebuild (#237)

codex added this to the 08 - Persona and OpenClaw product loops milestone

2026-05-19 08:36:31 +02:00

pdurlej referenced this issue from a commit

2026-05-23 10:31:04 +02:00

Merge pull request 'docs(specs): pseudo-anonymization-readlayer-v0 prebuild (#177)' (#338) from claude/pseudo-anonymization-readlayer-v0-prebuild into main

codex referenced this issue

2026-05-28 01:21:54 +02:00

chore(m08): select next one or two Persona/OpenClaw product loops #542

codex referenced this issue

2026-05-29 16:58:33 +02:00

chore(m08): select next one or two Persona/OpenClaw product loops #542

codex commented

2026-05-29 16:58:37 +02:00

Collaborator

M08 supplemental triage result: keep in M08. Iskra recommends keeping the privacy/pseudo-anonymization read-layer as relevant to safe persona/cloud-agent work; no implementation started here.

claude added the

agent/claude-code

label

2026-05-30 13:08:24 +02:00

claude added the

priority:p3

label

2026-05-30 22:43:23 +02:00

Iskra commented

2026-06-09 03:03:27 +02:00

Collaborator

{
"confidence": 5,
"effort_hint": "large",
"escalation": {
"kind": "operator",
"reason": "Pseudo-anonymized vault access defines sensitive data boundaries for cloud agents."
},
"evidence_refs": [
{
"note": "Issue proposes a pseudo-anonymization read layer for cloud-agent vault access using a privacy filter.",
"type": "forgejo",
"value": "issue-title-body-labels-and-target-snapshot"
},
{
"note": "Body frames the model as a local PII-redaction proxy where the operator sees plaintext and agents see redacted skeletons.",
"type": "forgejo",
"value": "issue-body-context"
},
{
"note": "Snapshot labels mark the issue as priority p3 with Claude Code agent context.",
"type": "snapshot",
"value": "target-snapshot-labels"
}
],
"impact": 5,
"judge_actor": {
"name": "iskra",
"runtime": "openclaw"
},
"judged_at": "2026-06-09T01:01:00Z",
"labels_to_apply": [
"judge/p1",
"judge/operator-needed"
],
"piotr_fit": "high",
"priority": "p1",
"rationale_summary": "This is P1 operator-shaped privacy architecture because cloud-agent vault access needs explicit redaction, trust, and failure-mode boundaries before implementation.",
"reach": 5,
"recommended_next_action": "operator_needed",
"rerun_reason": "no_prior_judgment",
"schema": "openclaw.judge.v0",
"target": {
"kind": "issue",
"number": 177,
"repo": "pdurlej/platform"
},
"target_snapshot": {
"body_hash": "sha256:2255de2ea0df8db85f0ff0e490aecd1856e7a21a109ff1cca4ca1de7c9a3f412",
"commit_count": null,
"evidence_hash": "sha256:fda41a3836643efa991d71a5388679d2076ef5c6b66868c9bfcef1a98f50f782",
"head_sha": null,
"labels": [
"agent/claude-code",
"priority:p3"
],
"labels_hash": "sha256:ed1eb2432179447e4422e70f699a3fbe2901a29a416c7f93623543097a1f0b3d",
"state": "open",
"title_hash": "sha256:50ddcd912e54fee01d0b52f08198824237ea619032bb137f8e85251b32c7b91a",
"updated_at": "2026-05-30T22:43:23+02:00"
},
"top_caveat": "Do not expose vault content through this layer until redaction quality, auditability, and bypass rules are tested and approved."
}

{ "confidence": 5, "effort_hint": "large", "escalation": { "kind": "operator", "reason": "Pseudo-anonymized vault access defines sensitive data boundaries for cloud agents." }, "evidence_refs": [ { "note": "Issue proposes a pseudo-anonymization read layer for cloud-agent vault access using a privacy filter.", "type": "forgejo", "value": "issue-title-body-labels-and-target-snapshot" }, { "note": "Body frames the model as a local PII-redaction proxy where the operator sees plaintext and agents see redacted skeletons.", "type": "forgejo", "value": "issue-body-context" }, { "note": "Snapshot labels mark the issue as priority p3 with Claude Code agent context.", "type": "snapshot", "value": "target-snapshot-labels" } ], "impact": 5, "judge_actor": { "name": "iskra", "runtime": "openclaw" }, "judged_at": "2026-06-09T01:01:00Z", "labels_to_apply": [ "judge/p1", "judge/operator-needed" ], "piotr_fit": "high", "priority": "p1", "rationale_summary": "This is P1 operator-shaped privacy architecture because cloud-agent vault access needs explicit redaction, trust, and failure-mode boundaries before implementation.", "reach": 5, "recommended_next_action": "operator_needed", "rerun_reason": "no_prior_judgment", "schema": "openclaw.judge.v0", "target": { "kind": "issue", "number": 177, "repo": "pdurlej/platform" }, "target_snapshot": { "body_hash": "sha256:2255de2ea0df8db85f0ff0e490aecd1856e7a21a109ff1cca4ca1de7c9a3f412", "commit_count": null, "evidence_hash": "sha256:fda41a3836643efa991d71a5388679d2076ef5c6b66868c9bfcef1a98f50f782", "head_sha": null, "labels": [ "agent/claude-code", "priority:p3" ], "labels_hash": "sha256:ed1eb2432179447e4422e70f699a3fbe2901a29a416c7f93623543097a1f0b3d", "state": "open", "title_hash": "sha256:50ddcd912e54fee01d0b52f08198824237ea619032bb137f8e85251b32c7b91a", "updated_at": "2026-05-30T22:43:23+02:00" }, "top_caveat": "Do not expose vault content through this layer until redaction quality, auditability, and bypass rules are tested and approved." }

Iskra added the

judge/operator-needed

judge/p1

labels

2026-06-09 03:03:27 +02:00