> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usetero.com/llms.txt
> Use this file to discover all available pages before exploring further.

# PII leakage

> Sensitive data that ended up in logs

PII leakage occurs when logs contain personal data, credentials, secrets, payment data, or other sensitive values that don't belong in observability storage.

Common sources include request-object logging, error messages that include user input, verbose third-party libraries, and instrumentation that records more fields than intended.

## Signals

| Signal                    | Description                                                                                                         |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Sensitive field name      | Field names such as `card_number`, `email`, `ssn`, `api_key`, or `token`.                                           |
| Sensitive value pattern   | Values match known formats for payment cards, secrets, credentials, or identifiers.                                 |
| Free-form message content | A text field contains sensitive substrings inside an otherwise routine message.                                     |
| High-risk field type      | Request bodies, error messages, user input, and metadata fields can contain sensitive data through developer error. |

## Example

<Tabs>
  <Tab title="Credit card numbers">
    <Tabs>
      <Tab title="Before">
        ```json theme={null}
        {
          "@timestamp": "2024-01-15T10:30:00Z",
          "service.name": "payment-service",
          "event": "payment.processed",
          "card_number": "4111111111111111",
          "amount": 99.99
        }
        ```
      </Tab>

      <Tab title="After">
        ```json theme={null}
        {
          "@timestamp": "2024-01-15T10:30:00Z",
          "service.name": "payment-service",
          "event": "payment.processed",
          "amount": 99.99
        }
        ```
      </Tab>
    </Tabs>

    ```yaml theme={null}
    id: redact-credit-card-payment-service
    name: Redact credit card numbers from payment-service
    description: Remove 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
    ```
  </Tab>

  <Tab title="Email addresses">
    <Tabs>
      <Tab title="Before">
        ```json theme={null}
        {
          "@timestamp": "2024-01-15T10:30:00Z",
          "service.name": "user-service",
          "event": "user.updated",
          "user_id": "usr_abc123",
          "email": "alice@example.com"
        }
        ```
      </Tab>

      <Tab title="After">
        ```json theme={null}
        {
          "@timestamp": "2024-01-15T10:30:00Z",
          "service.name": "user-service",
          "event": "user.updated",
          "user_id": "usr_abc123"
        }
        ```
      </Tab>
    </Tabs>

    ```yaml theme={null}
    id: redact-email-user-service
    name: Redact email addresses from user-service
    description: Remove email field containing user email addresses.
    log:
      match:
        - resource_attribute: service.name
          exact: user-service
        - log_attribute: email
          exists: true
      transform:
        remove:
          - log_attribute: email
    ```
  </Tab>

  <Tab title="API keys in messages">
    <Tabs>
      <Tab title="Before">
        ```json theme={null}
        {
          "@timestamp": "2024-01-15T10:30:00Z",
          "service.name": "integration-service",
          "body": "Request failed with key sk_live_abc123xyz789..."
        }
        ```
      </Tab>

      <Tab title="After">
        ```json theme={null}
        {
          "@timestamp": "2024-01-15T10:30:00Z",
          "service.name": "integration-service",
          "body": "Request failed with key [REDACTED]"
        }
        ```
      </Tab>
    </Tabs>

    ```yaml theme={null}
    id: redact-api-key-integration-service
    name: Redact API keys from integration-service logs
    description: Redact Stripe API keys found in log messages.
    log:
      match:
        - resource_attribute: service.name
          exact: integration-service
        - log_field: body
          regex: "sk_live_[a-zA-Z0-9]+"
      transform:
        redact:
          - log_field: body
            pattern: "sk_live_[a-zA-Z0-9]+"
            replacement: "[REDACTED]"
    ```
  </Tab>
</Tabs>

## Recommended enforcement

<CardGroup cols={2}>
  <Card title="Enforce at edge" icon="server" href="/policies/enforcement/edge">
    Redact or remove sensitive values before data leaves your network.
  </Card>

  <Card title="Open PRs" icon="code-pull-request" href="/policies/enforcement/open-prs">
    Change source instrumentation so sensitive values are not logged.
  </Card>
</CardGroup>

Use edge enforcement to stop matched values from reaching the provider. Open a PR when the source statement should stop emitting the field.

Tero creates one policy per PII pattern, and you approve each on its own.

## Detection notes

Tero uses the [Master Catalog](/master-catalog) to understand fields, including what each field represents, what values it contains, and why it exists. Tero uses that context to determine which fields are scanned for PII.

Tero scans fields that can carry PII through developer error, including `error_message`, `request_body`, `user_input`, and free-form text fields. It skips fields with fixed formats that are structurally incompatible with PII, such as `timestamp`, `severity`, `status_code`, and `pid`.

Tero detects PII using patterns from [gitleaks](https://github.com/gitleaks/gitleaks), an open source project for secret detection.

<AccordionGroup>
  <Accordion title="Personal information">
    * Credit card numbers (Visa, Mastercard, Amex, Discover)
    * Social Security numbers (US)
    * National Insurance numbers (UK)
    * Email addresses
    * Phone numbers
    * IP addresses
    * IBANs
  </Accordion>

  <Accordion title="Cloud providers">
    * 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
  </Accordion>

  <Accordion title="Source control & CI/CD">
    * 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
  </Accordion>

  <Accordion title="Communication & collaboration">
    * Slack tokens (bot, user, webhook)
    * Discord tokens
    * Telegram bot tokens
    * Microsoft Teams webhooks
    * Mattermost tokens
    * Twilio API keys
  </Accordion>

  <Accordion title="Databases & infrastructure">
    * Database connection strings
    * Planetscale tokens
    * MongoDB connection strings
    * Redis connection strings
    * Elasticsearch credentials
  </Accordion>

  <Accordion title="Payment & financial">
    * Stripe API keys
    * Square access tokens
    * Plaid API tokens
    * Coinbase access tokens
    * GoCardless tokens
  </Accordion>

  <Accordion title="AI & ML services">
    * OpenAI API keys
    * Anthropic API keys
    * Hugging Face tokens
    * Cohere API tokens
  </Accordion>

  <Accordion title="Observability & monitoring">
    * Datadog access tokens
    * New Relic API keys
    * Grafana API keys
    * Sentry tokens
    * Dynatrace API tokens
  </Accordion>

  <Accordion title="SaaS & productivity">
    * Notion API tokens
    * Asana client secrets
    * Linear API keys
    * Jira API tokens
    * Shopify access tokens
    * SendGrid API tokens
    * Mailchimp API keys
  </Accordion>

  <Accordion title="Cryptographic material">
    * Private keys (RSA, DSA, EC, PGP)
    * JWTs
    * PKCS12 files
    * Age secret keys
  </Accordion>
</AccordionGroup>