Aegis Latent Core: a tamper-evident evidence chain for AI traffic. Does this help a blue team, or is it just another log source?

Disclosure: I am the author. Personal project. Source-available, not OSI open source. Not selling anything in this post. I am here because r/blueteamsec is where detection engineering and log integrity get taken seriously, and I want to know if what I built is operationally useful or just architecturally cute.

The blue team problem I am trying to address

Your SIEM ingests logs from endpoints, identity providers, proxies, and SaaS. If an attacker with privileged access wants to erase a trace, the classic move is T1565.001 (Stored Data Manipulation) applied to the audit trail itself: mutate an event, delete one, reorder them, or roll back to an earlier state. You already know this. The standard mitigations are off-host collection, append-only storage, and hash-chaining with periodic root digests.

Aegis Latent Core is not a SIEM and not a log shipper. It is an evidence layer that sits in front of AI traffic (web UI via browser extension, API via proxy, local models via gateway) and produces a per-interaction hash-chained, signed receipt before the response is delivered. The question for this community is narrower than "is it secure": does a per-interaction evidence chain for AI traffic give a blue team a detection signal or an investigative artifact that it does not already get from its existing log pipeline?

What the chain actually gives you (and what it does not)

The design is deliberately close to the audit-chain pattern you already know. Each event is canonicalized, hashed, linked to the previous event in the stream, and signed. The chain detects:

• In-place mutation of an event after it was recorded (hash mismatch at the affected sequence).
• Deletion of an event (gap at the missing sequence).
• Reordering (out-of-order sequence).
• Rollback to an earlier chain head (boundary shift).

This is the same integrity model as a per-tenant audit chain that forwards to a SIEM, and the same scope limitations apply: the chain starts at the collector. If an attacker controls the client before the event reaches the collector, the chain will faithfully record whatever the client emitted. It is not producer attestation. It does not prove the client was honest.

For a blue team, that means the chain is useful for post-collection integrity and investigative artifact preservation, not for pre-collection detection of a compromised endpoint. I want to be explicit about that distinction because it is the difference between "this helps your IR" and "this replaces your EDR".

Where this might actually be operationally useful

I have three hypotheses. I would like you to tell me which one is wrong.

1. Detection of evidence tampering during an AI-related incident

If an incident involves an employee exfiltrating data through an AI tool, the first question in the post-incident review is often "what did they actually send, and can we prove it?" The chain gives you a signed, ordered record of what reached the collector, with a receipt that a third party can verify without trusting the gateway. That is a DFIR artifact, not a detection rule. But if the attacker's objective includes cleaning up the AI interaction history, the chain gives you a way to detect post-hoc modification of the collected record, which is one layer below the endpoint.

Question for you: in your experience, does a per-interaction receipt like this survive contact with legal or HR, or does it get dismissed because the client is untrusted?

2. A log source for "AI interaction anomalies" that your SIEM can correlate

The events are structured metadata by default (hashes, timestamps, surface, user/device identifiers), not message bodies. That makes them cheap to ship to a SIEM and correlate with DLP, CASB, or identity logs. The signal is not "the model said something bad"; the signal is "this user's AI interaction pattern changed, and the chain shows no tampering in the record of that change."

Question for you: would you actually onboard a new log source for AI interactions, or would you rather have this folded into an existing CASB/DLP feed?

3. Evidence preservation for AI Act Article 12 traceability

Article 12 of Regulation (EU) 2024/1689 requires high-risk AI systems to technically allow automatic recording of events over the lifetime of the system, with traceability appropriate to the intended purpose. The obligations for Annex III employment-related systems take full effect on 2 August 2026. The operational reading for a blue team is that you will soon be asked to produce and defend a traceability record, not just retain logs. A hash-chained, signed per-interaction record is closer to that requirement than a plain log line, because it is verifiable after the fact.

Question for you: if your organization deploys high-risk AI in employment or critical infrastructure, is Article 12 traceability on your roadmap yet, or is it still a legal team problem that has not reached detection engineering?

What I am not claiming

• Not tamper-proof. Tamper-evident.
• Not producer attestation. The chain starts at the collector; a compromised client can emit fabricated events that the chain will faithfully record.
• Not a completeness guarantee. Unenrolled devices, uncovered browsers, and user-initiated pauses are recorded as gaps, not eliminated.
• Not a SIEM replacement. It is one more source, with a specific integrity property.
• Not a compliance certification. It can help an operator produce Article 12-style traceability, but it is not a conformity assessment.

The questions I actually need answered

1. Signal vs. noise: if this showed up as a new log source in your pipeline, what would make you keep it versus mute it after a week?
2. Chain design: for blue team purposes, is per-interaction hash chaining enough, or do you need periodic root digests anchored off-host (WORM bucket, RFC 3161 timestamp) before you would treat it as evidence?
3. Client trust: is there any realistic way to get from "tamper-evident record of what the collector received" to "trustworthy record of the interaction" without a TEE on the endpoint, or should I stop trying and scope the claim to server-side observation only?
4. DFIR workflow: would a per-interaction receipt be useful during an investigation, or does it add a verification step that analysts will skip under time pressure?
5. The "just use X" question: if you already hash-chain audit logs in your pipeline (the Cordum pattern, or an equivalent), what would justify a separate evidence layer for AI traffic instead of extending the existing chain to cover AI events?

Links

• Repository: github.com/JuanLunaIA/aegis-latent-core
• Project page: aegislatent.com (README is the source of truth if the page is down)
• License: LICENSE in the repo root (LicenseRef-Aegis-Commercial-1.0, source-available, not OSI open source)

If this is operationally useless to you, say why. That is more valuable to me than a polite "interesting project".