How to reconstruct what your AI did after an incident
The short answer
Because Senthex proxies every call, it keeps a per-call metadata record — model, route, shield verdicts and scores, timestamps and token counts. After an incident you can reconstruct the timeline of what your AI did across providers, and in the v1.1.7 pilot prove that timeline wasn't edited. What it does not replay by default: the verbatim prompts and completions, which are not stored.
What can you actually reconstruct after an AI incident?
From the metadata-first record, you can rebuild the operational story of a session:
- Which calls ran — to which model and provider, with what status;
- Which shields fired — the verdict, score and rule version for each, so you see what was flagged, blocked or redacted;
- In what order, and when — timestamps and token counts give you the sequence and the timing.
That is enough to scope blast radius ("which sessions hit the poisoned input?"), build the incident timeline, and hand security a record they can export to a SIEM — without your audit log becoming a second copy of customer prompts.
Why do ordinary application logs fail in an investigation?
App logs are written by the same service that made the decision, so they can be edited or rotated away, and they rarely correlate calls across multiple model providers. When the question is "prove to a customer or regulator exactly what happened," scattered, mutable logs are hard to stand behind. A proxy sees the whole call path in one place, records it on a defined schedule, and — in the pilot — lets you prove the record is intact.
How does Senthex reconstruct a session?
Each call is a structured record, correlated so you can walk a session end to end. You export the relevant window to your dashboard or SIEM and read the sequence directly. For integrity, the verifiable-audit pilot (v1.1.7) chains records with SHA-256 and anchors the chain to an RFC 3161 timestamp, and an offline verifier re-checks it — so "this is what happened, and it wasn't edited" is something an auditor can confirm independently, not just something you assert.
What this does not give you (the honest part)
Three limits, stated up front:
- Not verbatim content by default. Senthex logs metadata, not raw prompts and completions. You reconstruct what ran and what fired, not the exact words, unless you have deliberately enabled content capture (which carries its own privacy trade-offs).
- Not a complete trail if logging was off. A record proves what was logged, never what was never captured.
- The integrity proof is a pilot. The published release does metadata logging; the SHA-256 chain + RFC 3161 + offline verifier is the v1.1.7 pilot.
How does this fit EU AI Act and incident-reporting duties?
The per-call record is the raw material for Article 12 record-keeping and Article 19 retention (at least six months) — not Article 15. It also helps when the Cyber Resilience Act incident-reporting duties apply (severe incidents and actively exploited vulnerabilities, from 11 September 2026): a defensible timeline is far easier to produce from one proxy-side record than from reconstructed app logs. See the EU AI Act mapping for the line-by-line detail.
Reconstructing an AI incident
| What the investigation needs | Scattered app / database logs | Senthex per-call record |
|---|---|---|
| Which calls did this session make? | Maybe — if every service logged consistently | Yes — one record per call, in one place |
| Cross-provider timeline (OpenAI + Anthropic + …)? | Rarely correlated | Yes — the proxy sees every provider's traffic |
| Which shield fired, and why? | No | Verdict, score and rule version per shield |
| Can you prove the record wasn't edited? | No | Yes, in the v1.1.7 pilot (SHA-256 chain + RFC 3161) |
| Verbatim prompts and completions? | Only if you stored them (a privacy liability) | No by default — metadata, not raw bodies |
Frequently asked questions
How do I reconstruct what my AI did after an incident?
Use Senthex's per-call metadata record: which model and provider each call hit, which shields fired with their verdict and score, and the timestamps that give you the sequence. You export the relevant window to your dashboard or SIEM and walk the session end to end. In the v1.1.7 pilot you can also prove the record wasn't edited.
Can I replay the exact prompt and response?
Not by default. Senthex logs metadata, not raw prompts and completions, so you reconstruct what ran and what fired — not the verbatim words — unless you have deliberately enabled content capture, which carries its own privacy trade-offs. The honest default is metadata-first.
How is this different from just keeping application logs?
App logs are written by the same service that made the decision, can be edited or rotated, and rarely correlate calls across providers. A proxy records the whole call path in one place on a defined schedule, and in the pilot lets an auditor verify the record is intact instead of taking your word for it.
Does it prove the timeline wasn't tampered with?
In the v1.1.7 pilot, yes — records are chained with SHA-256 and anchored to an RFC 3161 timestamp, and an offline verifier re-checks the chain. It is tamper-evident, not tamper-proof: changes are detectable, not prevented. The published release does the metadata logging.
Can I send the records to my SIEM?
Yes — the records are exportable, which is what makes a proxy-side trail usable for incident response and post-market monitoring rather than just a dashboard you stare at.
Build the timeline before you need it
The record only helps if it's already running when the incident hits. Start on the Free plan to see the per-call dashboard, and read how to prove the trail is intact. For a self-hosted, SIEM-integrated deployment, talk to us.