[Enterprise Gap] Preserve operational PII through policy-bound disclosure instead of blanket masking

[seonghobae]

Buyer-visible problem

OriginWeave must support real enterprise workflows in which names, contact details, account identifiers, delivery information, customer records, and other personal data are operational inputs. Blanket masking can make the delegated task impossible or produce false evidence. The opposite design—placing raw personal data in every service, log, model prompt, trace, export, and support channel—creates unacceptable security, privacy, tenant-isolation, and audit risk.

The product needs a third architecture:

Keep authoritative personal data usable by explicitly authorized business processes while replacing ambient propagation with purpose-bound, field-level, just-in-time disclosure and complete access evidence.

This issue defines engineering controls. It does not claim CSAP certification, SOC 2 conformity, or legal compliance by itself. Release readiness requires review against the law, certification criteria, system boundary, contracts, deployment region, and actual operating procedures effective at that time.

Required bounded vertical slice

Create an independently reusable Rust originweave-sensitive-data authority and provider-neutral service contract. It must govern every transition from an authoritative sensitive-data store to a human UI, deterministic browser action, extraction pipeline, model request, external connector, export, support tool, or audit record.

No caller receives raw values merely because it is inside the network, owns a session, or can name a database field. Every disclosure is a separate resource-access decision.

Data classification and authoritative storage

• Define versioned field classifications such as public_data, internal_data, personal_data, sensitive_personal_data, credential_data, payment_data, and customer-defined classes.
• Store authoritative values in a bounded sensitive_data_record behind tenant and subject boundaries.
• Separate searchable non-sensitive metadata from protected values; do not duplicate raw values into generic event stores, vector stores, caches, or analytics tables.
• Use envelope encryption at rest with a versioned encryption_key_reference; support customer-managed keys, region policy, rotation, revocation, and cryptographic deletion evidence.
• Use authenticated transport for every disclosure path and bind service identity to policy decisions.
• Permit reversible tokenization, deterministic encryption, or format-preserving transforms only when a documented workflow requires joins, deduplication, or legacy-format interoperability. Record residual risk and collision/domain constraints.
• Never treat hashing as anonymization when the value space is enumerable or linkable.

Purpose-bound authorization

Evaluate a typed sensitive_data_request using at least:

• tenant identity;
• human, workload, service, and device identity;
• authenticated session and task identity;
• requested field identifiers and record scope;
• declared business purpose;
• action type;
• destination origin or connector;
• model/provider/region when AI is involved;
• requested retention and export behavior;
• data-subject or customer policy;
• current risk and break-glass state.

Return one of:

• deny_access;
• opaque_handle_only;
• derived_value_only;
• partial_field_disclosure;
• full_field_disclosure;
• human_approval_required;
• dual_control_required.

Network location, repository membership, administrator role, or possession of a model API key must never imply full disclosure.

Opaque handles and secret/data broker

• Give the planner and model an opaque sensitive_value_handle by default, not the underlying value.
• Allow typed actions such as fill_sensitive_field, compare_sensitive_value, validate_address, or send_to_approved_connector without returning the value to the model.
• Resolve handles only inside a narrowly scoped broker or trusted browser adapter after rechecking task, origin, field, purpose, freshness, and approval.
• Bind each handle to one tenant, task, field set, destination class, expiry, maximum use count, and non-transferable audience.
• Prevent handles from being serialized into long-term model memory, URLs, screenshots, telemetry, crash dumps, clipboard history, or user-visible provenance.
• Revoke handles on task completion, policy change, key rotation, session termination, or suspicious use.

Selective model disclosure

Raw personal data may enter a model context only when all of the following hold:

• the workflow cannot be completed with an opaque handle, deterministic transform, local rule, structured tool, or approved derived value;
• the exact fields and purpose are authorized;
• the selected provider, model, region, retention mode, training policy, and subprocessors are permitted for the tenant and classification;
• the request has a bounded prompt, output schema, token budget, expiry, and no unrelated conversation history;
• high-risk categories receive human or dual-control approval where policy requires it;
• output is validated and retained according to a separate policy;
• a credential-free audit receipt records what class and field identifiers were disclosed without copying their values.

Support an enterprise policy that requires local or private inference for selected classes. A provider outage or policy mismatch must fail closed, not silently fall back to a less trusted model.

Operational usability without blanket masking

Authorized human interfaces and deterministic tasks must still be able to use full values where the job requires them:

• address a shipment;
• complete an approved form;
• contact a named customer;
• reconcile an account;
• investigate an incident;
• satisfy a verified data-subject request;
• export an authorized record set.

Usability requirements:

