DEV Community: Ventse

The EU AI Liability Directive is dead: what actually governs AI agent harm now

Ventse — Tue, 01 Sep 2026 08:49:12 +0000

The EU AI Liability Directive is dead: what actually governs AI agent harm now

On 6 October 2025, a short notice appeared in the EU's Official Journal confirming what the European Commission had already signalled eight months earlier: the AI Liability Directive was not coming. The withdrawal followed a Commission decision at its 2533rd meeting on 16 July 2025, and closed a proposal that had been on the table since 2022 — the one piece of EU law written specifically to make it easier to prove an AI system caused you harm.

If you run agents that touch EU users, or sell into the EU, the practical question is not "what did we lose." It is: what governs an AI agent causing harm now, and does it cover the harm your agent could actually cause?

What the directive was meant to do

The proposed AI Liability Directive would have complemented the AI Act rather than duplicated it, easing a claimant's path to compensation for AI-caused harm along two specific mechanisms: a court's power to order disclosure of evidence from a provider or deployer of a high-risk AI system, and a rebuttable presumption of a causal link between an AI system's non-compliance and the resulting harm, where the claimant could show fault was likely but proving causation was disproportionately hard given how the system worked. It was designed for exactly the case that makes agents hard to litigate: the claimant cannot see inside the system, and the operator holds all the evidence.

Why it was dropped

The Commission's 2025 work programme, adopted 11 February 2025, listed the directive for withdrawal with a one-line justification: "no foreseeable agreement." Member states and industry groups had spent two years unable to converge on the scope and mechanics, and the withdrawal landed alongside a broader simplification push that also dropped the ePrivacy Regulation. The Commission's own text left the door open rather than closing it: it "will assess whether another proposal should be tabled or another type of approach should be chosen." As of this piece, no replacement has been tabled.

What already applies instead

The gap is not empty. The EU's overhauled Product Liability Directive, Directive (EU) 2024/2853, was adopted separately and was never at risk — it entered into force in the weeks after its publication on 18 November 2024, and member states have until 9 December 2026 to transpose it. Unlike the withdrawn directive, it is not AI-specific, but it was substantially rewritten with software in mind: the definition of a covered "product" now explicitly extends to software, firmware and AI systems, closing a long-standing ambiguity about whether a defective model was a "product" at all.

The mechanics carry over some of what the withdrawn directive was trying to do. A court can compel a defendant to disclose relevant evidence once a claimant has made a sufficiently plausible case. And where the claimant can show a defect is likely but proving it is excessively difficult because of the product's technical complexity — or where the defendant fails to comply with a disclosure order — the product is presumed defective. Practically, that is close to what the AI Liability Directive would have delivered for high-risk AI: the burden moves toward whoever holds the evidence.

The gap it doesn't close

The catch is scope. The Product Liability Directive exists to protect natural persons, and the damage it compensates is death, personal injury, damage to property kept for private use, and destruction or corruption of data not used for professional purposes. It expressly excludes pure economic loss and property "used exclusively for professional purposes." A consumer whose smart device is bricked by a faulty AI update is covered. A business whose AI agent misfires a transaction, corrupts a business dataset, or ships a bad deployment is not — that is a commercial, economic loss, and it stays exactly where the withdrawn directive would have reached: general national contract and tort law, unharmonised across 27 member states.

That is the case most companies running agents actually have. Agents deployed in a business context, causing business harm, to another business. The one EU proposal aimed squarely at that gap is the one that got withdrawn.

What this means if you run an agent

Two different regimes now apply depending on who got hurt, and neither hands a B2B agent operator's counterparty an easy route:

Consumer-facing harm — falls under the revised Product Liability Directive from December 2026 for newly placed products. Courts there can already order disclosure and will presume a defect against whoever cannot produce a credible answer.
Business-to-business, economic harm — the case a coding agent, a data pipeline agent, or an internal automation agent is most likely to produce — stays on national contract and tort law, with no EU-wide presumption to lean on either way.

In both cases, the practical position is the same: nobody is going to take a log file's word for what an agent did. Where the Product Liability Directive applies, the mechanism rewards whoever can actually satisfy a disclosure order with something a court finds credible, not just present. Where it doesn't apply, and the dispute runs on ordinary national rules of evidence, the party who can independently prove what happened is arguing from a position the other side cannot easily contest. A signed execution receipt — a canonical record of inputs, outputs, timing and sandbox policy, signed with a key the agent never touches — is built to be exactly that kind of artefact: something you hand over under a disclosure order, or into evidence, rather than something a claimant successfully argues you should be presumed to be hiding. What such a receipt does and does not establish, and the fields an audit trail needs regardless of which regime ends up applying, are covered in How to verify what an AI agent actually did and AI agent audit trails.

The uncomfortable read: the one EU proposal written specifically for AI harm was withdrawn for lack of agreement. What replaced it either doesn't reach the B2B case most agents create, or rewards whoever can actually produce evidence once a court asks for it. Either way, "trust our logs" was never the safer bet.

What to do before December 2026

Map your exposure. Separate agent deployments that touch consumers and personal data from ones that only produce business-to-business, economic outcomes — they now sit under genuinely different legal regimes.
Don't wait for the transposition deadline. The Product Liability Directive only covers products placed on the market after 9 December 2026; anything shipped earlier, and anything B2B, is already governed by whatever your national law and your contracts say today.
Build the evidence trail regardless of which regime applies. Disclosure orders and presumptions of defect both cut against whoever cannot produce a credible record. That is true whether a court is applying the new EU rules or your counterparty's home jurisdiction's ordinary contract law.

The receipt format, the verifier and the transparency log are open: the spec, the verifier on PyPI and the public log. Regulation in this area is still being written and rewritten around you. The evidence you can produce when someone finally asks is not something you can backdate.

Originally published on traceseal.io.

Indirect prompt injection: how an AI agent gets hijacked by the data it reads

Ventse — Tue, 25 Aug 2026 08:50:13 +0000

An agent that reads a web page, an issue tracker, an inbox or a pull-request description is reading text that somebody else wrote. Indirect prompt injection is what happens when that text contains instructions addressed to the model rather than to the reader, and the model carries them out using the agent's tools and the agent's permissions.

The uncomfortable part is not that the attack exists. It is that the people who study it hardest do not claim to have solved it. This piece covers the mechanism, what the standard mitigations genuinely buy you, and what a team can do about the residue: making what the agent actually did provable after the fact.

Direct and indirect

OWASP's LLM01:2025 Prompt Injection entry splits the class in two. A direct injection is one where a user's prompt input "directly alters the behavior of the model in unintended or unexpected ways". An indirect injection occurs "when an LLM accepts input from external sources, such as websites or files" whose content alters the model's behaviour.

