How Theron Protects Your Data

SOC analysts work with sensitive information every day — internal IPs, hostnames, usernames, file paths, and client environment details. Before any of that reaches an AI model, Theron runs it through a layered redaction system designed specifically for SOC investigation data.

This page explains how it works, why it's built the way it is, and what its limits are.

The Core Problem

Generic AI tools have no idea what's sensitive in a SOC investigation. An internal hostname, a domain user, a client's IP range — to a general-purpose AI, it's all just text. Sending raw logs and alert details to an AI model means sending your environment's data along with it.

Most tools either ignore this problem entirely, or bolt on a generic "don't share PII" warning and call it done. Neither approach holds up to how SOC analysts actually work — pasting real alert data, log excerpts, and event fields in the middle of an investigation.

Theron was built around this problem from day one. Here's the system that resulted.

Layer 1 — Automatic Redaction

Before any message reaches the AI, Theron automatically detects and replaces:

MAC addresses → [MAC_ADDRESS]
Windows SIDs → [SID]
Org-configured hostname patterns → [HOSTNAME]
Org-configured IP ranges → [INTERNAL_IP]

This happens automatically, with zero effort from the analyst. The redacted version is what gets sent to the AI, what gets stored, and what appears in the chat — the original values never leave your browser unprotected.

Layer 2 — Flagged for Review

Some data can't be identified with universal patterns. Theron flags the following for analyst review, shown as clickable chips below the message input. One click redacts each item:

All IP addresses (public and private)
Email addresses
DOMAIN\user format usernames
UPN usernames
File paths containing user directories
Hostnames and FQDNs

A hostname like FW-CORE-NYC01 or a domain like device.example-corp.com could be sensitive internal infrastructure — or it could be a publicly known reference. This step exists because no automated system can reliably tell the difference between "internal hostname" and "any other alphanumeric string" without knowing an organization's specific environment — and we deliberately don't want that information stored insecurely (more on this below).

Layer 3 — Confirm Before Sending

If any flagged items remain unredacted when an analyst hits send, Theron shows a final warning: "Some flagged items were not redacted. Send anyway or go back?"

This isn't a hard block — analysts retain control over their own investigation data. But it ensures nothing sensitive is sent by accident. A junior analyst who doesn't yet know what's sensitive gets a meaningful pause before it happens, not a silent gap.

Layer 4 — Org Redaction Patterns

Every organization names its devices differently, and uses different internal IP ranges. Generic patterns can't cover this — but storing an organization's actual hostnames or network layout in a third-party database creates its own risk.

Theron's solution: managers can teach the system their organization's naming conventions without storing real device names.

A manager pastes 1-3 example device names (e.g. WK-7741-ALPHA, WK-3309-ALPHA). Theron derives a pattern describing the shape of those names — "2 letters, hyphen, 4 digits, hyphen, 5 letters" — directly in the browser. Only that pattern is saved. The example names themselves are never transmitted or stored.

The same applies to internal IP ranges: a manager can define their organization's CIDR ranges (e.g. 10.42.0.0/16) so any IP in that range is automatically redacted org-wide, for every analyst on the team.

Once configured, these patterns apply automatically — no chips, no review step. They're treated with the same confidence as the universal Layer 1 patterns.

What This Looks Like in Practice

When an analyst sends a message, they immediately see a small confirmation: "🔒 N items auto-redacted." The chat bubble itself shows the redacted version — [INTERNAL_IP], [USERNAME], [HOSTNAME] — so there's never any ambiguity about what was sent.

What We Don't Claim

No redaction system — ours or anyone else's, including enterprise DLP tools from major vendors — is 100% perfect. Context-dependent judgment calls (is this string a hostname or a product code? a username or a project name?) are inherently hard for any automated system without full knowledge of an organization's environment.

What Theron does is defense in depth: multiple layers, each catching what the others might miss, with the analyst kept informed and in control at every step. Universal patterns catch the certain cases automatically. Org-specific patterns close the gap for known environments. Flagging and confirmation catch what's left, with a human making the final call.

This is the same layered philosophy used by serious data protection tools — adapted specifically for SOC investigation work, where the data involved (logs, alerts, IOCs, environment details) doesn't look like anything a generic DLP tool is built to understand.

Questions?

If you have questions about how Theron handles data — for your team, your organization, or a specific compliance requirement — reach out at support@theronai.io.