Every time sensitive data is detected and masked, it gets logged. The matched text is HMAC-hashed so you have a full audit trail without storing the actual PII.
Each detection creates a log entry with everything you need for an audit, but nothing that exposes the original data
What kind of sensitive data was found โ email, SSN, phone number, credit card, medical record number, etc.
The redacted version that was sent to the LLM. You can see exactly what the model received.
When the detection happened, down to the millisecond. Useful for correlating with other system events.
A unique ID that ties the detection back to the specific API request. Easy to cross-reference with your own logs.
A one-way hash of the actual matched text. You can verify if a specific value was detected without us ever storing it in plain text.
Which API key triggered it, which project it belongs to, and whether it was in the request or the response.
Three steps, fully automatic. You don't need to change anything in your code.
Our guardrails scan every request and response. When something sensitive is found โ like an email, phone number, or SSN โ it gets flagged and masked before reaching the LLM.
The detection is recorded with the PII type, masked value, request ID, and an HMAC hash of the original text. The raw value is never stored anywhere.
All log entries are available in your dashboard and via API. Filter by date, PII type, API key, or project. Export them whenever you need them for compliance reviews.
Storing the original PII would defeat the purpose of masking it. But you still need a way to answer the question: "Was this specific value ever detected?"
HMAC hashing solves this. We hash the matched text with a secret key. The hash is stored in the log. If an auditor wants to check whether a particular email or SSN was ever caught, they hash that value and look for a match. Simple, and the original data never sits in a log file.
Example detection record
PII Type
EMAIL_ADDRESS
Masked Value
[EMAIL_REDACTED]
HMAC Hash
a1b2c3d4e5f6...9k0l
Request ID
req_8f3a...
Timestamp
14:32:07.421
Auditors want proof that sensitive data is being handled properly. This gives them exactly that.
HIPAA
PHI detection logging with the "minimum necessary" standard. You can prove data was masked without retaining it.
SOC 2
Audit trail of all data protection events. Exactly what auditors look for during Type II reviews.
GDPR
Evidence that personal data was identified and protected before being processed by third-party models.
PCI-DSS
Cardholder data detection and masking records. Shows that card numbers never reach the LLM in plain text.
Pull up every PII detection for a given time period. Show auditors exactly what was caught, when, and how it was handled. No scrambling.
If someone reports that sensitive data might have leaked, use the HMAC hash to check if that exact value was ever detected and masked.
See which PII types are being caught most often. Spot false positives. Adjust your guardrail rules based on real data, not guesses.
Break down detections by project, API key, or time period. Useful for understanding which teams or apps are handling the most sensitive data.
Available on Pro plans and above. Starts logging the moment you enable guardrails.