The threat model changes completely between the two. A direct injection requires the attacker to be talking to your system. An indirect one does not. The attacker writes something once, somewhere your agent will eventually read, and waits for the agent to come to them.

OWASP also records that these inputs "do not need to be human-visible/readable, as long as the content is parsed by the model". An HTML comment, pale text on a pale background, a document's metadata or wording rendered inside an image all qualify. A human reviewing the same source may see nothing at all.

The technique was named by Simon Willison in September 2022. Its indirect form was set out systematically in Not what you've signed up for (Greshake et al., February 2023), which argued that LLM-integrated applications "blur the line between data and instructions" and demonstrated working attacks against production systems, including Bing's GPT-4-powered chat and code-completion engines. The authors showed that "processing retrieved prompts can act as arbitrary code execution".

Why there is no boundary to enforce

Classical injection bugs have a structural fix. SQL injection ends when queries are parameterised, because the database is then told, in a channel the attacker cannot reach, which bytes are code and which are data. Prompt injection has no equivalent. Instructions and content arrive at the model as one undifferentiated token sequence. As Willison puts it:

LLMs are unable to reliably distinguish the importance of instructions based on where they came from. Everything eventually gets glued together into a sequence of tokens and fed to the model.

Delimiters, tagging of untrusted regions and system prompts that say "ignore any instructions in the content below" all raise the cost of an attack, sometimes considerably. What none of them provide is a rule the model is architecturally obliged to obey. They are strong suggestions to a system that treats every token as a suggestion.

The lethal trifecta

Willison's lethal trifecta framing (June 2025) is the clearest way to work out whether a given agent is exposed. Three capabilities together create the risk:

Access to private data — which is usually the entire point of giving the agent tools.
Exposure to untrusted content — any route by which attacker-controlled text or images reach the model.
The ability to communicate externally in a way that could carry data back out.

"If your agent combines these three features," Willison writes, "an attacker can easily trick it into accessing your private data and sending it to that attacker." The awkward observation is that most agents worth deploying hold all three by design. A coding agent that reads a private repository, browses documentation and opens a pull request has the full set. Dropping one leg is a real mitigation and frequently an unacceptable product decision.

What the mitigations actually buy you

OWASP lists seven countermeasures: constraining model behaviour, defining and validating output formats, input and output filtering, least-privilege access, human approval for high-risk actions, segregating external content, and adversarial testing. Each is worth doing. The entry prefaces all of them with a sentence that deserves quoting exactly:

Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection.

NIST arrives somewhere similar from another direction. AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (March 2025), describes its own purpose as identifying "current challenges in the life cycle of AI systems" and describing "corresponding methods for mitigating and managing the consequences of those attacks". Managing consequences is the language of an attack that landed.

So the design question is not only how to stop injection. It is what your system can still tell you once one gets through.

What changes when the target is an agent

Against a chatbot, a successful injection produces wrong text and a bad afternoon. Against an agent it produces actions: a file written, a secret read, an API called, a branch pushed, a message sent on your behalf. OWASP's impact list includes "executing arbitrary commands in connected systems" and "providing unauthorized access to functions available to the LLM".

Two things follow. First, blast radius is set by the permissions you granted, not by the model's judgement, because the model's judgement is the component under attack. Second, and less widely appreciated: the agent's own account of events becomes attacker-influenced output. If the injected text says "do X, then report that you did Y", the transcript says Y. Reasoning traces, tool-call summaries and self-reports are all generated downstream of the compromise. They are the last artefacts that should be treated as evidence, and often the only ones a team has kept.

What the regulation already assumes

Article 15 of the EU AI Act requires that high-risk AI systems "shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities". The technical measures it calls for must, where appropriate, "prevent, detect, respond to, resolve and control for" AI-specific attacks, expressly including "inputs designed to cause the AI model to make a mistake".

Article 15 binds high-risk systems, so it will not reach every agent deployment. The drafting is instructive regardless: prevention is one verb out of five. Detection, response and resolution each presuppose an attack that succeeded, and each requires a record that stays trustworthy after the system it describes has been compromised.

Two controls that survive a failed prevention

Containment. A kernel-namespace sandbox bounds what an injected instruction can reach, whatever the model decides to do. We published a working bubblewrap profile in How to sandbox an AI coding agent, along with the DNS leak we only found by running it. A sandbox limits consequences. It will not tell you that an injection arrived.

A record made outside the agent. A signed execution receipt is a canonical record of inputs, outputs, timing and sandbox policy, stored as SHA-256 hashes and signed with an ed25519 key the sandboxed process never sees. The agent does not write it and cannot amend it. A third party checks it offline, with no access to your systems:

$ pip install traceseal-verify
$ traceseal-verify receipt.json
[OK] receipt.json — operator signature verified

None of this prevents injection. What it does is make the aftermath answerable. Given a suspected compromise last Tuesday, what did the agent read, what did it touch, and can you demonstrate that to somebody who has no reason to take your word for it? The walkthrough of what such a check does and does not establish is in How to verify what an AI agent actually did.

What to record so an injection stays provable

The exact content the agent read, hashed at fetch time. If the poisoned page is quietly edited afterwards, the hash still pins what was actually served to you.
Every tool call and its real arguments, captured at the tool boundary rather than from the model's description of what it intended.
The sandbox policy in force during the run, so containment becomes something a reader can check rather than something you assert.
Observed side effects — files written, network destinations reached, commits created — recorded from outside the agent process.
A signature over all of it, made with a key the agent cannot reach, so the record's integrity does not depend on the agent having behaved.

The field-level detail, including the EU AI Act's log-retention floor, is in AI agent audit trails.

The question to sit with: if one of your agents read a poisoned document last week, would you learn about it from your own records, or from the person its data ended up with?

The receipt format, the verifier and the transparency log are open: the spec, the verifier on PyPI and the public log. Prevention research will keep moving, and it should. In the meantime, the attacks that get through are the ones your evidence has to account for.

Transparency log witnesses: how cosigned checkpoints make a log tamper-evident

Ventse — Tue, 18 Aug 2026 08:49:30 +0000

On 17 August 2026, at 14:17:40 UTC, an independent witness operated by Markovian Protocol cosigned the checkpoint of our public transparency log. Nothing about the log changed that afternoon. What changed is what we can prove about it: from that moment, if we ever rewrote the log's history, a third party outside our infrastructure would be holding cryptographic evidence of the version we abandoned.

This post explains what a transparency log witness is, what a cosigned checkpoint actually proves, and the obligations you take on when one starts watching your log. Most of it we learned by going through the process rather than by reading about it.

