OCSF Without the Parsers: How Grepr AI Maps New Log Sources and Catches Schema Drift

Grepr knows every unique pattern in your logs, and Grepr AI maps new log patterns to OCSF, repairs the mapping when a source changes, and tells you exactly what changed. No need to write parsers, and your original data is kept intact.

Learn how it works by watching this demo video.

Security tools work best with clean, consistent data, but log sources rarely provide it: sshd writes free text, your auth gateway writes access logs, and next week a new service shows up with a format nobody has seen. Someone has to write the parser, map it to a schema, and keep it working when the source changes.

OCSF (the Open Cybersecurity Schema Framework) solves the schema half. It's the common format that AWS Security Lake, Splunk, and a growing list of SIEMs understand. Getting your logs into it still takes hand-written parsers and mappings, and nobody tells you when a source changes underneath them. 

The problem: parsers that break quietly

• Every source logs differently. The same failed login looks different in sshd, your VPN, and your web app.
• Every new source is a ticket. Each one needs a parser, a mapping, a test, and a deploy before your detections can use it.
• Changes are silent. A deploy can rename or drop a field without an obvious error. Detections that depend on it can quietly miss events.

‍

How Grepr AI solves it

Grepr identifies every unique pattern in your log stream (think of them as unique “fingerprints”). When a new fingerprint appears, or an existing one changes, Grepr turns that into a signal. For security data, two kinds of changes matter most:

1. A new log. A new source, a new service, or a new event type nobody has mapped yet.
2. A change in log shape. The same message as yesterday, but with fields added or removed.

Grepr AI identifies both scenarios above by reading the logs in context and deciding which of the following actions to take:

1. A new log: Map the new log to OCSF
2. A log change: Repair the mapping and report exactly how the log changed

In either scenario, you don’t need to write a rule.

Scenario 1: New logs become OCSF on their own

When a new log arrives, Grepr AI initiates the following end-to-end process:

1. Picks the OCSF class. Failed SSH logins map to Authentication. User creation maps to Account Change.
2. Writes the parser and the mapping. Grepr AI pulls out details such as the user and source IP, then maps them to the matching OCSF fields.
3. Tests the change on your real logs. Before touching the pipeline, Grepr AI runs the change against live traffic, with nothing written anywhere, and checks the output against the OCSF schema.
4. Updates the pipeline. With auto-apply on, tested changes go live right away. If you want a human in the loop, switch the agent to "Require human approval," and every change becomes a suggestion you review first.

When a new event type, such as ‘user creation’ shows up, Grepr AI adds a mapping within minutes without anyone touching the pipeline. Existing mappings stay exactly as they were.

Your original data is never lost

No security team will trust a mapper that throws data away, which is why Grepr enforces the guardrails itself instead of leaving them to the agent's judgment:

• Originals are always kept. Every field the source sent is preserved under unmapped, the convention OCSF defines and AWS Security Lake follows.
• Mappings only grow. The agent can add a mapping for a new log type, add fields to an existing one, or give a field a fallback when its source renames it. It can't change or remove anything a mapping already writes.
• No dropping, no rerouting. The agent can't delete events or send them to a new destination.
• Strict OCSF on top. Only OCSF fields sit at the top level.

Scenario 2: A log change

The logs you already rely on change too. A deploy renames a field, drops one, or adds a few, often without any error, and your detections start missing events.

Because Grepr’s Autonomous Telemetry Pipeline tracks the shape of every pattern, that change is a signal too. In our demo, you’ll notice a deploy rename a field in the failed-login log: node.ip becomes node.ip_address. Nothing errors, but the OCSF mapping reads node.ip for the destination IP, so every new failed login would quietly arrive without one. Grepr AI compares the new shape with what the same message looked like before, sees one field disappear and another appear with the same values, and recognizes the rename. It repairs the mapping so the destination IP falls back to the new field: logs that still send node.ip come out exactly as before, and renamed logs get their destination IP back. Then it posts the difference in a Slack message containing the following: 

• Service
• Message
• When it started
• Keys added and removed, and what it changed in the mapping
• A sample log
• A link to the full investigation.

You can configure the Grepr AI agents to take any actions as you please. Our demo instructed the agent to add the fields mentioned above as part of what it posts to Slack.

Why it matters for security teams

• No parser backlog. New log types get mapped as they appear, not when someone gets to the ticket.
• Schema changes don't break your mappings. You see exactly which fields changed, and the mapping is already repaired, instead of finding out after a detection misses something.
• Every change is tested first. Grepr AI tries each change on your real logs before applying it, and every investigation keeps its reasoning and steps for review.

Try it out: Design partnership is open

We’re actively seeking design partners to provide feedback on what we’re building. In exchange, you’ll get to run Grepr AI for free. If you’d like to join the program, reach out to us.

FAQ

What is OCSF?

‍The Open Cybersecurity Schema Framework is an open standard for security events. It gives every kind of event, like an authentication or an account change, a fixed set of fields, so tools such as AWS Security Lake and Splunk can read data from any source the same way.

What triggers Grepr AI?

‍Grepr’s Autonomous Telemetry Pipeline captures every unique log pattern and its shape. A pattern it has never seen before, or a known pattern whose fields changed, becomes a signal that starts an investigation. You don't write alert rules.

Does Grepr AI change my pipeline without approval?

‍Only if you let it. Each agent has a setting: auto-apply tested changes, or record them as suggestions for a person to review and apply.

How does Grepr validate the agent's changes and keep it grounded?

‍Every change starts from your real logs. Before it is applied, it is tested against live traffic in a dry run, and its output is checked against the OCSF schema. Grepr then enforces its own rules on top. Each investigation records its reasoning and steps, so you can review exactly what it did and why.

How/Where does schema drift detection get reported?

‍It depends on how you configure the agent. In the demo it was configured to report the service, the message, when the new shape first appeared, the exact keys added and removed, what it changed in the mapping, a sample log, and a link to the investigation, posted to Slack.

‍