Guardrails
Every SDK-routed request and response is scanned locally for built-in PII and credential patterns. Matches are recorded on spans as guardrail attributes; normal SDK traffic is never blocked or rewritten.
SDK behaviour
The transport uses scan-and-record behaviour:
- Prompt and response continue unchanged.
- Match names are recorded as
guardrail.violation. guardrail.actionis recorded aswarn.- A guardrail or telemetry failure never prevents the provider call.
This is intentional. Observra's gateway and provider call remain authoritative for request success or failure.
Built-in patterns
| Name | Matches |
|---|---|
email | Email addresses |
credit_card | Digit sequences shaped like payment cards |
ssn | US Social Security numbers such as 123-45-6789 |
phone | Common US and international phone-number formats |
api_key | Long sk-... keys |
generic_token | Long obs, ghp, gho, or xox tokens |
Patterns are regular expressions. False positives are possible; treat matches as observability and safety signals, not compliance enforcement.
Bounded scanning
Only the first 50,000 characters of a payload are scanned. Remaining content continues unchanged and unscanned. This bounds local work for unusually large prompts and responses.
Direct checker
Advanced code can use the internal checker directly for warn, redact, or block decisions. This module is not part of the stable top-level public API, so pin and test against your SDK version if you depend on it.
from observra.guardrails.check import GuardrailViolation, check_payload
try:
result = check_payload("My SSN is 123-45-6789.", mode="block")
except GuardrailViolation as error:
print([violation.pattern_name for violation in error.violations])
Modes:
warn: return violations and leave payload unchanged.redact: return a result whoseredacted_payloadmasks matches.block: raiseGuardrailViolationwhen any match exists.
Direct checker modes do not change the SDK transport's scan-and-record policy.