The parsing tax: why AI agents need telemetry in one schema

Three dialects, one shape

The agent is doing data engineering before it does security

Every AI agent that investigates an alert works the same way underneath. It is handed a question and a pile of evidence, and it reasons over whatever arrives in its context window. The context window is the working memory of a large language model (LLM): the text it can see at once. You pay for every token that goes into it, and everything the model spends understanding the shape of the evidence is capacity it cannot spend understanding what the evidence means.

When the evidence is raw vendor telemetry, a surprising amount of that capacity goes on translation. One identity provider calls the person actor.alternateId. Another calls them userPrincipalName. The Windows event log calls them TargetUserName and writes a different format of the same name. One source says a login failed with outcome.result: FAILURE, another with status.errorCode: 50126, a third with the hexadecimal status 0xC000006D. Before the agent can notice that one person failed to log in three times from the same address, it has to work out that these are the same kind of event, about the same person, meaning the same thing.

We call that the parsing tax. It is paid on every investigation, it is paid before the agent thinks once, and it is invisible on the bill because it looks exactly like the agent working.

This piece explains where the tax comes from, what removing it does to the quality of an investigation and to what each investigation costs, and why the fix belongs in the pipeline and the lake rather than in the prompt.

One failed login, three dialects

Take the most ordinary security event there is: somebody typed the wrong password. Here is the same failure as three common sources record it, with the field names exactly as each vendor documents them.

• Okta writes a System Log event with eventType: user.session.start and outcome.result: FAILURE. The person is in actor.alternateId, usually their login address, and the address they came from is in client.ipAddress.
• Microsoft Entra ID writes a sign-in log entry with the person in userPrincipalName and the reason as an error code, status.errorCode: 50126, which Microsoft documents as an invalid username or password.
• Windows writes security event 4625, “an account failed to log on”, with the account in TargetUserName, often as a short account name rather than an address, and the reason in Status: 0xC000006D, which Microsoft documents as a bad username or bad authentication information.

As each source writes it

One shape the agent reads

Okta System Log

eventType:

user.session.start

outcome.result:

FAILURE

actor.alternateId:

dana.garcia@example.com

Microsoft Entra ID sign-in log

userPrincipalName:

dana.garcia@example.com

status.errorCode:

50126

ipAddress:

203.0.113.24

Windows security event 4625

TargetUserName:

dgarcia

Status:

0xC000006D

IpAddress:

203.0.113.24

Your control layer

Parse, enrich and normalize, in flight

Identity resolved from your directory

OCSF Authentication, class_uid 3002

metadata.product.name:

Okta

activity_id:

1 (Logon)

status_id:

2 (Failure)

status_code:

FAILURE

user.email_addr:

dana.garcia@example.com

OCSF Authentication, class_uid 3002

metadata.product.name:

Microsoft Entra ID

activity_id:

1 (Logon)

status_id:

2 (Failure)

status_code:

50126

user.email_addr:

dana.garcia@example.com

OCSF Authentication, class_uid 3002

metadata.product.name:

Windows

activity_id:

1 (Logon)

status_id:

2 (Failure)

status_code:

0xC000006D

user.email_addr:

dana.garcia@example.com

Values are illustrative. Field names are as Okta, Microsoft and OCSF document them. One person, three failures, the same fields.

A human analyst who has worked all three consoles reads these as one story without effort. An agent handed them raw has to rebuild that knowledge inside its context every time, from the field names alone. It has to decide that 50126 and FAILURE and 0xC000006D belong to the same category. It has to guess that dgarcia and dana.garcia@example.com might be the same person, and it has no way to confirm the guess, because the directory that links them is not in the evidence. Sometimes it gets this right. Often it gets it partly right. Every attempt costs tokens.

