Skip to content
TruthVouch Docs

Auditable Sensitive Data Reveal

Sensitive data — personally identifiable information (PII), secrets, prompt text, quarantined content — is masked by default throughout TruthVouch. This prevents accidental exposure while maintaining full audit transparency.

The Auditable Sensitive Data Reveal process allows authorized users to view masked data through a justified, role-based, immutable audit trail that meets SOC 2 and GDPR requirements.

Sensitive Data Types

The following data is masked by default:

PII (Personally Identifiable Information)

  • Names, email addresses, phone numbers
  • Social Security numbers, passport numbers
  • Driver’s license numbers
  • Financial account numbers
  • Home addresses

Secrets & Credentials

  • API keys, authentication tokens
  • Database connection strings
  • Private encryption keys
  • System passwords
  • SSH keys

Prompt Text

  • Full system prompts (masked in inventory views)
  • User prompts containing sensitive input
  • Internal system prompts with corporate knowledge

Quarantined Content

  • Outputs blocked by governance policies
  • Toxic, unsafe, or policy-violating content
  • Outputs flagged for manual review
  • PII-containing LLM responses

Request Logs

  • System prompts in LLM API call logs
  • User input containing sensitive information
  • API responses with confidential data

Controlled Reveal Process

Step 1: Request Reveal

