Version: v1.1.0
This page documents behavior guaranteed in TealTiger v1.1.0. TealTiger emits two types of operational outputs: audit events for compliance evidence, and logs for debugging and monitoring. Both are structured and redaction-safe by default.
Logs vs Audit Events
Think of them like this:- Audit events = Your security camera footage (evidence for compliance)
- Logs = Your system health monitor (debugging and operations)
Audit events (evidence)
Use audit events when you need:- Compliance evidence - Prove what happened for auditors
- Incident response - Investigate security incidents
- Forensics - Reconstruct past decisions
- Decision outcome (allow/deny/redact)
- Reason codes (why the decision was made)
- Correlation IDs (link related events)
- Policy identifiers (which policy applied)
- Redaction indicators (what was redacted)
Logs (operations)
Use logs when you need:- Debugging - Figure out why something isn’t working
- Monitoring - Track system health and performance
- Alerting - Get notified of issues
- Component lifecycle events
- Performance metrics
- Error conditions
- Integration status
Do not treat logs as compliance evidence. Use audit events for compliance.
Default logging posture
TealTiger logging is secure by default: ✅ Structured - Key/value pairs, not unstructured text✅ Redaction-safe - Sensitive data excluded by default
✅ Correlation-ready - Includes trace IDs for distributed tracing
❌ No prompts - User prompts excluded by default
❌ No responses - Model outputs excluded by default
❌ No secrets - API keys and tokens never logged
What logs include
Safe operational data:What logs exclude
Sensitive data that could leak: ❌ Raw user prompts❌ Model completions
❌ API keys or tokens
❌ PII (names, emails, phone numbers)
❌ Tool payload values
❌ Full error stack traces with user data
If you need to log additional fields for debugging, apply redaction first and keep them out of production.
Log levels
TealTiger uses standard severity levels:Examples
Configuring log output
Console logging (default)
File logging
Custom logger
Exporting to observability platforms
OpenTelemetry
Datadog
Best practices
- Use INFO in production - Avoid DEBUG unless troubleshooting
- Monitor WARN logs - They indicate potential issues
- Alert on ERROR logs - Set up alerts for failures
- Correlate with traces - Use trace_id to link logs and audit events
- Separate logs and audit - Send to different destinations
- Rotate log files - Prevent disk space issues
- Redact before logging - If you add custom fields, redact first
Related reading
Audit Event Schema
Complete audit event structure
Cost Metadata
Track AI spending
Audit and Redaction
Security-by-default approach
OpenTelemetry Integration
Export to observability platforms

