Data Protection
Where log processing happens, what data leaves your network, symbol libraries, AI, and how to validate that security logs are not filtered.
Where does log processing happen
All processing happens in your infrastructure:
- Reporter: a DaemonSet that reads a copy of the stream and writes no events onward. It sits beside the delivery path rather than in it, so nothing it does can alter or delay what reaches your SIEM.
- Receiver: a sidecar to your forwarder (Filter or Compact mode).
- Retriever: deploys in your AWS/cloud account, not ours.
- MCP server: where your agent (Claude or your own LLM) runs to inspect patterns and propose config. The agent proposes; the Receiver enforces what you approve.
You control where processed events go via output configuration (files, forwarders, metric destinations). Log10x never receives log content.
What data does Log10x actually see
Zero log content, always. The pipeline's metric output carries aggregated per-pattern metrics to the destination the install names, which is normally a backend you own: event counts and byte volumes grouped by enrichment fields, including a recurring log-pattern name derived from symbol tokens in your code. Never log messages, PII, or raw events.
What log data leaves my environment
None reaches log10x. Log content travels only where your own pipeline sends it, which is normally your SIEM. Aggregated metrics go to the backend you nominate at install; the log10x-hosted one exists for the demo and for evaluation, not as a production destination. AI analysis is optional too; the next answer covers exactly what it sends.
What specific metrics leave my network
Two separate streams, and it matters which is which. Telemetry is the authority for both, typed, with a PII column and a JSON companion; this answer is the summary.
Engine telemetry is what the engine reports about itself, and it reaches log10x only on a licensed deployment that names an endpoint. Six series, every value a count or a duration, carrying the pipeline's display name, its UUID, a parent UUID where one is set, and the host name the engine runs on. That host name, which on Kubernetes is the pod name, is the one field with any PII character. Three further labels appear only on launch failures.
Per-pattern metrics are a different stream: all_events_summaryVolume_total, all_events_summaryBytes_total and the rest, grouped by enrichment fields. Values are counts and byte volumes. A pattern name is built from the line's library words, the words compiled from code, or from a hash of its shape when it has none, so no value outside the library enters it: numbers, IDs, IPs and timestamps never do. A value that is also a library word can, so a customer or product name made of library words can reach a metric label. The shipped configs for the Receiver, the Reporter and the Retriever include no metric output, so this stream goes only where an operator points it, and it reaches log10x only when run/output/metric/log10x is added and backendEndpoint is set.
What reaches the log10x gateway, on a licensed deployment with an endpoint configured, is a best-effort startup license check carrying the license token and nothing else, the engine telemetry above, and the per-pattern stream when the log10x metric output is added. Two states send none of it. An engine with no license configured runs the built-in evaluation license, which the launcher forces air-gapped whatever the endpoint says, and TENX_AIRGAPPED=true removes every outbound call on any license type, with usage reconciled through your account contact instead. Outbound sets out all three states, and Verifying is the packet capture that settles each one.
Adding a metric output of your own does not by itself stop any of that: it is an extra destination, and the engine's own two calls are unaffected by it either way. Leaving the endpoint unset stops everything, and so does running air-gapped.
What are symbol libraries and do they contain my code
Symbol libraries contain 64-bit hashes of string constants extracted from your log statements, plus class and method names to identify the source of each log statement. They contain no source code, no log data, and no telemetry. Compilation happens in your CI/CD pipeline, we never see your repositories, code, or symbol libraries. See the Compiler FAQ for full details.
Is AI optional? What data does it send
Fully optional, and you choose how. AI analysis runs two ways:
- Bring Your Own Key, point the agent at your own model and provider
- Disabled, no data sent to any AI provider
Either way you supply the model and the key; log10x does not provide an AI key. Only aggregated metrics (event-type names, volume, cost) are ever sent to the model, never raw log content. Nothing preconfigures AI, so it is off until you enable it, and optimization works the same either way.
How do I validate that critical security logs aren't being filtered
The agent proposes which patterns to filter; you review the proposal (a pull request in your own repo) before it takes effect, and the Receiver enforces only what you approve. Several layers let you confirm your security logs are preserved:
- Shadow mode first: Deploy the Reporter as a read-only DaemonSet. It tails the live event stream pre-SIEM without modifying, filtering, or redirecting any data. Compare what would be reduced vs actual security events before the Receiver enforces anything in-path.
- Allowlist approach: Explicitly preserve all logs from security indexes. Allowlist sourcetypes like
firewall,ids,authentication. - Metrics tracking: Dropped event counts are recorded in aggregated metrics: query
all_events{routeState="drop"}to see exactly what was dropped and confirm nothing unexpected was filtered. - Recoverable on demand: Patterns the engine offloads land in your own S3, where the Retriever returns the exact offloaded events on demand if a security log is ever needed.
- Confirm it: the per-pattern metrics in your own backend show the volume kept and dropped for every pattern, including the security sources you excluded.