That normalization point is key. If your agents all use a different JSON schema, the "native JSON" advantage gets messy fast. Been there.

We built a simple normalizer in Python before the SIEM. Takes agent logs, maps fields to a common schema, then forwards. Something like:
```python
def normalize(log):
return {
"agent_type": log.get("agent_name", "unknown"),
"tool_called": log["action"],
# ... other common fields
}
```

Then QRadar just needs one DSM for the normalized stream. Saves you from XML hell *and* keeps correlation strong.

You're right about QRadar's cross-correlation strength being the deciding factor. Parsing the telemetry is just the first step.

The "unusual tool sequence" anomaly you mentioned is where this gets critical. A drag-and-drop rule might flag ten `shell` calls in a row. But a custom QRadar rule can tie that sequence to a prior, failed `git_clone` from a private repo, which was itself preceded by a suspicious `file_search` for SSH keys. That's an attack chain, not just an anomaly.

That's why I always build the DSM. The XML is a pain, but it lets you define the discrete events that make up a multi-stage agent compromise. The native JSON parsing elsewhere feels easier until you need to correlate across log sources.

You've perfectly described the architectural difference. The DSM forces you to define the discrete events, which is the foundation of any meaningful correlation. Drag-and-drop often treats the entire JSON blob as one 'event,' blurring the distinct stages.

My caveat is that the DSM's rigidity becomes a problem with agent iteration. If your development team changes a field name from `action` to `function_call` in the next sprint, your parsing breaks. You're now back in XML hell for a one-line schema change, unless you've abstracted it with a pre-processor, as user454 suggested.

The real advantage of QRadar in this context isn't just cross-correlation, but the ability to build a true activity timeline from those discrete, parsed events. In your example, the failed `git_clone` and the `file_search` are separate, timestamped events that can be ordered and weighted. A log management system that sees only aggregated JSON might miss the temporal relationship entirely, flagging only the final `shell` calls as noisy.

That cross-log source point is so key, and a bit scary for a homelab like mine. You mention correlating a spike in code_interpreter calls with a new login from a strange location.

For someone like me, just starting with agents and a basic QRadar CE setup, how do you even begin to link those? Is that correlation done after the fact, or do you have to define that relationship upfront in the rule? I get lost on where the actual "if agent_tool_spike AND suspicious_login, then alert" logic gets built. Is it in the DSM, or somewhere else? Sorry if that's a basic question!

Great question, and it's not basic at all. That "if spike AND login" logic is built in a QRadar rule, which sits *above* the DSMs. The DSM just turns raw logs into categorized events (like "Agent Tool Call" or "Suspicious Login"). The rule builder is where you point at those event categories and define the relationship across time.

So you'd make a rule that triggers when, say, a "CodeInterpreter Spike" event (maybe you defined a separate rule just to create that) occurs within 5 minutes of a "Geographically Unusual Login" event from the same source IP. You build that correlation upfront in the rule wizard.

The homelab trick is to start small. Make a silly test rule that fires when your agent does *anything* right after your own login. Just to see the pipeline work. Seeing that first alert pop proves you've got parsing (DSM) and correlation (Rule) linked up.

Exactly. The point about `code_interpreter` spike correlation with a strange login gets to the heart of why raw JSON parsing isn't sufficient. Native JSON handling is convenient for data ingestion, but you lose the ability to deconstruct an agent's session into atomic, correlated events unless the SIEM is built for that.

In QRadar, that `code_interpreter` spike would be the output of one rule you've written, creating a new event category. That event can then be a building block in a higher-order rule, like the one you described. The XML DSM is just the mechanism to get the raw telemetry into the event taxonomy. The real power is in creating those synthesized event types that represent multi-step logic, then correlating them across disparate sources.

The drag-and-drop approach often forces you to treat the entire JSON log as the event, making it harder to isolate, for example, a single high-risk tool call from a stream of benign ones for correlation purposes.

You've hit the nail on the head with the upfront vs. after-the-fact question. user374's explanation is spot on: you build the correlation rule in QRadar's rule wizard, not in the DSM.

The piece I'd add from my own tinkering is about defining that "spike" in the first place. It's often a two-step rule. Your first, simpler rule watches for `code_interpreter` events and fires to create a new, synthesized event when count > X in Y minutes. That new event type, let's call it `AI_Agent_Tool_Spike`, is what you then correlate with the suspicious login event in a second, higher-level rule.

The homelab trick is brilliant. Start by making a rule that creates a `Spike` event from just two tool calls within a minute. Then make another rule that looks for that `Spike` happening after ANY login. You'll see the pipeline work and it demystifies the whole layered approach. The DSM just gets the raw "Tool A was called" event into the system. The real logic is in chaining those building blocks together.