When a user encounters masked data, they request access:

  1. Click [REDACTED] badge on masked content
  2. Click Request Reveal
  3. Select Reason (dropdown):
    • Compliance Audit
    • Security Incident Investigation
    • Customer Support (with ticket #)
    • Operational Debugging
    • Other (with explanation)
  4. Provide Business Justification (required):
    • Why you need to see this data
    • What problem you’re trying to solve
    • Expected outcome
  5. Submit request

Step 2: Authorization

Authorized users receive notifications and review the request:

  • Request details: Who, what data, when, justification
  • Requestor profile: Role, department, previous reveals
  • Risk assessment: How sensitive is the requested data?
  • Approve/Reject decision

Requests are typically approved/rejected within 1 business day.

Step 3: Reveal & Audit Trail

Upon approval:

  1. Data is revealed to authorized user only
  2. Session is marked as “sensitive data access”
  3. All interactions are logged (every page view, copy, download)
  4. Timestamp recorded: when reveal was granted, when accessed, when session ended
  5. Requestor and approver both notified

The reveal session expires after:

  • 1 hour of inactivity
  • End of business day
  • Or manual revocation by the approver

Step 4: Immutable Audit Trail

Every reveal action creates an immutable audit log entry:

{
  "timestamp": "2024-03-10T14:32:15Z",
  "action": "sensitive_data_reveal",
  "requestor_id": "alice@company.com",
  "requestor_role": "Engineering Manager",
  "approver_id": "bob@company.com",
  "approver_role": "Security Officer",
  "data_type": "prompt_text",
  "resource": "chatbot_system_prompt_v3",
  "justification": "Debugging customer support chatbot malfunction in Europe region",
  "session_duration": "42 minutes",
  "actions_in_session": [
    {"action": "view", "timestamp": "2024-03-10T14:33:02Z"},
    {"action": "copy", "timestamp": "2024-03-10T14:35:47Z"},
    {"action": "download", "timestamp": "2024-03-10T14:41:33Z"}
  ],
  "ip_address": "203.0.113.42",
  "device": "MacBook Pro (Chrome)"
}

Role-Based Access

Only users with specific roles can reveal masked data:

PII Viewer Role

Can reveal: Names, emails, phone numbers, addresses

Cannot reveal: Secrets, prompt text, system details

Typical users: Customer support, compliance officers

Approval requirement: No approval needed (role-based access control)

Secrets Viewer Role

Can reveal: API keys, passwords, connection strings, system prompts, quarantined content

Cannot reveal: PII (separate governance)

Typical users: Infrastructure engineers, platform security team, incident responders

Approval requirement: Yes, always requires written justification

Compliance Officer Role

Can reveal: All data types for audit investigations

Approval requirement: For audit purposes, Compliance Officer approval is recorded but not required

Special capability: Can export audit logs for regulatory proof

Administrator Role

Can reveal: All data (but actions are still logged)

Approval requirement: Yes, administrative reveals always require approver (cannot self-approve)

Integration with Compliance Frameworks

SOC 2 Type II Compliance

TruthVouch’s reveal process satisfies SOC 2 requirements for:

  • Access Control (CC6.1) — Only authorized roles can reveal sensitive data
  • Audit Logging (A1.2, CC7.2) — All reveal actions logged immutably
  • Change Management (CC7.1) — Justification recorded for every access
  • Incident Response (CC9.2) — Audit trail available for investigations

Auditors can verify that sensitive data access is:

  • ✓ Authorized (proper roles and approvals)
  • ✓ Justified (documented business reason)
  • ✓ Auditable (immutable tamper-proof log)
  • ✓ Accountable (identity verified, IP logged)

GDPR Compliance

For GDPR Article 32 (security of processing) and Article 33 (breach notification):

  • Minimal exposure — Sensitive data masked by default, revealed only when necessary
  • Documented justification — Why access was needed (GDPR “lawful basis”)
  • Right to audit — Organizations can prove how PII was handled
  • Data subject requests — Audit trail supports transparency requests (“who accessed my data?”)

Auditing & Monitoring

Reveal Activity Dashboard

View all sensitive data access:

Reveal Activity Log (last 30 days)


Mar 10, 2024, 14:32 | alice@company.com | Approved by bob@company.com
  → Prompt text reveal (chatbot_system_prompt_v3)
  → Justification: Debugging customer support issue
  → Duration: 42 minutes
  → Devices: 1 (MacBook Pro)


Mar 09, 2024, 09:15 | carol@company.com | Approved by dave@company.com
  → PII reveal (customer_email)
  → Justification: Escalated customer support ticket #45821
  → Duration: 8 minutes
  → Devices: 1 (Windows Desktop)

Trend Analysis

Track reveal patterns:

  • Who reveals most often? — Identify power users, investigate anomalies
  • What data is accessed? — Hotspots of sensitive data interest
  • When are reveals highest? — Incident windows, after-hours spikes
  • Approval latency — How quickly are requests approved?
  • Rejection rate — Why are some requests denied?

Anomaly Detection

Automatic alerts on suspicious activity:

  • After-hours reveals — Access outside business hours
  • Bulk reveals — Many reveals in short timeframe
  • Unusual requestor — New requestor accessing sensitive data
  • Cross-department reveals — Reveal by user from different team
  • Repeated denials — User requesting repeatedly without approval

Best Practices

For Requestors

  • Be specific — “Debugging customer issue #5821” is better than “general debugging”
  • Use ticket numbers — Link to customer support or incident tickets
  • Short reveals — Request only during active debugging, not for casual browsing
  • Minimize scope — If possible, request reveal for specific field, not entire record

For Approvers

  • Fast review — Aim for < 1 hour approval time (SLA: 4 hours)
  • Risk assessment — Adjust approval criteria based on data sensitivity
  • Escalate suspicious requests — Any unusual patterns should trigger investigation
  • Regular audits — Monthly review of reveal approvals for compliance

For Administrators

  • Set policies — Define approval requirements per role and data type
  • Monitor trends — Weekly dashboard reviews
  • Train users — Ensure teams understand reveal process and proper justification
  • Export for auditors — Monthly/quarterly audit log exports for SOC 2 evidence

Reveal Examples

Scenario 1: Customer Support Debug

Requestor: Sarah (Support Manager) Data: Customer email address (PII Viewer role) Justification: “Escalated customer issue #8392 — customer reports not receiving password reset emails. Need to verify email address in system.” Approval: Auto-approved (PII Viewer role doesn’t require approval) Access: 3 minutes, viewed email Audit log: Shows Sarah’s access, justification, and brief session

Scenario 2: Security Incident

Requestor: Alice (Infrastructure Engineer) Data: Database API keys in system prompt (Secrets Viewer role) Justification: “SECURITY INCIDENT: Automated alert detected unusual database queries. Need to review system prompt to verify if API keys were exposed in logs.” Approval: Approved by Bob (Security Officer) within 15 minutes Access: 28 minutes, viewed prompt, copied to secure editor Audit log: Shows Alice’s access, Bob’s approval, 3 copy actions, IP address, device fingerprint

Scenario 3: Compliance Audit

Requestor: Carol (Compliance Officer) Data: All PII accessed in past 90 days (Compliance Officer role) Justification: “Annual SOC 2 audit — validating that PII access is properly controlled and logged.” Approval: Compliance Officer approval recorded (for audit proof) Access: 2+ hours, reviewed 47 PII reveal events Audit log: Shows full access timeline, export of audit logs for auditor

Troubleshooting

Q: I requested reveal 2 hours ago, still waiting for approval. A: Check your notifications for approval decision. If still pending, your approver may be out. Escalate to another authorized approver or security team.

Q: Can I approve my own reveal request? A: No. All reveals require a second person to approve (prevents unauthorized access).

Q: I revealed data by accident. Can I “unreveal” it? A: The reveal is permanent (immutable audit trail). However, the brief access is logged and can be reviewed. For Secrets Viewer data, notify your security team immediately (may need to rotate credentials).

Q: How long does reveal access last? A: Typically 1 hour or end of business day. After 1 hour of inactivity, you’re logged out and must request reveal again.

Next Steps