Why infer approvals but leave unrecognized calls untagged?

[mahirhir]

Two choices in the README point opposite ways and I would like to know how you settled them.

Unrecognized tool calls carry no ATT&CK tag rather than a guess. Approvals go the other way: a tool that runs after a prompt is treated as approved, marked inferred:*, and that is the large majority of gates.

I think I see why. A blank tag costs nothing, while a blank approval would break sequence rules that need a gate event to correlate against.

The part I cannot tell from the docs is what happens to the marker downstream. Does inferred: survive the ECS and UDM mappings, or can it be normalized away before an analyst reads the event?

[blitzcrieg1]

Your reading is right, and there is a stronger version of it.

A missing ATT&CK tag is a gap in enrichment. Nothing downstream needs it to exist, and a wrong technique id is worse than none, because an analyst pivots on technique_id and a guess sends them somewhere real that never happened.

A missing approval is a gap in a chain. No IDE reports the human's click, so if we recorded nothing the trail would say a gated action ran with no gate, which is indistinguishable from an agent that bypassed one. The absence would be a stronger and falser claim than the inference.

So the asymmetry is not conservative versus permissive. Both choices refuse to assert something we did not see. One refuses by staying silent, the other refuses by labelling what it did instead.

The marker is load-bearing inside the engine too

Worth knowing before the SIEM question. approval-denied-then-executed skips inferred denials outright:

if str(_action(event).get("reason") or "").startswith("inferred:"):
    continue

Ingest synthesises denied responses for asks still pending at session end. Treating those as a human saying no convicted every later call of the same tool and produced twelve criticals on one ordinary Cursor session. So the prefix is not decoration; a rule reads it.

Your actual question, checked rather than answered from the docs

I ran a synthetic approval_response carrying reason: "inferred:tool_ran_after_prompt" through both mappings:

ECS carries 'inferred:' at: event.reason, agentmetry.action.reason
UDM carries 'inferred:' at: metadata.description

It survives both. But not equally, and you have found something.

In ECS it lands in two places, including the namespaced passthrough, so an analyst can filter on it.

In UDM it survives only inside metadata.description, which is free text. Filtering means string-matching a description rather than querying a field, and anything that rewrites or truncates descriptions on the way in would take it with no error. That is thinner than it should be for a marker a detection rule depends on.

So the honest answer to "can it be normalized away" is: not by us today, and far more easily in UDM than in ECS.

What should change

inferred should be a structured boolean on the approval, not a string prefix on a free-text reason. The prefix works because everything reading it today lives in this repository. It stops working the moment the consumer is somebody else's parser, which is the entire point of shipping ECS and UDM.

Additive to schema 1.2.0, and the prefix stays for compatibility. Filing it now and crediting the question.