The gap witnesses close: a log can lie to you specifically

An append-only log is the standard answer to "how do I show my records existed before the dispute did". You publish entries into a Merkle tree, the tree has a root hash, and anyone can check that a given entry is included. Certificate Transparency (RFC 6962) runs the web's certificate issuance through this structure; the Go checksum database does it for module hashes; Sigstore's Rekor does it for software signatures.

But a Merkle tree on its own has a hole, and RFC 6962 was upfront about it: detecting a misbehaving log requires people to compare notes on what the log showed them. A log operator who controls the serving infrastructure can present one version of the tree to the auditor and a different version to everyone else. Each view is internally consistent, each proof checks out, and the two views never meet. This is the split-view attack, and no amount of hashing inside the log prevents it, because the operator is the one doing the hashing.

For our purposes the operator's honesty is exactly what is in question. Traceseal exists because logs written by the party under scrutiny are not evidence. Our transparency log anchors signed agent receipts, and until last week it had the same weakness as every self-hosted log: you had to trust us not to serve you a private version of history.

What a checkpoint is

A checkpoint is a small signed statement of the log's current state, in the format specified by c2sp.org/tlog-checkpoint: the log's name (its origin), the number of entries, and the root hash of the tree at that size, wrapped in a signed note. Ours currently reads:

log.traceseal.io
19
OhQzzSdQHnpofrO/F2reZkiIDDPjUEM+wuGNc4mlD84=

— log.traceseal.io vLzsyMryP2doyfOtISb5...

Nineteen entries. Certificate Transparency logs hold billions, and the format is the same, which is rather the point: the protocol does not care whether it is guarding the web PKI or a small receipts log. A checkpoint commits the operator to one specific history up to one specific size. What it cannot do alone is stop the operator issuing two different commitments to two different audiences.

What a witness actually does

A witness is a service, run by someone other than the log operator, that keeps the latest checkpoint it has seen for each log it follows. The protocol, c2sp.org/tlog-witness (v1.0.0, March 2026), is short enough to read over coffee. The core of it:

Witnesses verify that the checkpoint is consistent with their previously recorded state of the log (if any), and return a timestamped cosignature.

"Consistent" carries the whole load. When our log grows and asks the witness to cosign the new checkpoint, it must supply a consistency proof: a Merkle proof that the tree at the new size contains the tree the witness already recorded as a prefix. If the proof fails — if any old entry was altered or removed — the witness refuses. The cosignature it returns on success embeds its own timestamp, so the statement a verifier ends up with is precise: at this time, this witness saw this exact view of the log, and that view extended every view the witness had seen before.

A split view now requires deceiving the witness as well, and the witness's records are not ours to edit. That is the entire trick. No new cryptography, just a signature from someone whose incentives are not our incentives.

One implementation detail that cost us an afternoon: the log's own /checkpoint endpoint serves only the log's signature. The cosignature lives on the witness's copy, at /<sha256(origin)>/checkpoint on the witness's host. If you fetch your own checkpoint and wonder where the witness signature went, it was never going to be there.

What a cosignature does not prove

Witnessing is content-blind, and it is worth being blunt about the edges:

It says nothing about what the entries mean. A witness checks append-only consistency, not truth. A log of fabricated receipts, faithfully appended and never rewritten, will be cosigned without complaint. Content verification is a separate job — ours is done by signature checks on each receipt, and the honest-limits caveats in that post still apply.
One witness is one extra party to corrupt. If the log operator and the witness collude, the split view returns. The mitigation is a quorum of independent witnesses, which is why a shared witness network is being built around the C2SP protocols rather than each log recruiting its own friendly observer.
A cosigned checkpoint covers the log up to that size. Entries appended since the last cosignature are committed by the log's own signature only, until the next witnessing round picks them up.

The part nobody advertises: witnessing binds you

Before the pin, our append-only claim was policy. We could have quietly regenerated the log, re-signed it, and nobody outside would have been the wiser. After the pin it is a commitment with teeth, and the teeth point at us.

The log must now stay strictly append-only forever, because the witness's copy of every cosigned checkpoint is permanent evidence against any rewrite. And the log's signing key can no longer rotate casually: the witness pins the key it verified, and a checkpoint signed by an unknown key gets refused. We put both obligations in writing to the witness's operator — no history rewrites, and no key rotation without coordinating first — and they were confirmed back to us as the terms of witnessing.

Worth sitting with: a tamper-evident log is not a feature you add. It is a constraint you accept. If you are not prepared to be caught by your own infrastructure, external witnessing is not for you — which is precisely what makes it persuasive when you do accept it.

Check our log yourself

None of this asks for trust in the telling. Both views are public:

$ curl https://log.traceseal.io/checkpoint
$ curl https://witness.markovianprotocol.com/$(printf 'log.traceseal.io' | sha256sum | cut -d' ' -f1)/checkpoint

The bodies should match byte for byte, with the witness's cosignature as an extra line on the second. We have published the verifier we run daily — it checks the log's Ed25519 signature, the witness cosignature against the witness's public key, and that live and pinned bodies agree — as lib/tlog_witness.py in the Alibi repository.

Where this fits in an agent accountability stack

A signed receipt proves an execution record has not changed since it was sealed. An audit trail tells you what to put in that record. The transparency log proves the receipt existed before anyone had a reason to dispute it. The witness closes the last gap in that chain: it stops the log itself being quietly replaced. Each layer covers a failure the previous one cannot.

One witness is not the end state; a quorum of independent witnesses is. What ours bought is the step from "trust us" to "trust us, or catch us out through a party we do not control". How many witnesses a receipts log needs before a court or an auditor treats its timestamps as settled is a question nobody has an answer to yet. We would rather be early to finding out.

Originally published on the Traceseal blog. The receipt format, verifier and transparency log are open: spec, verifier on PyPI, public log.

AI agent audit trails: what to record, and what your records can prove

Ventse — Tue, 11 Aug 2026 08:51:37 +0000

An AI agent does not just answer questions. It calls tools, edits files, opens pull requests, moves money, sends messages. Sooner or later one of those actions gets questioned, by a customer, an auditor, a regulator, or your own incident review, and what you can say at that point depends entirely on what you recorded at the time.

Building a useful audit trail for an agent is really two problems, and teams usually only notice the first one. Completeness: did you capture the right events? Credibility: can anyone other than you believe the record? This post covers both, including the record-keeping duties the EU AI Act now attaches to high-risk systems.

What an AI agent audit trail should record

Chat transcripts are not an audit trail. The transcript records what the model said; the questions that matter later are about what the system did. A trail worth keeping records, for every run:

Which code and model ran. Agent and skill versions, the model identifier, and content hashes of the code that executed, not just a version string someone can retag.
The inputs. The task or prompt, the configuration, and the policy in force. Store sensitive payloads as SHA-256 digests rather than plaintext: a hash proves the input was what you say it was without retaining the data itself.
Every tool call. Name, arguments, result and exit status. Tool calls are where an agent touches the world; a trail that omits them records the commentary and drops the actions.
What changed. Files written, diffs applied, messages sent, records created, again as digests, so the artefact can be checked against the record later.
Timing. Start and end of the run and of each step. This is not gold-plating: for biometric systems, Article 12(3) of the EU AI Act requires logging "the period of each use of the system (start date and time and end date and time)" explicitly.
Human involvement. Which steps ran under an approval, and who gave it. When something goes wrong, the first question after "what happened" is "who signed it off".

The regulatory floor: EU AI Act record-keeping

If your agent falls in the Act's high-risk category, record-keeping stops being a best practice and becomes a duty with numbers attached. Three articles of Regulation (EU) 2024/1689 do the work:

Article 12 requires high-risk AI systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system", covering events relevant to identifying risk, post-market monitoring, and monitoring of operation by deployers.
Article 19 obliges providers to keep those automatically generated logs, to the extent they are under their control, for a period appropriate to the system's purpose and at least six months.
Article 26(6) places the mirror-image duty on deployers: keep the logs your high-risk system generates, again for at least six months, longer where other EU or national law (data protection in particular) requires it.

On timing: under Article 113 the Act applies generally from 2 August 2026, which brings the obligations for high-risk systems listed in Annex III with it; systems that are high-risk because they are safety components of regulated products (Article 6(1)) follow from 2 August 2027.

Most coding and operations agents are not high-risk systems under the Act. But the transparency duties in Article 50 already apply to systems that interact with people or generate content, and if you are going to keep records at all, the Act's six-month retention floor is the obvious number to copy rather than invent your own.

A complete log can still prove nothing

Suppose you record all of the above faithfully. You now have a trail that is excellent for debugging and incident response — and still worthless the moment someone outside your organisation needs convincing.

The problem is authorship. Application logs are written by the same system they describe, stored on infrastructure the operator controls, and editable by anyone with write access to the store. When the record's author is the party whose conduct is in question, the record cannot clear them. Security practice has long treated missing or unprotected logs as a top-tier weakness (it is A09 in the OWASP Top 10), but integrity is a separate property from existence. A log that exists, is complete, and could have been rewritten yesterday answers "what happened?" only for people who already trust you.

We have written up the full argument in why logs are not evidence; the short version is that WORM storage, centralised log collectors and hash chains each move the trust boundary without removing it.

Making the trail verifiable

The fix is mechanical, and none of it is exotic cryptography:

Hash every artefact the run touched, so the record commits to specific bytes rather than descriptions.
Serialise the record as canonical JSON, so there is exactly one byte sequence a signature can cover.
Sign it at execution time with an ed25519 key held outside the agent's reach, so neither the agent nor a later intruder can rewrite history without breaking the seal.
Anchor it in a transparency log, so the record provably existed before the dispute did.

That turns your audit trail into a receipt anyone can check offline, with no access to your systems:

$ pip install traceseal-verify
$ traceseal-verify receipt.json
[OK] receipt.json — operator signature verified

We walk through what that verification actually proves in an earlier post, and the honest limits matter here too. A signed receipt proves the record has not changed since it was sealed and who sealed it. It does not prove the record is complete: an action taken outside the instrumented path leaves no receipt at all. That is why receipts pair naturally with sandboxing the agent — the sandbox narrows what can happen off the record, and the receipt seals what happened on it.

The test worth applying: pick one agent action from last month and try to show a third party what happened, without asking them to trust your database. If the exercise ends at "here is a row in our logging system", you have an audit trail. You do not yet have evidence.

A checklist you can apply this week

Record tool calls and artefacts, not just conversation.
Hash sensitive inputs and outputs instead of hoarding them.
Retain records for at least six months, the floor set by Article 19 and Article 26(6).
Sign records when they are made. A trail you start keeping after the dispute begins says nothing about what came before.
Rehearse retrieval: if you have never pulled a specific run's record under time pressure, you do not know whether you can.

The receipt format, verifier and transparency log are open — the spec, the verifier on PyPI, and the public log. You can adopt the format without adopting us.

Originally published on the Traceseal blog.

How to sandbox an AI coding agent (and what a sandbox cannot prove)

Ventse — Tue, 04 Aug 2026 08:50:37 +0000

The question usually arrives after the run rather than before it. An agent has spent forty minutes in a repository, the diff is larger than anyone expected, and somebody asks whether it touched anything outside the working directory. The instinct is to search the transcript. The trouble with that instinct is the one this blog keeps returning to: the transcript is written by the process you are asking about, so a clean transcript is exactly what a misbehaving run produces.

The durable answer is to make the action impossible rather than to watch for it. This post is a working profile for doing that on Linux, an honest account of where it leaked when we tested it, and the point at which a sandbox stops helping.

What a sandbox is, underneath the word

"Sandbox" is used loosely enough to mean anything from a Docker container to a permissions prompt. On Linux it has a specific meaning, assembled from three kernel facilities:

Namespaces give a process a private view of a global resource: its own mount table, process tree, or network stack (namespaces(7)). User namespaces are the piece that matters for developer tooling, because they let an ordinary account create the others without root.
Seccomp filters system calls, so a process can be denied whole classes of kernel interface rather than denied a file (seccomp(2)).
Landlock lets an unprivileged process restrict its own filesystem access and never get it back, which is the right shape for a wrapper that launches something it does not trust (kernel documentation).

Bubblewrap is a small setuid-or-userns tool that composes the first two into a single command. It is what Flatpak uses underneath, it needs no daemon, and it starts in milliseconds, which matters when the thing you are wrapping is invoked hundreds of times a day. Everything below was run against bubblewrap 0.11.0 on Debian.

A profile that actually runs

The shape you want for a coding agent is narrow: it may read the system, it may write to one directory, and it may not reach the network.

$ bwrap \
    --ro-bind / / \
    --bind "$PWD" "$PWD" \
    --dev /dev --proc /proc \
    --unshare-net \
    --unshare-pid \
    --die-with-parent \
    --chdir "$PWD" \
    -- your-agent-cli run

Line by line: --ro-bind / / mounts the entire host filesystem read-only, so the agent keeps the toolchain, libraries and language runtimes it needs and can modify none of them. --bind "$PWD" "$PWD" punches one writable hole at the working directory. --unshare-net puts the process in a fresh network namespace with no interface but loopback. --unshare-pid stops it seeing or signalling other processes on the box, and --die-with-parent means an orphaned agent is killed rather than left running.