Normalized, each event is mapped across to the same fields. In the Open Cybersecurity Schema Framework (OCSF), all three become the Authentication class, class_uid 3002, with activity_id 1 for a logon and status_id 2 for a failure. Each keeps its original code in status_code and its product in metadata.product.name, and the person is one user.email_addr, resolved against the directory during enrichment. The agent receives three records that already mean the same thing, and goes straight to the question that matters: is this a person who forgot a password, or somebody trying passwords?

What changes for the agent: quality first

The most important effect of normalization is not cost. It is that the same model, with the same prompt, reaches better conclusions.

The clearest public test of this we know of is a benchmark published in February 2026 by Gruve.ai, an AI security services company, run with the normalization vendor Fleak.ai. It is a vendor-published benchmark on a single dataset, and it reports qualitative results rather than measured token counts, so read it as an illustration of the mechanism, not as a number to plan against. The design was simple. One set of Zscaler Private Access logs with attacks hidden in it, one LLM agent acting as a behavioral analytics engine, one identical system prompt. The only variable was the data: raw vendor logs in one run, the same logs normalized to OCSF in the other.

Three findings from that test are worth knowing, because they show what the parsing tax does to an investigation.

One person, recognized as one person. In the raw run, a single user was treated as three separate entities, because the same account arrived in three formats as the logs drifted. Behavioral analysis depends on building a profile of what is normal for each person, so a person split three ways has three thin profiles and no real baseline. Normalized, the account became one actor.user.name across every event, and the profile became accurate. This is entity resolution, and nothing about it depends on the model being clever. It depends on the data already agreeing with itself.

Service accounts told apart from people. In the raw run, a service account moving a lot of data was flagged as a human exfiltrating it, which is the kind of false positive that teaches an analyst to stop reading the agent’s output. Normalized, the event carried an actor type, and the agent classified the traffic as benign service behavior and suppressed it. The context was not in the model. It was in the record.

A lateral move seen as a path. In the raw run, connection attempts to several internal addresses were read as isolated, unrelated events. Normalized, the agent linked them into a sequence, user to endpoint A to B to C, and raised it. The same run also caught a policy brute force pattern that the raw run had dismissed as a configuration error.

None of these improvements came from a better model or a better prompt. They came from the agent no longer having to reconstruct the meaning of the data before it could use it. That is the part of AI triage nobody can buy as a feature, and it is why we treat the data layer as the foundation of any agent we build rather than as a preprocessing detail. We made the same argument from the other side in why most alerts are never investigated: an analyst drowning in inconsistent alerts and an agent drowning in inconsistent fields are the same problem.

What changes on the bill: cost second

Once the quality point is clear, the cost point follows from it.

An agent’s cost per investigation is driven by how much it reads and how many turns it takes to reach a verdict. Raw telemetry inflates both. The records are longer, because vendor payloads carry nested objects and fields nobody needs for the question. The reasoning is longer, because the model spends turns disambiguating before it analyzes. And the answer is less reliable, which means more follow-up queries, more escalations to a larger model, and more human review.

Normalized and enriched records are shorter, consistent and already joined to the context the agent needs. The agent reads less, asks fewer clarifying questions of its own evidence, and reaches a verdict in fewer turns. Across thousands of alerts a month, that difference is a line on the AI bill.

There is a second, larger effect. Clean, consistent data is what makes it safe to give routine work to a small, inexpensive model. A small model struggles with messy, heterogeneous input, which is why teams reach for the largest model available and pay for it on each alert it reads. When every login, every process event and every network flow arrives in the same shape, a small model can do the endless routine work, the low-severity alerts, the compliance lookups, the “has this host done this before” questions, and the large model is kept for the investigations that earn it. We describe that split in Phase 03 of the Logmetry Blueprint. Choosing a model per task is a control you only have when you own the data layer, and normalization is what makes the cheap choice a good one.

We do not quote a percentage for this saving, and we would be wary of anyone who does without showing their measurement. The size of the parsing tax depends on how many sources you run, how inconsistent they are, and how much of each record your agents read. What is certain is the direction.

What changes when a tool changes: portability third

The third effect is the one that compounds over years.

