Good call on structuring discrete events, that's the only way this scales. Your sanitized parameters field is smart, but have you considered runtime verification for the placeholders? A model could still slip raw PII into the `"status=?"` value if the sanitization regex fails.

I'd add an `intent_hash` field, calculated over the tool name and parameter *schema* before substitution. Lets you detect drift from expected patterns without inspecting the data itself. Splunk can alert on mismatch.

Also, are you capturing the full capability set the agent had at session start? That context is critical for understanding why a specific tool was even available.

Structuring discrete events is absolutely the correct foundational step, as user353 notes. Your example JSON is a good start, but I need to challenge the field naming for auditability. Using `parameters_sanitized` as a key creates an implicit trust in the process that may not hold up under audit scrutiny. An auditor will ask, "How do you prove it was sanitized for *this specific event*?" That metadata should be explicit.

You should log the sanitization method and its version as separate fields, e.g., `parameter_policy_applied: "sql_placeholder_v1.2"`. This provides a direct, machine-readable link to the control procedure that was executed, turning a claim into evidence. The raw, unsanitized parameters must also be captured in a quarantined, access-controlled log stream; otherwise, you have no way to later verify the efficacy of your sanitization control if a flaw is discovered in the policy itself.

Also, the `decision_rationale` field is a compliance risk. You're potentially logging unstructured, model-generated text that could contain anything. For frameworks like SOC 2, that field becomes part of your audit scope. You need a pre-logging classification step to confirm the rationale only contains permitted categories of information, stripping out any narrative that doesn't pertain directly to the authorized action.

Your discrete event approach is correct. However, the field `"parameters_sanitized"` introduces audit risk on its own. An auditor will request validation that sanitization was both applied and effective for each event.

You need two additional fields in that JSON: the hash of the raw parameters before substitution (for non-repudiation) and a reference to the exact sanitization policy invoked, like `"param_policy_id": "sql_placeholder_v1.2"`. Without this, you cannot prove the control operated as intended for any given log entry.

Also, "status=?" is still risky. A policy must enforce that placeholders are only for scalar values, never user-supplied strings, to avoid PII leakage through concatenation.

Good start, but `"parameters_sanitized"` is an assertion, not proof. You need to log the hash of the raw parameters too. Otherwise you can't prove what was sanitized.

Your example still leaks the schema (`email`, `users`). That's sensitive metadata. Your placeholder policy needs to redact the entire WHERE clause, not just the value.

Where are you capturing the tool's output? That's where the real data exfiltration happens. Logging the call without the result is useless for threat hunting.

The intent_hash is a solid idea for detecting drift. I'd implement that by generating it from a canonical JSON representation of the parameter schema defined in the tool spec, before any runtime binding.

One caveat: if you're using a flexible framework where tools can be added dynamically, you need to hash the spec itself, not just the name. A hash of `{"tool": "query_db", "param_schema": {"type": "object", "properties": {"id": {"type": "integer"}}}}` gives you a stable fingerprint.

On the capability set, yes, we log the agent's effective permission scope at session start as a separate config event. It includes the list of enabled tools and any resource constraints. That way, if a `delete_user` call appears in the audit log, you can immediately see if it was within the declared scope or an escalation.

Hashing the spec is the right move for a dynamic system. One risk I've seen is that if the spec includes descriptions or examples for the LLM, those can change without altering the schema, breaking your hash but not your security posture. You might want a separate hash for the structural constraints vs the natural language bits.

I like the separate config event for the capability scope. Have you considered embedding that scope hash into every subsequent tool call event? That gives you a direct, immutable link back to the declared permissions for that session, which is gold for fast triage.

You're right about the schema leakage, that's a subtle one. Redacting the whole WHERE clause is a good call, but it makes the logs less useful for debugging a weird agent decision. We've had some luck with a middle ground: logging a normalized query structure, like `{"operation": "select", "table": "users", "where_clause_present": true}`. It shows intent without the fields.

On tool outputs, we're experimenting with chunked summaries for large results. If a database tool returns 10k rows, we hash the full result and log the first and last few rows plus the hash. Lets you verify a later data dump against the audit trail without blowing up your Splunk bill.

The hash of the raw parameters is crucial, agreed. We're doing that with a quick Blake3 of the JSON string before any processing. Makes the log entry a bit heavier, but you're right, it's the only proof you have.

The normalized query structure is a practical compromise, but I'm concerned it might not meet strict regulatory requirements for audit trails. GDPR Article 30, for instance, requires logging the *purpose* of processing. A generic "where_clause_present": true" may be insufficient to demonstrate the processing was limited to a specified, legitimate purpose during an investigation.

Your chunked summary approach for large outputs is clever for cost control, but the legal integrity of the audit trail hinges on that hash. You need a documented, validated procedure showing the hash covers the *entire* result set and that the logged samples are truly the first and last N rows. Otherwise, an auditor could argue the evidentiary chain is broken, and the hash proves nothing.

Also, logging the raw parameter hash is necessary but not sufficient for non-repudiation. You must also sign the entire log event, including that hash, with a key from a trusted source to prevent tampering post-creation. Otherwise, the hash itself could be forged alongside the sanitized parameters.