Skip to main content
Zero risk Credit card numbers, emails, SSNs, access tokens. Sensitive data that ended up in logs by accident. A developer logs a request object. An error message includes data it shouldn’t. A third-party library dumps more than you expected.

​
Why it happens

Developers log context for debugging. Sometimes that context includes sensitive fields. A payment service logs the full request body. An auth service logs tokens for troubleshooting. An error handler dumps the entire user object. Nobody intends to leak PII. But it happens. And once it’s in your observability provider, you have a compliance problem.

​
Example

{
  "@timestamp": "2024-01-15T10:30:00Z",
  "service.name": "payment-service",
  "event": "payment.processed",
  "card_number": "4111111111111111",
  "amount": 99.99
}
Tero generates the following policy:
id: redact-credit-card-payment-service
name: Redact credit card numbers from payment-service
description: Drop card_number field containing credit card data.
log:
  match:
    - resource_attribute: service.name
      exact: payment-service
    - log_attribute: card_number
      regex: "^[0-9]{13,19}$"
  transform:
    remove:
      - log_attribute: card_number
Each PII pattern gets its own policy. You approve them individually based on your compliance requirements.

Enforce at edge

Redact PII before data leaves your network. The data never reaches your provider.

Open PRs

Fix the instrumentation so PII is never logged in the first place.
Edge enforcement is critical here. Redacting at the edge means the sensitive data never leaves your infrastructure. No cleanup timeline. No breach notifications. The blast radius is zero because the data never reached your provider. But you should also fix the source. Open a PR to remove the sensitive fields from the log statement entirely.

​
How it works

Tero scans log content for patterns that match sensitive data using regex patterns from gitleaks, a widely-used open source project for secret detection. When Tero finds sensitive data, it identifies the field and the service. You can then redact (replace with [REDACTED]), hash (replace with a consistent hash for correlation), or drop the field entirely.

​
Supported patterns

Each category below can be approved as a set of policies. Approve the categories relevant to your compliance requirements.
  • Credit card numbers (Visa, Mastercard, Amex, Discover)
  • Social Security numbers (US)
  • National Insurance numbers (UK)
  • Email addresses
  • Phone numbers
  • IP addresses
  • IBANs
  • AWS access keys and secret keys
  • GCP API keys
  • Azure AD client secrets
  • Alibaba access keys
  • DigitalOcean tokens
  • Heroku API keys
  • Cloudflare API keys
  • Databricks API tokens
  • GitHub tokens (PAT, OAuth, App, Fine-grained)
  • GitLab tokens (PAT, Deploy, Runner, CI/CD job)
  • Bitbucket client secrets
  • Travis CI tokens
  • CircleCI tokens
  • Drone CI tokens
  • Slack tokens (bot, user, webhook)
  • Discord tokens
  • Telegram bot tokens
  • Microsoft Teams webhooks
  • Mattermost tokens
  • Twilio API keys
  • Database connection strings
  • Planetscale tokens
  • MongoDB connection strings
  • Redis connection strings
  • Elasticsearch credentials
  • Stripe API keys
  • Square access tokens
  • Plaid API tokens
  • Coinbase access tokens
  • GoCardless tokens
  • OpenAI API keys
  • Anthropic API keys
  • Hugging Face tokens
  • Cohere API tokens
  • Datadog access tokens
  • New Relic API keys
  • Grafana API keys
  • Sentry tokens
  • Dynatrace API tokens
  • Notion API tokens
  • Asana client secrets
  • Linear API keys
  • Jira API tokens
  • Shopify access tokens
  • SendGrid API tokens
  • Mailchimp API keys
  • Private keys (RSA, DSA, EC, PGP)
  • JWTs
  • PKCS12 files
  • Age secret keys