Two classes of action stop being things you monitor and become things that cannot happen. A write outside the working directory fails at the kernel:

$ touch /home/tim/SHOULD_NOT_EXIST
touch: cannot touch '/home/tim/SHOULD_NOT_EXIST': Read-only file system

And there is no route off the machine, so a connection to a raw address fails to establish. That is a better guarantee than any amount of transcript review, because it does not depend on the agent's cooperation, its honesty, or your diligence in reading the output.

Where it leaked

Testing the profile above produced a result we did not expect. Egress was properly gone: ip route was empty inside the namespace and curl to a bare IP address failed to connect. But name resolution still worked.

$ getent hosts example.com
2606:4700:10::6814:179a  example.com
2606:4700:10::ac42:93f3  example.com

The explanation is in /etc/nsswitch.conf. Debian's hosts line includes the resolve module, which does not send a DNS packet at all: it talks to systemd-resolved over a Unix socket at /run/systemd/resolve/io.systemd.Resolve. That socket arrived inside the sandbox as an ordinary file, carried in by the read-only bind of /. Masking the directory confirms it, and the resolution stops:

$ bwrap ... --unshare-net --tmpfs /run/systemd/resolve -- getent hosts example.com
$   # no output

The general lesson is worth more than the specific fix. A network namespace governs interfaces, routes and sockets in the network stack. It has nothing to say about a Unix socket to a host daemon that still has full network access, and a filesystem bind will hand you one of those without mentioning it. Anyone auditing an agent sandbox should assume the same is true of the container runtime socket, the SSH agent socket, and the D-Bus session bus.

Worth stating plainly: we wrote the confident version of the paragraph above first, then ran it, and the run disagreed. A sandbox profile that has not been driven end to end is a hypothesis about isolation, not a control.

Three further limits are structural rather than fixable. The working directory is writable by design, and for most repositories that is where the interesting secrets live: .env files, and .git/config remotes with an access token embedded in the URL. Environment variables cross the boundary untouched unless you add --clearenv, so an API key exported in the parent shell is available inside. And the kernel is shared, which is the standing caveat on all container-style isolation and the reason NIST SP 800-190 treats it as weaker than a virtual machine boundary. Docker's none network driver is the same idea with the same caveats, if a container is already in your stack.

The part nobody budgets for

Isolation changes what the agent does, not only what it is able to do, and this is a genuine operational cost rather than a footnote. An agent that cannot reach the network will still try to install a package. When that fails, it improvises: it writes a stub, or vendors something from a cache, or quietly adjusts a test so the missing dependency stops mattering. The run does not stop; it goes sideways.

The second effect is on diagnosis. A run that failed because the sandbox blocked it and a run that failed because the task was wrong produce output that looks much the same, and the agent's own explanation of which one happened is not evidence either. Teams adopting sandboxing tend to lose a week to this before they start logging the policy denials separately from the task failures. It is worth doing on day one. This is also why grading agents against ground truth on disk beats grading them on what they said they did.

From control to evidence

Here is the limit of everything above. A sandbox constrains; it does not communicate. You now know the agent could not write outside the repository. A customer, an auditor or a regulator asking the same question next quarter still has nothing but your description of a profile you say you applied.

Closing that gap is what an execution receipt is for. The receipt specification carries a sandbox_profile_hash field: a SHA-256 hash of the sandbox configuration, meaning the bubblewrap argument list plus the environment. A verifier holding a known-good profile can hash it and check whether the run used that profile or a different one, offline, with one command and no access to your systems. Combined with the signature over the whole record, an altered profile cannot be presented as the original. For what the signature covers and what an [OK] means, see the walkthrough and the primer on why logs are not evidence.

What that does not do is more interesting, and the specification says so itself rather than leaving a reader to discover it. Among the things a valid receipt does not prove:

That the sandbox actually enforced the declared profile (the receipt records what the operator claims the sandbox was; a compromised operator could lie).

Section 6.1 of the same document puts it more bluntly still: the receipt is "an attestation, not a proof of execution in the zero-knowledge sense". An operator who never ran bubblewrap at all can sign a receipt naming a profile hash they took from the documentation.

What is still open

That last gap does not close by thinking harder about receipt design, and we are not going to pretend a signature solves it. It closes only by moving the seal outside the party being trusted, and each route out has a real cost. A second party can run or observe the sandbox and cosign the record, which works and requires someone willing to be that party. Hardware-rooted attestation can bind the measurement to a chip rather than an assertion, at the price of a much heavier deployment. A third-party execution environment removes the operator's discretion entirely, along with the operator's control of their own infrastructure.

Which of those becomes normal is going to be settled by procurement departments and insurers rather than by cryptographers, and probably not this year. In the meantime the honest position is that a signed profile hash moves an unverifiable claim to a checkable one and stops short of proof, which is still a considerable distance from a log file nobody can check at all.

The regulatory direction is at least consistent with the effort. Article 15 of Regulation (EU) 2024/1689 requires high-risk systems to be designed for an appropriate level of accuracy, robustness and cybersecurity across their lifecycle. A demonstrable containment boundary is easier to argue than a policy document describing one.

Questions to ask of your own setup

Has the profile been run, or only written? Try to write outside the workdir and try to reach the network from inside it. Ours resolved DNS through a socket we had not thought about.
What sockets came in with the filesystem? Enumerate what is under /run and /var/run in the mount. Each one is a channel your network namespace does not cover.
What is in the environment? If you have not used --clearenv, every secret in the parent shell is inside the sandbox.
Are policy denials logged separately from task failures? If not, you cannot tell a blocked agent from a confused one.
Can anyone outside your team check which profile ran? If the answer is that you would tell them, that is a description, not a record.

The receipt format, the verifier and the transparency log are open. You can adopt the format without adopting us.

Alibi: grade coding agents on what actually happened on disk

Ventse — Thu, 30 Jul 2026 08:36:27 +0000

Ask a coding agent whether it finished the job and it will usually say yes. The closing summary may be fluent, itemised and confident. None of that proves what happened.

We have written before about why logs are not evidence: a record produced by the system it describes inherits that system's honesty. An agent's account of its own run has the same defect one layer up.

So we built Alibi, an MIT-licensed harness that ignores the account entirely. Alibi runs the same missions through agentic CLIs and grades each run against ground truth on disk: the files that exist and the changes that were made. It never grades what the agent says it did.

The grading rule

Each configured CLI, currently Claude Code and OpenAI Codex, receives an identical mission brief inside its own bubblewrap sandbox. Each lane gets a private working tree, an isolated home and an isolated /tmp.

