EU AI Act Compliance for AI Agents, Built as an Audit Trail
If your organisation runs AI agents in the EU, Article 12 already requires automatic, tamper-evident logs, and Article 14 requires a human who can actually stop the system. Screenshots and a spreadsheet do not satisfy either one. AI Blackbox is a continuous, tamper-evident record of everything every AI agent on a machine does — a record the agent itself cannot switch off, edit, or rewrite — built specifically to produce the evidence an auditor will accept.
Finds every AI on its own: Claude, Qwen, Kimi, DeepSeek, Ollama, llama.cpp, Open WebUI, and containerised models. Proven and running on Linux today, including OS-level tamper prevention verified on real hardware. Runs locally, no mandatory cloud dependency.
// the law, in plain terms
Three obligations. None of them are met by "we have some logs."
The EU AI Act does not ask you to promise good behaviour. It asks for architecture: logs the system cannot suppress, a person who can actually intervene, and records kept long enough to matter.
| Article | What it requires | Where it bites |
|---|---|---|
| Art. 12 | Automatic, traceable record-keeping over the AI system's entire lifecycle — events relevant to risk, not just final outputs. | A log the AI can edit or disable does not satisfy this. It has to be architectural. |
| Art. 14 | Human oversight: a person must be able to understand, monitor, and interrupt the system's operation. | A stop button inside the same process the agent controls is not oversight. |
| Art. 19 / 26(6) | Providers and deployers must retain the automatically generated logs for a defined period. | Retention has to be enforced, not a setting someone can quietly shorten. |
Read together, the three articles describe one property: the record has to survive the system it is recording. That is the whole design brief behind AI Blackbox.
// why ordinary logging fails this
When an agent breaks something, you need a record, not a "probably"
AI agents already act with real privilege: they run commands, touch files, call the network and model APIs, and decide things on their own. Here is what follows from that, and where most teams currently have no answer.
A log the AI can switch off
Ordinary logging lives in the agent's own domain, so the agent can edit, truncate, or disable it. As evidence for an auditor or an incident review, it is worth nothing.
Nobody knows what is even running
A real developer or production box runs several AIs at once — a coding agent, a local model, a chat UI, a cloud API. An honest, current inventory of that and where it sends data usually does not exist.
Something broke, nothing to reconstruct it from
A file is gone, a config is rewritten, and which of three agents running in parallel did it is unknown. Without per-action attribution, there is no way to rebuild the decision.
Human approval that never happened
An agent can present its own silence or an automated default as if a person signed off on it. Without independently verified identity, that is impossible to check after the fact.
Article 12 does not accept "we have some logs"
It requires automatic, traceable logs over the system's lifecycle. A log the system itself can suppress does not meet that bar, no matter how detailed it looks in a demo.
// proven in our own testing
Three models ran in parallel on the same machine, and all three had touched the WireGuard configuration. When the interface disappeared, AI Blackbox's record showed, unambiguously, that the ip link delete command was run by the Grok agent specifically, with an exact timestamp and OS-level attribution. The other two models were cleared instantly — the record showed they never touched that action.
// how it works
Every event is a signed link in a chain that cannot be rewritten unnoticed
AI Blackbox assumes the agent itself could be compromised or hostile, and does not rely on its good behaviour at any step.
- Discovery. A sensor finds every model and agent on the machine by itself — by process name, model file, listening port, and which model API it calls — and names each one in plain terms: "DeepSeek · harness (web)", "Qwen 2.5 3B · local model", not a process ID.
- Recording. Every event — a tool call, a network connection, a SQL statement, a human decision — becomes a signed (ed25519) link in a SHA-256 hash chain, stored append-only. Editing any past event breaks every checksum after it, which an independent verifier (
bbverify) detects with no access to the live system. - OS-level enforcement. Under root, the append-only file attribute blocks rewriting, truncating, or deleting the journal — even for root itself. Verified on real hardware: ext4, systemd, TPM 2.0.
- External anchoring. Signed Merkle checkpoints ship to an external witness. Even a fully compromised machine cannot rewrite history it no longer controls.
- A human outside the agent. A kill-switch and an approval queue run on the brokers, out of the agent's reach. A decision is recorded with the operator's OS-verified identity before it is applied.
- Evidence export. One self-contained package: the records, cryptographic proof of their integrity, and an Article 12 coverage report — verifiable by a third party with no access to your environment.
// visibility and investigation
See where every model sends data, and ask the journal directly
The network map turns "where is our data going" into one picture, and a bundled AI analyst answers plain-language questions grounded in the journal — it can read records and nothing else.
The analyst is a local, fine-tuned Qwen 2.5, restricted three independent ways: no action tools by construction, a read-only socket at the transport layer, and a sandboxed deployment. Every answer is grounded in records, with citations.
// compliance, mapped directly
Each obligation, and exactly what in AI Blackbox satisfies it
| Requirement | Covered | How |
|---|---|---|
| Art. 12 — automatic, traceable logging | ✔ yes | Every action is recorded automatically; nothing depends on the agent choosing to report it |
| Art. 12 — logs the system cannot suppress | ✔ yes | Hash-chained, signed, append-only; OS-enforced under root on real hardware |
| Art. 14 — ability to monitor operation | ✔ yes | Live console, auto-discovery, and a network map covering every model on the machine |
| Art. 14 — ability to interrupt the system | ✔ yes | Kill-switch enforced on brokers outside the agent's own process |
| Art. 14 — decisions attributable to a real person | ✔ yes | Approvals carry the operator's OS-verified identity, journaled before being applied |
| Art. 19 / 26(6) — enforced retention | ✔ yes | 6-month default, 24-month profile; configuration below the legal minimum is rejected |
| Third-party verifiability | ✔ yes | Independent verifier plus a second, separate Python implementation of the format |
| GDPR-clean evidence | ✔ yes | Journal holds hashes and references; raw content is separately encrypted, PII-redacted, short retention |
// why this, and not ordinary logging
A property of the architecture, not a setting that can be turned off
Cannot be rewritten unnoticed
Hash-chain, ed25519 signing, append-only storage. Editing, deleting, reordering, or truncating history breaks the checksums and is caught by an independent verifier.
Not even root can disable it
OS-level protection verified on real hardware: the append-only flag blocks rewriting or deleting the journal for the agent and for root alike. The service auto-restarts; any gap is a critical alert.
Signing key out of software's reach
The key is sealed in a TPM 2.0 via systemd-creds, verified on hardware — not a file on disk an agent could theoretically read.
A witness outside the machine
Signed checkpoints ship to an external bb-witness service. Even a fully compromised machine cannot rewrite history someone outside has already confirmed.
The format is independently re-derivable
bbverify needs no access to the live system, and a second, independent implementation of the check exists in Python — proof the format is open, not "trust us."
Evidence kept separate from personal data
The immutable journal holds hashes and references. Raw prompts and outputs live separately, encrypted, PII-redacted, on a short retention — a clean GDPR boundary.
// what it already does
Built and proven on real hardware, not a roadmap
| Capability | Status | How |
|---|---|---|
| Tamper-evident journal: hash-chain + signature + append-only | ✔ working | Core of the product, independent verifier bbverify |
| Rewrite prevention under root | ✔ verified on hardware | Append-only file attribute, socket group separation, systemd watchdog with auto-restart |
| Auto-discovery of AI models on the machine | ✔ working | By name, model file, port, and calls to LLM APIs |
| Signing key in hardware (TPM) | ✔ verified on hardware | systemd-creds provider, seed sealed in TPM 2.0 |
| Kill-switch and human approval queue | ✔ working | Outside the agent, on brokers; decisions carry OS-verified identity |
| External witness for a machine fleet | ✔ working | bb-witness detects tail truncation |
| Evidence export mapped to Article 12 | ✔ working | Self-contained package, verifiable by a third party |
| Built-in AI analyst over the journal | ✔ working | Local Qwen 2.5, read-only, no action tools |
| Autostart and full collection | ✔ working | systemd service, enabled and proven on real hardware |
// pricing
Free core for one machine, paid plans for a fleet and an audit
You are not paying for logging. You are paying to pass an audit and to have something to answer with at an incident. Pricing is scoped to your fleet and your compliance regime — talk to us.
Free / OSS core
- Collector, verifier, console
- Auto-discovery on one machine
- Hash-chained journal +
bbverify - Kill-switch and approval queue
Team
- External anchoring / witness
- Evidence export for audit
- Retention profiles
- Bundled AI analyst
- Autostart packaging, support
Enterprise
- Central backend for a fleet
- Long retention with Object Lock
- SSO, custom profiles (NIST AI RMF, DORA)
- Audit-ready evidence workflow
- Dedicated support
// built by AgentOffense
We break AI agents for a living. AI Blackbox answers "what if it already did something."
Our firewall airlock_ai stops a dangerous action in the moment. AI Blackbox is the other half: it records, proves, and hands an auditor an evidence package. Together, that is prevention plus accountability. If you need an attacker's view of your agents, or help rolling out recording across a fleet with an EU AI Act evidence pack, that is our day job.
// further reading
More from our work on AI agent accountability
EU AI Act Article 12 for AI agents
What tamper-evident logging actually requires, in detail.
One AI agent doing everything breaks segregation of duties
Why a single autonomous agent is a governance problem, not just a security one.
Autonomous AI agents stole thousands of credentials in 6 hours
Inside Google's report — what unrecorded agent autonomy actually costs.
What can an AI coding agent actually do on your machine?
The full privilege surface an agent gets by default.
Find out what your AI agents actually did — and be able to prove it.
An audit trail for AI agents. Working prototype, proven on real hardware. Core runs locally, no mandatory cloud.
Talk to us about EU AI Act compliance
Tell us about your AI agents and your compliance deadline, and we will reply within one business day with what an AI Blackbox rollout would look like for your environment.
EU AI Act compliance for AI agents: FAQ
What does the EU AI Act actually require for AI agents?
For high-risk AI systems, Article 12 requires automatic, traceable logging over the system's lifecycle. Article 14 requires human oversight, including the ability to monitor and interrupt the system. Article 19 and Article 26(6) require the logs to be retained for a defined period. None of these are satisfied by ad hoc logging the system itself can edit or disable.
What is the penalty for non-compliance?
Non-compliance with these obligations can carry fines of up to €15 million or 3% of global annual turnover, whichever is higher, under Article 99(4).
How is this different from ordinary application logging?
Ordinary logs live inside the same system they are supposed to hold accountable, so the AI can edit or disable them. AI Blackbox's journal is a signed, hash-chained, append-only record enforced at the OS level, anchored to an external witness, so no single compromised machine can rewrite its own history.
Does this apply to any AI agent, or only specific vendors?
AI Blackbox auto-discovers models and agents by process, model file, port, and API calls, covering Claude, Qwen, Kimi, DeepSeek, Ollama, llama.cpp, Open WebUI and containerised models without vendor-specific integration.
Is AI Blackbox free?
The core for a single machine — the collector, verifier, console, and discovery — is free. Organisations pay for what a fleet and an audit actually need: external anchoring, evidence export, and retention profiles. Pricing is discussed directly, through the form on this page.