DEV Community: Ventse

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