TBW / AI SECURITY / USE CASE
Sensitive Data Protection in AI Workflows
Classify, redact and route sensitive information before model access, and keep unnecessary sensitive values out of logs and traces.
The Problem: Sensitive Values Move Through More Than Prompts
An employee may paste a customer record into a chat, attach a file with payroll fields or trigger a workflow that retrieves a confidential document. Protecting only the initial prompt misses extracted text, tool results and generated answers. A different failure occurs when the model request is clean but a verbose error trace preserves the original payload.
Detection also varies by source and format: a number resembling an account ID is not always sensitive, while a scanned document may hide an identifier that a simple pattern misses. The workflow needs a declared classification and handling decision at each boundary, not a blanket claim that every value has been anonymized.
A Data Boundary Before and After the Model
Input → Classify → Detect → Redact/Tokenize → Route → Model → Output Check → Controlled Reinsertion → Audit. Identify the source, owner and permitted purpose before parsing a prompt or file. Detect sensitive fields in the actual content sent downstream, choose irreversible removal when the answer does not need the original, and use reversible tokens only when an authorized result requires restoration. A routing policy decides whether a sanitized request can use an approved model destination or must stay in a controlled environment.
Inspect the generated answer before release for sensitive disclosure, including memorized context, quoted tool output or an unapproved restored token. Reinsertion is a separate authorized operation after output checks, not an instruction to the model to reconstruct hidden values. Audit decisions, policy versions and outcomes without recording the protected values themselves.
Architecture and an Illustrative Routing Policy
Classify and detect
Combine source labels and owner rules with patterns, dictionaries, classifiers or ML detectors appropriate to the data. Evaluate false positives and false negatives on representative, permissioned examples, including OCR and unusual formatting. Escalate uncertain classifications rather than silently downgrading them.
Transform and route
Redaction removes a value when restoration is unnecessary. Tokenization replaces it with an opaque reference held in a secured mapping vault when an approved recipient must see the original. The model sees neither the vault nor its keys; enforce access, encryption, retention and deletion on mappings.
Check and release
Validate the destination before a model request, scan the answer against the original classification, then authorize any reinsertion for the intended user and channel. A blocked request or answer needs an exception path with named approval and a recorded reason, not an unlogged bypass.
Illustrative policy only — adapt to the organization’s classification scheme and vendor agreements: low-sensitivity content may go to an approved managed model; sensitive content goes to a controlled processing route with stronger restrictions; restricted content is not sent to an external model. A label alone does not grant access: requester identity, purpose, destination, source permissions and retention rules still apply. This is a design example, not a claim about TBW’s or any customer’s implemented policy.
Controls at Every Data Exit
- Classification ownership: name data classes, source owners, approved destinations and a rule for unknown or newly added sources. Treat attachments, extracted text, retrieval snippets and tool responses as inputs to the same policy.
- Detector evaluation: test patterns, dictionaries and classifiers on permissioned positives and negatives; review misses and excessive redaction by source and format, then version the rule set.
- Allow, block and exception: enforce routing outside the model; log only the policy decision and exception approver. Expire exceptions and re-evaluate when the source or destination changes.
- Vault and transport: encrypt token mappings in transit and at rest, isolate access to reinsertion, set retention/deletion limits and test unauthorized retrieval and key rotation.
- Minimal telemetry: do not store unnecessary sensitive values in prompts, logs, traces, analytics, crash reports or debug captures. Apply the rule to errors and third-party observability as well as normal requests.
- Leakage tests: red-team prompt injection, quoted source passages, output reconstruction and cross-user token use; add failures to regression tests before expanding traffic.
Pilot Artifacts
- A source-to-destination data map identifying classification owner, model route, approved user and retention boundary.
- A detector test set with labeled permitted examples, misses, false alarms and a process for adding new formats.
- A redaction-versus-tokenization decision record, including vault owner, access policy, reinsertion condition and deletion behavior.
- A route and exception matrix showing allow/block decisions for each tested class and destination.
- A logging inventory and regression checklist covering input, output, retrieval, errors, traces and downstream analytics.
These are proposed design deliverables, not evidence that a customer control is deployed.
Measure Protection Without Invented Results
On a labeled, permissioned test set, track detector precision and recall alongside false positives by format. Verify routing correctness for each class/destination combination, sample logs and traces for prohibited values, and count exception requests, approvals and expirations. Check both legitimate task completion and blocked leakage attempts after rule changes. Establish baseline and acceptance thresholds with the owner; no deployment performance or customer outcome is asserted here.
Start with One Workflow and One Sensitive Class
- Observe: choose one workflow and one data class, map uploads, retrieved context, model destinations, answers and telemetry. Collect a permissioned evaluation set without copying production secrets into the pilot.
- Evaluate: run detectors and candidate transformations in a controlled mode; inspect misses, false alarms, route decisions and output leakage. Review whether restoration is genuinely necessary before provisioning a token vault.
- Enforce narrowly: enable allow/block routing and answer checks only after owners approve the policy and exception path. Monitor sampled logs, source changes, vault access and user impact, then expand class by class.
Failure Modes to Test
| Risk | Mitigation and test |
|---|---|
| Unusual format evades detection | Add scanned, nested and oddly formatted samples to the labeled set; hold uncertain inputs for review rather than silently allowing a lower-trust route. |
| Excessive redaction harms the task | Measure false positives and task utility together; adjust scoped rules with owner approval instead of turning protection off globally. |
| Token mapping vault is compromised | Separate model and vault access, encrypt and rotate keys, minimize mapping lifetime, audit reinsertion and exercise unauthorized-access tests. |
| New source lacks classification | Default to a restricted or review route until its owner assigns class, purpose and destination; test source-onboarding behavior. |
| Error path leaks raw values | Exercise timeouts, parser failures and retries; inspect logs, traces, analytics and debug captures for prohibited payload fields. |
Frequently Asked Questions
Does redaction always make a prompt safe for an external model?
No. Context can still identify a person or expose confidential facts after obvious fields are removed. Classify the whole request, verify the destination and review residual disclosure before routing.
When should a workflow tokenize instead of redact?
Use a reversible token only when a permitted downstream action genuinely needs the original value. Keep the mapping outside model access and authorize reinsertion for a specific user, purpose and output channel; otherwise remove the value irreversibly.
Can a detector guarantee that no sensitive data is missed?
No. Patterns and classifiers have false negatives, especially with scans, unusual formatting or unfamiliar sources. Test on representative examples, route uncertainty for review and re-test as formats change.
Should prompts and traces be retained for troubleshooting?
Keep only the minimum diagnostic metadata needed for the approved purpose. Avoid raw sensitive values in prompts, logs, traces, analytics and debug or error captures; set retention and access controls for what remains.
What if an answer contains a protected value that was not in the sanitized request?
Hold the answer for output checks and investigate retrieval content, tool results, model behavior and any token-reinsertion path. Block release where policy requires it, record a value-free incident trace and add the failure to regression coverage.
Scope a Data-Protection Pilot
Bring one workflow, a named data owner and a class of information that must not cross a model or logging boundary. We can map the routes, select a transformation and define the evaluation and exception checks before broader enforcement.