• disclose only the fields needed for the current step;
• clearly identify why access was granted and when it expires;
• avoid permanent masked copies that diverge from the authoritative record;
• provide copy/reveal/export actions only under explicit capability and policy;
• preserve accessibility and keyboard operation without exposing values in hidden DOM, accessibility labels, analytics, or screenshots unnecessarily;
• support a controlled break-glass flow with reason, approval, time limit, heightened monitoring, and post-event review.

Logging, evidence, and observability

Never place raw protected values in:

• application logs;
• traces and span attributes;
• metrics labels;
• exception messages;
• GitHub issues, CI logs, or test snapshots;
• WARC/PROV exports unless a separate retention and access policy explicitly authorizes protected evidence;
• model prompts or responses outside the approved disclosure contract;
• analytics events, support bundles, crash reports, or alert payloads.

Emit immutable sensitive_access_evidence containing:

• request and decision identifiers;
• tenant, actor, workload, task, and device identifiers;
• data classification and field identifiers, never field values;
• purpose and destination;
• policy and control versions;
• approval/break-glass references;
• handle issuance, resolution count, expiry, and revocation;
• model/provider/region and retention policy when applicable;
• encryption-key reference and rotation epoch without key material;
• decision time, disclosure time, completion time, and retention deadline;
• success, denial, partial disclosure, or policy-change outcome;
• cryptographic hash chaining or equivalent tamper-evident sequencing for audit exports.

Tenant isolation and service identity

• Enforce tenant identity at every repository, cache, queue, object-storage, search, vector, model, export, and audit boundary.
• Use workload/service identities and explicit authorization, not shared static credentials.
• Bind service-to-service disclosure to authenticated identities and narrowly scoped policy.
• Reject confused-deputy requests where an authorized service is asked to disclose to an unauthorized destination.
• Make cross-tenant support access disabled by default and separately approved.
• Test data residency and provider-region policy as executable contracts.

Retention and lifecycle

• Attach a retention_policy_record to authoritative values, derived values, model artifacts, exports, and evidence.
• Distinguish task-local ephemeral use, operational record retention, legal hold, customer-configured retention, and audit retention.
• Propagate deletion and revocation to caches, search indexes, vector indexes, temporary files, model caches, exports, and backup expiry workflows.
• Produce deletion receipts without retaining the deleted value.
• Prevent a model summary, embedding, screenshot, or provenance artifact from becoming an undeclared permanent copy.

CSAP and SOC 2 evidence mapping

Create a versioned control_evidence_mapping rather than claiming certification from code alone.

For CSAP readiness, map the deployed service boundary, assets, organizations, support services, identities, encryption, access control, audit, incident response, change management, supply-chain evidence, tenant isolation, data location, and continuity evidence to the currently applicable KISA certification type and criteria. Record evidence owners, collection cadence, exceptions, and assessor-facing artifacts.

For SOC 2 readiness, map controls and evidence to the AICPA Trust Services Criteria categories actually included in management's system description—security, availability, processing integrity, confidentiality, and privacy. Preserve the distinction between:

• product capability;
• configured control;
• operating control;
• collected evidence;
• management assertion;
• independent examination result.

No UI, documentation, or release note may state “CSAP certified”, “SOC 2 compliant”, or equivalent without the corresponding valid certification or independent report for the defined system and period.

Realistic tests

Use realistic end-to-end workflows rather than only unit-level redaction tests:

• an authorized shipment task fills a full name and address into the exact approved origin without exposing either value to the planner, logs, or evidence;
• a model receives opaque handles and approved derived values while raw fields remain absent from captured requests;
• an explicitly approved private-inference workflow receives only its allowed fields and fails closed when provider, region, model, or retention policy changes;
• a deterministic browser fill rechecks the origin, document epoch, field identity, purpose, expiry, and use count immediately before disclosure;
• unauthorized actor, wrong tenant, wrong task, stale handle, wrong field, wrong origin, wrong connector, replay, and confused-deputy cases fail;
• break-glass access requires reason and approval, expires, emits heightened audit, and cannot become a reusable role grant;
• field-level access produces complete evidence with no protected value bytes;
• log, trace, metric, crash, support-bundle, screenshot, clipboard, WARC, PROV, model-cache, and exception scanners find no unapproved value occurrence;
• key rotation, key revocation, tenant deletion, retention expiry, backup expiry, and legal hold produce the expected accessible/unavailable states;
• concurrent requests cannot cross tenant, task, or handle audiences;
• service identity and mTLS/token audience mismatch fail closed;
• property tests and fuzzing cover hostile Unicode, oversized identifiers, path/query injection, serialization ambiguity, race conditions, and policy-version changes;
• production function, line, region, and branch coverage are exactly 100%, with complete public rustdoc.

Use synthetic or explicitly approved test identities. Live-test fixtures must never use production personal data.

Database object naming

Every database object must contain at least two words and use snake_case. Suggested objects:

sensitive_data_record
sensitive_field_definition
sensitive_data_request
sensitive_access_decision
sensitive_value_handle
sensitive_access_evidence
business_purpose_record
field_disclosure_policy
tenant_security_policy
model_disclosure_policy
provider_region_policy
encryption_key_reference
retention_policy_record
approval_evidence_record
break_glass_event
control_evidence_mapping
audit_sequence_record
deletion_receipt_record

Architecture and documentation

• Add an ADR explaining why blanket masking and ambient raw access are both rejected.
• Add a threat model covering prompt injection, confused deputy, insider access, compromised service, compromised model provider, cross-tenant access, log leakage, export leakage, stale handles, and key compromise.
• Add Mermaid data-flow and sequence diagrams for handle issuance, browser fill, selective model disclosure, break-glass access, deletion, and audit export.
• Update AGENTS.md, CLAUDE.md, ARCHITECTURE.md, README.md, CHANGELOG.md, docs/product-roadmap.md, docs/quality-gates.md, and docs/doctoring.md.
• Document the service boundary and evidence responsibilities for standalone deployment and use as a naruon/CWL shared module.
• Require a legal/compliance review checkpoint before release; engineering tests are necessary but not sufficient legal conclusions.

Commercial proof

A buyer can complete a workflow that genuinely requires personal data, while replay evidence proves that only the exact authorized fields were disclosed to the exact authorized process, origin, connector, or model for the exact purpose and period. The same test corpus proves that unauthorized actors, services, models, destinations, tenants, logs, traces, exports, and long-term memories never receive the values.

Standards and authoritative references — APA 7th

American Institute of Certified Public Accountants. (2023). 2017 trust services criteria for security, availability, processing integrity, confidentiality, and privacy (with revised points of focus—2022). https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022

Chandramouli, R., & Butcher, Z. (2023). A zero trust architecture model for access control in cloud-native applications in multi-cloud environments (NIST Special Publication 800-207A). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207A

Korea Internet & Security Agency. (n.d.). 클라우드서비스 보안인증제 제도소개. Retrieved August 7, 2026, from https://isms.kisa.or.kr/main/csap/intro/index.jsp

Republic of Korea. (2025). 개인정보 보호법 (법률 제20897호, 시행 2025년 10월 2일). 국가법령정보센터. https://www.law.go.kr/법령/개인정보보호법

Republic of Korea. (2026). 개인정보 보호법 시행령 (대통령령 제36340호, 시행 2026년 5월 19일). 국가법령정보센터. https://www.law.go.kr/법령/개인정보보호법시행령

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207

Out of scope

Formal legal opinions, certification issuance, independent SOC examination, payment-card authorization, biometric-template design, national-identifier-specific business rules, customer master-data remediation, unrestricted support access, production key custody, or release of raw personal data to unapproved models/providers are outside this issue. They require separately scoped controls, contracts, operations, and review.

[seonghobae]

Current implementation lineage update (2026-08-10): protected main already contains the Accepted ADR 0007 purpose-bound policy kernel and credential-free sensitive-access evidence foundation. Draft PR #45 is now the bounded next slice: immutable handle lifecycle evidence (request/decision correlation, trusted issue/expiry epochs, maximum uses, observed resolution count, optional revocation epoch) in the existing originweave-evidence crate, with no opaque handle token and no protected value field. It does not implement the trusted broker, storage/encryption/KMS, atomic use reservation/enforcement, browser fill, model/provider disclosure controls, tenant persistence, or the standalone originweave-sensitive-data service; therefore it cannot close this issue.

A stale feat/sensitive-data-broker scaffold branch also exists, but it is not current implementation authority and is not being revived here: adding its workspace crate would require lockfile governance that the scheduled actor is not authorized to change for this task. Do not create a parallel broker/scaffold lane without first revalidating current main, lockfile authority, #45, and that stale branch.

[seonghobae]

Sensitive-data lineage has advanced beyond the earlier #45-only note while preserving the same truth boundary. Active work now includes #45 lifecycle evidence, #46 bounded authoritative in-process use reservation, #53 explicit revocation composition, #55 audience binding, plus PR #63 (3059fead1ef0b6cf2f7df765b03c4b00a669b9cf) proving that an extension granted only ProposeTypedAction still cannot widen secret-delivery authority: raw FillSecret is denied as SecretBrokerRequired, broker-handle FillSecret still reaches the ordinary R3 approval boundary, and broker material on a non-secret action is denied as UnexpectedSecretMaterial. PR #63 is exact-head green and Ready for review.

This does not close the enterprise gap. The authenticated workload/service-identity boundary, protected-value storage/resolution, encryption/KMS, cross-process transactional handle lifecycle, deterministic browser fill without model exposure, selective model disclosure, retention/deletion propagation and durable audit/export controls remain unimplemented on protected main. The canonical docs line on #44 records these as active/non-shipped evidence rather than broker completion.