When the process exits, Alibi inspects the tree:

Does the requested file exist?
Does it contain what the mission required?
Did the specified tests pass?
Did anything change outside the permitted area?

The agent's exit message is not consulted. A mission passes if the disk says it passed.

The sandbox also makes containment measurable. A write outside the allowed tree is a recorded violation, not a judgement about style. Alibi retains the working directory, sandbox home, temporary files and logs after the run, so someone can derive the grade again and dispute it.

What Alibi refuses to claim

Alibi is not a leaderboard. The mission set is small and the runs happened on our machines. A handful of missions is a probe, not a census, so we are not publishing rankings from it.

It also says nothing about consent behaviour. Lanes run with approvals granted by design because the object of study is execution, not permission seeking. How a CLI behaves when it has to ask first is a separate question.

The grades remain Alibi's judgement. Every assertion is ordinary code in the mission definition. You can read a check, run it again and dispute it.

The grader cannot be trusted either

A grading harness has the same structural problem as the agents it grades: it produces the record of its own run. If our scores mattered to anyone, we could quietly edit them.

Alibi now supports signed Traceseal receipts. Point one environment variable at an Ed25519 key and each CLI and mission result is sealed into a receipt containing hashes of:

the mission definition
the result record
the retained evidence tree

A run-level receipt chains those results into one verifiable unit. Signing happens on the host after the contained processes exit, and the key is never mounted inside the sandbox.

A second party can act as a witness. The witness tool derives every hash again from the retained evidence, checks each signature and the chain, and cosigns only if everything matches. It refuses to cosign with the original signer's key.

There is an important limit. Two keys on one machine prove key separation, not operator separation. Full independence requires the witness to verify on hardware the original signer cannot write to.

The signature means "this run occurred as described." The scores remain Alibi's judgement. Signing makes them tamper-evident, not true.

What to ask of any agent benchmark

First, what record was it graded against? If the answer is the agent's final message, the benchmark measured prose.

Second, could the operator rewrite the results afterwards? A results table in a repository the grader controls is still a log.

Third, can you run it yourself? The missions, assertions and harness should be readable and executable without the author's cooperation.

Finally, what was the consent model? Auto-approved runs measure capability. They do not measure conduct, and a result that blurs the two flatters everyone.

Alibi is our attempt to answer those questions cleanly for our own testing. Whether its missions generalise beyond the behaviours we care about remains open. The repository is small enough to read in an afternoon.

Read the missions, dispute the assertions and grade your own agent on GitHub.

Signed execution receipts: a primer on why logs are not evidence

Ventse — Tue, 28 Jul 2026 08:47:31 +0000

Every team running AI agents keeps logs. Almost none of them can answer the question that actually gets asked in a dispute: why should anyone believe them?

A log is a record your system keeps about itself. It is useful for debugging, indispensable for operations, and — on its own — close to worthless as proof. This is a primer on the difference, and on what a signed execution receipt adds that a log cannot.

What evidence actually demands

Strip away the legal vocabulary and a record has to satisfy four things before a sceptical outsider should rely on it:

Integrity. It has not been altered since it was created — and if it has, that fact is detectable.
Attribution. Someone specific is on the hook for it. A record nobody vouched for commits nobody.
Completeness. You are seeing the whole set, not a selection made after the fact by an interested party.
Independence. The check can be performed by the doubter, without the cooperation of the party being doubted.

Note that admissibility is a much lower bar than any of this. English civil procedure will receive a business record in evidence without requiring a witness to speak to it (Civil Evidence Act 1995, s.9). Getting a log in front of a tribunal is easy. What the tribunal then decides it is worth is the entire question, and that is where ordinary logging collapses.

Where logs fail, property by property

An application log fails all four, and it fails them structurally rather than through bad implementation:

Integrity: the log is a mutable file on infrastructure the operator controls. Anyone with disk or database access can rewrite history and leave no trace in the artefact itself. This is not a novel observation — computer-security guidance has said for two decades that log data requires explicit protection precisely because it is alterable by whoever holds the system (NIST SP 800-92), and the federal control catalogue carries a dedicated control, AU-9 Protection of Audit Information, for exactly this problem (NIST SP 800-53 Rev. 5).
Attribution: the agent writes the log describing the agent. The witness and the accused are the same process. A misbehaving or compromised agent writes a clean log by construction.
Completeness: what reaches an auditor is a filtered export — a date range, a grep, a dashboard screenshot. The absence of an entry is indistinguishable from an entry that was never emitted, dropped under load, or removed.
Independence: verification means asking the operator for the file and believing what arrives. That is not verification; it is a courtesy.

The structural problem: a log asks the reader to trust the writer. No amount of log quality fixes that, because the defect is in the direction of trust, not in the contents.

The partial fixes, and where each one stops

The industry has good, real answers to pieces of this. It is worth being precise about what each one buys, because teams routinely believe they have solved evidence when they have solved storage.

Centralised logging / SIEM. Moves the log off the machine that produced it, so a single compromised host cannot quietly rewrite it. Real improvement. But the collector is still operator infrastructure, so integrity now rests on the operator's word about the collector instead of about the host.
Append-only and WORM storage. Prevents edits at the storage layer. Also a real improvement — and enforced by a policy the operator configures, can reconfigure, and is asking you to take on trust. It constrains the operator; it does not let an outsider check anything.
Hash chaining. Each entry commits to the hash of the previous one, so removing or editing an entry breaks the chain — the idea behind digital timestamping since Haber and Stornetta (1991). This is genuinely strong, and it is why Traceseal keeps a hash-chained audit log underneath the receipts. Its limit: a chain proves internal consistency. Whoever holds the chain can rebuild it end to end and present a perfectly consistent alternative history, unless the chain is anchored to something outside their control.
Trusted timestamps and transparency logs. The anchoring step. An RFC 3161 timestamp binds data to a time via a third party; a Merkle-tree transparency log in the RFC 9162 style makes it cryptographically awkward to show two different histories to two different observers. This is the piece that closes the "rebuild the chain" gap.

Read that list in order and a pattern emerges: each step moves a claim from "trust the operator's process" towards "check the maths yourself". A signed receipt is simply the end of that road, packaged so a single file carries the whole argument.

What the signature adds

An execution receipt is a self-contained JSON document recording one execution: which signed code ran, what it consumed and produced (as SHA-256 hashes, per FIPS 180-4, so the record proves integrity without exposing the data), the sandbox policy it ran under, and an Ed25519 signature (RFC 8032) over the lot.

Three design choices do the actual work:

