Building a Real-Time PII Dashboard: From Detection to Forensic Audit

Detecting PII in AI traffic is necessary but not sufficient. The compliance value comes from what you do with the detection: who gets notified, what gets recorded, and whether the record is trustworthy enough to show a regulator.

SharkRouter's governance dashboard was built around those questions. Here's how it works under the hood.

The Detection Layer

SharkRouter's PII engine inspects every request and response passing through the gateway. It runs two passes:

Pattern-based detection uses optimized regex patterns for 17 entity types:

Entity Type	Example	Confidence Method
Credit Card	4532-XXXX-XXXX-7643	Luhn algorithm validation
US SSN	XXX-XX-XXXX	Format + context
Email	user@example.com	RFC 5322 regex
Phone	+1 (555) 867-5309	E.164 normalization
IP Address	192.168.1.1	CIDR validation
IBAN	GB29NWBK60161331926819	ISO 13616 checksum
Passport	A12345678	Country-specific patterns
Medical Record	MRN: 7891234	Context + pattern
...	...	...

ML-based detection runs a lightweight classification model for context-dependent entities: person names, addresses, and organization names where pattern matching alone produces too many false positives.

Both passes run in under 5ms on the hot path. If PII is found, the gateway either blocks the request, redacts the PII, or allows it with an audit event — depending on the policy configured for that client.

The Real-Time Feed

The dashboard receives detection events via WebSocket. The server pushes events as they occur, with no polling required.

```typescript
// Client-side WebSocket subscription
const ws = new WebSocket(`wss://api.sharkrouter.ai/v1/governance/stream`);

ws.onmessage = (event) => {
const detection: PIIDetectionEvent = JSON.parse(event.data);

// Each event includes:
// - entity_type: 'credit_card' | 'ssn' | 'email' | ...
// - confidence: 0.0 - 1.0
// - action_taken: 'blocked' | 'redacted' | 'allowed' | 'flagged'
// - client_id: which tenant triggered the detection
// - timestamp: ISO 8601
// - audit_id: reference to the immutable audit record
// NOTE: actual PII values are never sent to the dashboard
};
```

The dashboard aggregates these into:

• Live feed — scrolling list of detections as they happen
• Heat map — detection frequency by entity type over the last 24 hours
• Trend charts — 7-day and 30-day detection volumes
• Client breakdown — which clients are generating the most PII-containing requests

The Audit Chain Architecture

Every PII detection event is recorded in an append-only audit log. The critical property is tamper-evidence: if anyone modifies a historical record, the tamper is detectable.

SharkRouter implements this with a double-linked structure:

Ed25519 Event Signing

Each audit event is signed with an Ed25519 private key stored in the customer's KMS. The signature covers the full event payload including:

• Timestamp
• Event content (redacted — no raw PII)
• Sequence number
• Previous event hash

```python
def create_audit_event(event_data: dict, kms: KMSClient) -> AuditEvent:
sequence_num = get_next_sequence()
prev_hash = get_last_event_hash()

payload = {
    "seq": sequence_num,
    "prev_hash": prev_hash,
    "timestamp": datetime.utcnow().isoformat(),
    **event_data
}

# Sign with Ed25519 key from KMS
payload_bytes = canonical_json(payload).encode()
signature = kms.sign(payload_bytes, key_id="audit-signing-key")

return AuditEvent(
    **payload,
    signature=base64.b64encode(signature).decode(),
    signing_key_id=kms.get_key_id("audit-signing-key")
)

```

SHA-256 Hash Chain

Each event includes the SHA-256 hash of the previous event's canonical representation. This creates a chain: you can't insert, delete, or modify any event without breaking all subsequent hashes.

```python
def verify_audit_chain(events: List[AuditEvent]) -> VerificationResult:
for i, event in enumerate(events):
# Verify sequence is contiguous
if event.seq != i + 1:
return VerificationResult(
valid=False,
broken_at=i,
reason="Sequence gap detected"
)

    # Verify hash chain
    if i > 0:
        expected_prev = sha256(canonical_json(events[i-1]))
        if event.prev_hash != expected_prev:
            return VerificationResult(
                valid=False,
                broken_at=i,
                reason="Hash chain broken"
            )

    # Verify Ed25519 signature
    if not kms.verify(event.payload_bytes, event.signature, event.signing_key_id):
        return VerificationResult(
            valid=False,
            broken_at=i,
            reason="Invalid signature"
        )

return VerificationResult(valid=True)

```

The dashboard runs chain verification on demand and displays the result. CISOs can trigger a full chain verification before exporting logs for regulators.

What CISOs Actually Use the Dashboard For

After talking to security and compliance leads at enterprise customers, we found the real use cases diverge from what we initially expected:

Compliance Reporting

The most common use is generating evidence for quarterly compliance reviews. The dashboard exports:

• PDF reports with detection counts by category and time period
• CSV exports of raw detection events (without PII values)
• Chain verification certificates proving the audit log hasn't been tampered with

These go directly into SOC 2 evidence packages, GDPR DPA reports, and internal audit presentations.

Anomaly Investigation

When something unusual happens — a spike in credit card detections, a client suddenly generating 10x their normal PII volume — the dashboard provides the drill-down path:

1. Click the spike on the trend chart
2. See the detection events for that time window
3. Filter by client and entity type
4. Export the filtered event list with audit IDs for deeper investigation

Policy Tuning

False positives in PII detection are expensive: they block legitimate requests or add latency through unnecessary redaction. The dashboard shows confidence distribution for each entity type, letting security teams identify which patterns are generating low-confidence detections and adjust thresholds accordingly.

Incident Response

When a data incident occurs, investigators need to answer: "Did this data pass through our AI systems?" The audit log provides a forensic record. Given an approximate time window and user identifier, investigators can query the log and produce a cryptographically verified record of what was detected and what action was taken.

Performance Considerations

The real-time dashboard imposes minimal overhead on the gateway:

• Event generation adds ~0.5ms to the request processing path
• WebSocket broadcasting happens asynchronously after the response is returned
• Audit writes use a write-ahead buffer with 100ms flush interval, batching events to reduce database pressure
• Chain signing happens asynchronously; events are written immediately with a pending signature, which is filled in within 500ms

For high-volume deployments processing millions of requests per day, audit events are partitioned by date and archived to cold storage after 90 days, with the chain verification state preserved for continued tamper detection.

Building Your Governance Practice

A PII dashboard is a starting point, not an end state. The organizations getting the most value from SharkRouter's governance tools have built processes around the data:

• Weekly PII review — 30-minute meeting reviewing detection trends and policy changes
• Quarterly chain verification — Run a full audit log verification before compliance reporting periods
• Incident response runbook — Documented procedure for using the dashboard during a data incident
• Policy review cycle — Annual review of PII detection thresholds and action policies

The technical infrastructure makes these processes possible. The processes make the infrastructure valuable.

---

See the governance dashboard in action: book a demo or read the audit documentation.