Solutions · Compliance

Find sensitive data before it spreads.

Tero finds PII, PHI, payment data, secrets, tokens, and risky payloads in the telemetry you already store, raises issues with evidence, and routes safe redaction policies to the tools you already run.

Engineers log payloads when they are debugging. Tero finds what slipped through.

PIIPHIPayment dataSecretsAuth headersTokensRisky payloads

Point of view

Sensitive data does not stay put.

Sensitive data usually enters logs innocently.

Someone logs a payload to debug production. An error handler includes headers. A service dumps an object because the team needs to see what is happening. Nobody is trying to create a compliance problem.

But logs travel.

They move through agents, collectors, pipelines, vendors, security tools, archives, object storage, data lakes, and internal exports. By the time someone finds a sensitive field, the question is no longer just what matched. It is where it came from, where it went, who owns it, and how to stop more from spreading.

Brute-force scanning tries to solve this by inspecting everything for every sensitive pattern all the time. That gets expensive fast, and it treats a timestamp like a request body and a route like an authorization header.

Tero takes the downstream truth and turns it into targeted control.

It finds what actually landed, shows masked examples, owner, destination, volume, and raw evidence, then proposes a redaction policy where telemetry flows.

Tero does not promise sensitive data can never enter telemetry. It gives teams a better loop: find what leaked, understand where it spread, stop more from spreading, and keep evidence attached to the work.

Ben Johnson

Founder, Tero
Creator of Vector

Tero Index

Finds sensitive data across the estate.

Tero Issues

Makes sensitive data inspectable.

Tero Actions

Contains it with Telemetry Policies.

01 · Tero Index

Tero Index finds sensitive data across the telemetry estate.

The index builds maintained context over event types, field shapes, representative examples, destinations, service ownership, and links back to raw records.

For compliance, that context answers the questions that matter: what sensitive data is present, where does it appear, which service emits it, where is it being sent, and how severe is the exposure?

Not one vague "PII detected" label. Sensitive data has shape, and different shapes carry different risk and require different handling.

Sensitive data · masked examples18 services

Payment datapan=[.... .... .... 4242]HIGH

Identity data[email protected]MEDIUM

Regulated identifiersssn=...-..-8812HIGH

Health datadiagnosis=[........]HIGH

Secretsauthorization: Bearer eyJ......CRITICAL

Risky payloadsbody={ 2.4 KB serialized object }MEDIUM

02 · Tero Issues

Tero Issues makes sensitive data inspectable.

A compliance finding should not be a vague alert that says "sensitive data detected."

It should show the field, masked examples, affected service, destination, volume, owner, raw evidence, severity, and recommended action.

That matters because sensitive-data cleanup has to be reviewable. The team needs to know what was found, where it went, why it matters, who owns it, and what changed afterward.

03 · Tero Actions

Tero Actions contains sensitive data with Telemetry Policies.

The long-term fix may be a code change, but compliance issues need containment before that work lands. Redact or remove the field where telemetry flows: with evidence, review, ownership, and measurement attached.

Contain the exposure now, preserve lineage, and follow up in code with the full issue context.

Now officially part of OpenTelemetry ↗

Policy spec ↗Policy examples ↗How policies work ↗

checkout-api / redact-auth-header.yamlRedact

id: POL-1059
name: "Redact auth header from checkout logs"
description: "Created from ISS-2. Contain now, fix in code."
log:
  match:
    - resource_attribute: [service.name]
      exact: checkout-api
    - log_field: headers.authorization
      exists: true
  redact:
    - log_field: headers.authorization
      replacement: "[REDACTED]"
labels:
  - key: issue_id
    value: ISS-2

Policy runtime

Telemetry Policies run in the tools you already run.

Open-source Tero distributions run the policy engine inside the collector, agent, or pipeline you already operate. You install nothing new and replace nothing.

Approved policies sync to the runtime, and every runtime reports back hits, drops, and measured impact. One compiled matching pass keeps latency flat from ten policies to ten thousand.

Benchmarks ↗Distributions ↗

Raw telemetry

Clean signal

Host

OTel CollectorTero policy enginewasm

Find it before the audit does.

Sensitive data surfaces as issues continuously, not in the audit, not in the breach review.

Masked evidence, not vague alerts.

Every finding shows the field, masked examples, destination, and owner, reviewable without re-exposing the data.

Contain now, fix in code with context.

Redaction policies stop the exposure immediately; the issue carries full context to the code fix.

Redact where telemetry already flows.

Policies run in the collector, agent, or pipeline you already operate: reviewable, reversible, measured.

See what sensitive data is
already in your telemetry.

Masked examples, owners, destinations, and the safest redaction path — from your own stores.

Get a demo

Read-only connectionNothing to deployNo pipeline changesMasked evidence only