The signature covers a canonical encoding. Keys sorted at every level, no whitespace, no booleans or nulls — so a given receipt has exactly one valid byte sequence. There is no room for a semantically identical but differently-encoded document to pass. Any edit anywhere breaks verification.
The public key travels inside the receipt. Verification is offline and self-contained: no key server, no API call, no account, no request to the operator. The doubter is not dependent on the doubted.
Hashes, not contents. Because inputs and outputs appear only as hashes, a receipt can be published without leaking the data it describes — and anyone holding the original data can recompute the hash and confirm the match.

Set against the four properties: integrity comes from the canonical signature, attribution from the operator key that signed it, independence from offline verification, and completeness from anchoring the record in a public transparency log. That last one is worth stating plainly, because it is the property most evidence schemes quietly skip.

The format is fully specified — the receipt specification is written so that a developer can implement a verifier in any language without touching our code, and the reference verifier is on PyPI:

$ pip install traceseal-verify
$ traceseal-verify receipt.json
[OK] receipt.json — operator signature verified

For a field-by-field walkthrough of a real receipt and what an [OK] does and does not prove, see how to verify what an AI agent actually did.

Why this is becoming a compliance question

The EU AI Act already distinguishes keeping records from being able to stand behind them. Article 12 of Regulation (EU) 2024/1689 requires high-risk systems to allow the automatic recording of events over their lifetime, to a standard appropriate for traceability. Article 19 requires providers to keep those automatically generated logs where they are under their control. The obligation is to produce a record that supports traceability — and a record that the producing party can silently rewrite supports it only as far as that party's credibility extends.

Nothing in the regulation mandates cryptographic receipts. But when the moment comes to demonstrate traceability to a regulator, an enterprise customer or an insurer, the difference between a log export and a signed receipt is the difference between asking to be believed and inviting a check.

What to ask of your own stack

If an insider altered our records, how would we know? If the answer relies on that insider's access being correctly restricted, you have a control, not evidence.
Can an outsider verify without our help? If verification requires you to hand over a file and be believed, the record proves nothing about your good faith to someone who doubts it.
Is the record anchored outside our control? Internal consistency is not the same as an unrewritable history.
Was it sealed at the time? Receipts only cover executions that were instrumented when they ran. Evidence collection that begins when the dispute begins proves nothing about what came before.

Originally published at traceseal.io/blog. The receipt spec, verifier and transparency log are open — you can adopt the format without adopting us.

How to verify what an AI agent actually did

Ventse — Tue, 21 Jul 2026 08:46:24 +0000

Your agent says it finished the job. Its log file agrees. Neither of those is evidence: the log was written by the same process it describes, and it can be rewritten afterwards by anyone with disk access. If you need to show a customer, an auditor or a court what an agent did, you need a record that fails loudly when altered and that a stranger can check without trusting you. This is a practical walkthrough of doing exactly that with an open verifier and a signed execution receipt.

Step 1: install the verifier

The verifier is a small open-source Python package with a published receipt specification:

$ pip install traceseal-verify
$ traceseal-verify receipt.json
[OK] receipt.json — operator signature verified

The check runs offline. It needs no account, no API call and no access to the operator's infrastructure — which is the point. Verification that requires the operator's cooperation is not independent verification.

Step 2: read the receipt — the anatomy

A receipt is a single JSON document with three blocks. Here is a real one, abridged:

{
  "attestation": {
    "attested_at": "2026-04-15T05:29:04Z",
    "operator_fingerprint": "ed25519:d8d13a6f...",
    "operator_public_key": "3ba02728...",
    "signature": "4678a52c..."
  },
  "execution": {
    "skill_name": "yoast-seo-audit",
    "skill_version": "0.1.0",
    "inputs_hash":  "sha256:6ac78ba8...",
    "outputs_hash": "sha256:66858bb9...",
    "sandbox_profile_hash": "sha256:e7a3e6b8...",
    "skill_manifest_hash":  "sha256:79c14974...",
    "exit_code": 0,
    "ok": "true",
    "wall_time_ms": 47
  },
  "provenance": {
    "manifest_hash": "sha256:79c14974...",
    "publisher_fingerprint": "ed25519:d8d13a6f...",
    "transparency_log_seq": 5
  },
  "receipt_version": "1.0"
}

Each block answers a different question:

provenance — which code ran. The publisher signs a content-addressed manifest: every artefact (the skill definition, its capability declaration, the code itself) is listed by its SHA-256 hash (FIPS 180-4). Change one byte of the code and the manifest hash no longer matches.
execution — what happened. Inputs, outputs and the sandbox policy are recorded as hashes of their canonical JSON form. That proves integrity without exposing the data — you can demonstrate the output is unchanged without publishing the output.
attestation — who vouches for it. The operator signs the whole record with an Ed25519 key (RFC 8032). The signature covers a canonical JSON encoding — sorted keys, fixed separators — so there is exactly one valid byte sequence for a given receipt. Any edit anywhere breaks the seal.

Step 3: understand what the check proves

When traceseal-verify prints [OK], four things have been established:

The receipt is byte-for-byte what the operator signed — nothing was edited afterwards, by the agent, the operator's tooling, or anyone who handled the file since.
The code that ran is exactly the code the publisher signed, down to the hash of each file.
The recorded inputs, outputs and sandbox policy are the ones present at execution time — anything you are later shown can be checked against the hashes.
The signing key is identified by fingerprint, so repeated receipts from the same operator are linkable, and the receipt can be anchored in a public transparency log (the transparency_log_seq field), which prevents the operator quietly maintaining two versions of history.

What a receipt does not prove

Honest tools state their limits, and this matters if you ever rely on a receipt in a dispute:

It does not prove the work was good. A receipt proves what ran and what it produced — not that the output was correct. Checking outcomes against ground truth is a separate, complementary verification step.
It does not prove events it never covered. A receipt seals one execution. Actions taken outside sealed executions are simply absent — which is why instrumentation has to start before the incident, not after.
It binds a key, not a person. The signature proves the holder of the operator key vouched for the record. Tying that key to a legal identity is a key-management question, the same as with any signing scheme.

The trust inversion: with logs, the burden is on the reader to trust the writer. With signed receipts, the burden is on the record to survive verification. That is the difference between "our system says it behaved" and "check it yourself".

Why this beats screenshots and log exports

The evidence teams typically produce today — screenshots, log exports, dashboard PDFs — shares one flaw: it is all produced by, or under the control of, the party whose behaviour is in question. Computer-security guidance on log management has warned for years that logs require protection precisely because they are alterable by whoever controls the system (NIST SP 800-92). A detached signature over a canonical record removes the alterability, and an open verifier removes the need to take anyone's word for it.