A detection rule written against a vendor’s field names works for that vendor. When you add a second identity provider, you write a second rule. When a vendor renames a field without notice, which vendors do, the rule silently stops matching and nobody finds out until something is missed. The same is true of an agent prompt that refers to vendor fields, and of every saved query in the lake.

Written against a shared schema, one rule covers every source that maps to it. A brute force detection written against the OCSF Authentication class works for Okta, Entra ID and Windows at once, and for the next identity provider you add, because the mapping is done once in the pipeline rather than again in every rule. Swapping a SIEM, adding a destination or changing an identity provider becomes a change to one mapping, not a rewrite of your detection content. That is vendor agnosticism expressed in data, and it is the same argument that makes a control layer in front of your platforms worth owning.

Not one schema: two open standards that join

It is common to hear this described as “normalize everything to one schema”. The accurate version is slightly different, and it matters when you design a lake.

Security events and observability signals have their own open standards, each governed in the open and backed by the major vendors.

• OCSF for security events. The Open Cybersecurity Schema Framework defines event classes such as Authentication, Network Activity and Process Activity, with a shared dictionary of attributes. It became a Linux Foundation project on 19 November 2024, with AWS, Splunk, Cisco, IBM and Broadcom quoted in support at the announcement, and it is the format Amazon Security Lake stores.
• OpenTelemetry semantic conventions for metrics, logs and traces. OpenTelemetry (OTel) is the open standard for collecting telemetry, and its semantic conventions define the names for hosts, services, HTTP requests, databases and the rest. In April 2023 Elastic and the OpenTelemetry project announced that the Elastic Common Schema (ECS) would converge into the OpenTelemetry semantic conventions, making them the successor to ECS.

The two meet on shared keys: the host, the service, the user and the trace ID. That join is what lets one agent follow a security alert into the infrastructure underneath it, from a suspicious login to the service that account runs, to the host that service lives on, to the trace of the request that failed. It is the reason one lake can serve a security triage agent and a root cause agent at the same time, and it only works if both halves were normalized with the join in mind.

Where normalization belongs

Normalization can happen in three places, and only one of them removes the tax.

In the prompt. You can tell the agent how each vendor names its fields and hope it applies the mapping. This is the parsing tax, paid on every call, and it breaks the first time a vendor changes a field.

At query time. You can store raw data and map it when you search, the way some SIEM data models work. This keeps storage simple and pushes the cost into every query and every agent read, and the mapping lives inside one product.

In flight, before the data lands. The pipeline parses each source, enriches it with the context the source never knew, which team owns the host, which directory identity sits behind a short account name, whether an address is internal, and writes it to the lake in the open schema. Every consumer afterwards, the SIEM, the lake, the analyst, the agent, reads data that already means something. This is where we do it, as code in your repositories, so every mapping is reviewed, versioned and testable, and a vendor’s field change is caught by a test instead of by a missed detection.

The honest caveat is that the mapping is judgment, not a lookup table. Deciding which of OCSF’s event classes a given log belongs to, which enrichment matters for which question, and how to resolve identities across systems that were never designed to agree is the real work. Tools that generate mappings automatically can accelerate it. They do not remove the need for someone who understands your estate to decide what the mapping should be.

What to ask about your own estate

Three questions tell you how much parsing tax your agents are paying, or will pay once you deploy them.

1. What schema is your lake in today? If the answer is the schema of the SIEM it came from, or “whatever the source sent”, every agent that reads it will do its own translation.
2. When your agent reads a login from your identity provider and a login from Windows for the same person, does it know it is one person? If identity resolution is not in the data, it is being guessed in the context window.
3. If you swapped one identity provider or one SIEM tomorrow, how many rules, queries and prompts would you rewrite? The number is a measure of how much of your detection content is written against vendor dialects instead of an open schema.

If the answers are uncomfortable, the fix is not a better model. It is a foundation. We explain how we build that foundation, and why it comes before any agent, on the AI token efficiency page and in what AI native actually means.