Incident response
Reconstruct how the agent was compromised: which input reached it, which tools it called, what left the system.
Every prompt. Every tool call. Every response.Recorded as runtime evidence you can verify, with every gap counted.
The final answer alone rarely settles it. Every step in between has to be on record.
Reconstruct how the agent was compromised: which input reached it, which tools it called, what left the system.
Evidence for each finding: what happened, in a record whose integrity can be checked.
Show what triggered which action, step by step, from the first prompt to the last tool call.
Privacy violations in multi-agent LLM systems, measured across 4,979 execution traces.
Source: AgentLeak benchmark, El Yagoubi et al., arXiv:2602.11510
Part of the leakage happens in internal channels between agents, which a check of the final output never sees. Superinspect records those internal channels too.
Each step leaves something you can check: the event, the chain, the finding.
Prompts, retrieved content, tool calls, memory operations and model responses are captured at runtime.
The record is append-only and hash-chained. Signed checkpoints are written to a separate location, and the keys stay with you. Tampering before the latest signed checkpoint is detected.
Each finding, such as prompt injection, personal data or a policy violation, points to the exact recorded event and to a named requirement in the EU AI Act, ISO/IEC 42001, NIST AI RMF or the OWASP Top 10 for LLM Applications.
Prototype results on public benchmarks and in a test setup. The note under each number belongs to it.
Superinspect adds independent, auditable evidence.
Built for the vendor's own operations. They usually cover only that one vendor, and the vendor holds the data.
Built for debugging and performance, not as a tamper-evident chain of evidence, and not organised around audit requirements.
They block or change requests, which changes the very flow you may later need to evidence. Superinspect can run alongside them.
Six properties your security team can check before a pilot.
Never blocks or changes a call. If recording fails, the application keeps running and the gap is counted.
Your data stores are opened read‑only. A write attempt fails at the database itself.
Evidence files, including their side files, are created readable by their owner only.
Findings store what was found and where, never a copy of the sensitive value.
Binds to localhost by default. It loads no JavaScript and nothing from outside.
Hash-locked, scanned for known vulnerabilities, adopted only after a 14‑day waiting period.
The security model is documented alongside the code, so every point above can be reviewed in a pilot.
Anything not covered here, ask in your pilot request.
You choose one AI application. Three assurance questions are agreed up front for the pilot to answer. Examples: Did personal data enter or leave the workflow unexpectedly? Did the agent use tools outside policy? Was deleted data actually removed from memory? At the end you receive one evidence report. Each finding in it points to the recorded event and to the requirement it relates to.
It is built not to: it only observes and fails open, and the measured recording overhead is a median of 0.03 ms per call (0.02 ms without), in a test setup.
No. Superinspect itself sends nothing out; it runs entirely on your network.
No. Superinspect provides evidence: each finding points to the recorded event and to a named requirement. Whether a requirement is met is for your auditors to judge.
Anthropic, OpenAI, Azure OpenAI and LangGraph. Superinspect can also import sessions from Claude Code and OpenAI Codex; the Codex import is experimental. Personal-data detection is tuned for English text so far; German is in development.
A pilot tests whether the evidence is useful, not whether you are compliant.
Request a pilotA short email to kontakt@superinspect.de is enough: which AI application, and which question you want answered.