Everything shown here is open: the receipt spec, the verifier on PyPI, and the transparency log. You can implement the format yourself; the spec even includes a reference canonical-JSON encoder.

Originally published on traceseal.io.

EU AI Act Article 50: what it means for teams running AI agents

Ventse — Sun, 19 Jul 2026 10:14:59 +0000

On 2 August 2026 the transparency obligations in Article 50 of the EU AI Act (Regulation (EU) 2024/1689) became applicable. I run agents daily and I build tooling for them, so I have spent more time inside this article of the Act than is probably healthy. The short version: if your organisation deploys AI systems that interact with people or produce content, this now applies to you. Agents do both. And it applies wherever the system's output is used in the EU, so "we're not an EU company" is not the exit it sounds like.

What Article 50 actually requires

Four duties, in practical terms:

People must know they are interacting with an AI system, unless it is obvious from context.
Systems that generate text, audio, image or video must mark outputs as artificially generated, in a machine-readable form "where technically feasible". That quoted phrase carries a lot of weight, and I have not seen a settled answer on what it means for plain text.
Organisations deploying emotion recognition, biometric categorisation or deepfake-style generated content must inform the people affected.
AI-generated text published to inform the public on matters of public interest must be disclosed as such, unless a human took editorial responsibility for it.

Penalties for non-compliance run up to €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)).

Why agents are the hard case

For a chat window, disclosure is a banner. Done.

An agent plans, calls tools, edits files, sends messages and commits code. The transparency question stops being "did we tell the user it's AI?" and becomes "can we show what the system actually did?" Those are very different engineering problems.

The uncomfortable part is that the standard answer, application logs, proves nothing to anyone outside your organisation. Logs are written by the same system they describe. They can be edited after the fact. When an agent's action is challenged (a wrong transaction, a leaked file, a published article), "our logs say it behaved" is an assertion, not evidence. A regulator, an auditor or a journalist has no reason to take your word for it.

Making the record verifiable instead of trusted

The approach we took with Traceseal is to make the execution record tamper-evident and checkable by a third party:

The publisher signs the agent skill with an ed25519 key over a content-addressed manifest, so it is provable which code ran. The operator runs it in a kernel-namespace sandbox and signs a record of inputs, outputs, timing and sandbox policy. The record stores SHA-256 hashes rather than the data itself, so it proves integrity without exposing anything sensitive.

Anyone can then check the receipt offline, with no access to the operator's systems:

$ pip install traceseal-verify
$ traceseal-verify receipt.json
[OK] receipt.json — operator signature verified

The receipt is canonical JSON under a signature, so any tampering breaks the seal, whether it comes from the agent, the operator or someone downstream.

An honest limitation: a receipt only covers executions that were sealed at the time. If you start keeping records after a dispute begins, you have proof of nothing that came before. That cuts both ways. It is an argument for instrumenting now, and it is also a real gap if you are hoping to retrofit compliance onto last quarter's agent runs. You cannot.

I also do not know yet how regulators will weigh a signed receipt against an ordinary log file when the first Article 50 disputes actually land. The Act sets out the duties. Enforcement practice will be written by cases that have not happened. My bet is that "check it yourself" evidence beats "trust me" evidence in front of any tribunal, but it is a bet.

Before your next agent ships

Inventory your agents: anything that talks to people or generates content is in scope for at least one of the four duties. Then decide what your evidence standard is. Screenshots and logs are trust-me evidence. Signed receipts are check-it-yourself evidence.

The receipt format, the verifier and the transparency log are open: the spec, the verifier on PyPI, and the public log are all at traceseal.io. You can adopt the format without adopting us.

Proving What Your AI Agent Did: Introducing Traceseal

Ventse — Thu, 16 Apr 2026 14:01:09 +0000

Every AI agent framework can make agents do things. None of them
can prove what the agent did.

When a client asks "was your AI agent running authorized code when
it published that article?" the answer today is "trust me." When a
regulator asks "what capabilities did the automated system have?"
the answer is "trust me." When something goes wrong and someone
asks "what exactly happened?" the answer is still "trust me."

We built Traceseal to replace "trust me" with math.

What Traceseal does

Traceseal produces an Execution Receipt — a signed JSON document
that proves:

What code ran (manifest hash over every source file)
Who authorized it (publisher's ed25519 signature)
What sandbox it ran in (hash of the kernel-namespace configuration)
What it produced (SHA-256 of inputs and outputs)
Who vouches for it (operator's ed25519 signature over all of the above)

A third party verifies the receipt with one command:

pip install traceseal-verify
traceseal-verify receipt.json

[OK] receipt.json
  skill:     agentmail v1.2.0
  operator:  ed25519:f19bc125...
  publisher: ed25519:a07c7eb5...

No access to the operator's machine. No trust assumptions. Just math.

What we built

8 weeks. 217 tests. 27-entry audit chain on real Debian 13 hardware.
Three signed production skills with verified receipts:

A multi-entry-point skill bundle — signed, sandboxed with
kernel-namespace isolation, receipt verified by a third party. 116ms.
A real production skill with SDK dependencies — the agentmail
SDK was mounted read-only into the sandbox. The execution failed
(bad API key) and the receipt honestly records the failure.
The system doesn't hide bad outcomes — it seals them.
A web scraping skill — signed, sandboxed, 47ms, receipt verified.

The full pipeline — sign, sandbox, execute, receipt, verify — runs
in under 200ms.

Why this matters

AI agents are moving from demos to production. When they get there,
someone will ask for proof. Proof that the code was authorized.
Proof that the sandbox was real. Proof that the outputs weren't
tampered with. Proof that a third party can check independently.

Every other trust system in the AI agent space offers dashboards,
not proofs. They log what happened. We seal it. The difference:
a log says "the operator claims this happened." A receipt says
"anyone can independently verify this happened."

Open spec, open verifier

The Execution Receipt Specification is Apache 2.0:
→ RECEIPT-SPEC.md

The standalone verifier is Apache 2.0:
→ pip install traceseal-verify
→ GitHub

The transparency log is live:
→ log.traceseal.io

Anyone can verify receipts. Anyone can implement the spec.
The hard part — signing, sandboxing, audit logging, the full stack
that generates receipts worth verifying — is Traceseal.

What's next

Traceseal currently produces receipts for skill execution. We're
extending the receipt format to cover:

Model call receipts — prove which model processed your data
Orchestration receipts — prove a multi-step workflow executed in order with declared inputs at each step
Data flow receipts — prove what data was sent where

Same format. Same verifier. Same transparency log.

The goal: a cryptographic audit trail for every action your AI agent
takes, verifiable by anyone, without trusting the operator's machine.

→ traceseal.io