Update (Nov 4): v0.8.0 and v0.8.1 are out.
v0.7
- The exfiltration attack now runs against GitHub's real MCP server, with throwaway repos and labels from the
githubpreset. - Cedar policies cover authorization rules that roles can't express, such as working hours or "only repos in my org".
v0.8: labels follow data across more hops
-
Sub-agents share their parent's label: a sub-agent starts from what its parent has seen, and what it reads taints the parent. In Claude Code, add a
SubagentStarthook; in other frameworks, start the sub-agent's gateway withADTL_SESSION_ID=<parent session>. Audit entries name the sub-agent. - Agent-to-agent (A2A): a draft extension puts the sender's label on A2A messages and artifacts, signed with its key and bound to the content. The receiver trusts labels from keys it knows; any other key can only make the label stricter. A message edited in transit fails closed. Demo.
-
FIDES / fides-gateway: ADTL reads fides-gateway labels as server claims, and with
fides: { emit: true }it also writes them on results and outgoing tool calls, so the two can sit in one chain. -
Memory servers, again (thanks to Edward's comments below): Mem0's hosted docs say
update_memoryreplaces metadata, which would wipe the per-session stamps. A new tool rule,recordIds: id, makes the ledger also remember tainted writes by record id, so the label survives a replacing update. A merge that keeps the tainted text as a whole line keeps the label too; a merge that rewords it doesn't, so give read tools a strict rule if your account runs Merge. -
Catching up with the drafts: per-interceptor overrides and interceptors from several servers (SEP-2624), and tools that describe themselves with the draft
action-metadataannotations. A tool that saysrequiresReview: truenow gets an "ask" before it runs.
Still open: I haven't checked hosted Mem0 against a real key yet (#48). Release notes.
Update, Oct 25: ADTL is now at v0.6.0. Since this post: labels also follow records through memory servers that rewrite what you store (thanks to the discussion in the comments), ledger entries, declassifications and session receipts are signed, and there's a playground you can try without setting anything up:
npx -y @adtl/gateway playground. Details are marked "Update" below.
I've been working on a side project called ADTL (Agent Data Trust Labels) for a while now. It just hit v0.4, and the new part is something I didn't expect to need when I started, so I wanted to write up how I got there.
Quick disclaimer up front: it's a personal open-source project, it's experimental, and it's built on MCP proposals that are still drafts. Please don't put it in front of anything important yet.
The problem
AI agents read a lot of stuff they shouldn't trust. GitHub issues written by strangers, web pages, emails. And the same agent usually has tools that can send data out: post a comment, send a mail, fetch a URL.
That combination is the whole problem. In 2025 Invariant Labs showed it against GitHub's official MCP server: a public issue contained a hidden instruction telling the agent to read a private repo and post its contents as a comment. The agent did it.
You can tell the model "ignore instructions in tool results", and good models often do. But "often" isn't a security property. I wanted something that doesn't depend on the model noticing the attack.
The idea: label everything, check before acting
ADTL is an MCP gateway. Your agent (Claude Code, Cursor, anything that speaks MCP) talks to ADTL, and ADTL talks to your real MCP servers.
Every result that comes back gets a label with two parts:
-
integrity: can this be trusted to influence what the agent does? (
trusted,unknown,untrusted) -
confidentiality: who may see it? (
public,private,secret)
The session keeps a running label that only gets stricter. Read one untrusted issue and the session is untrusted until it ends. Read one private file and it's private.
Then before every tool call, a policy checks the session label against where the tool can send data:
policy:
rules:
- name: no-public-write-after-untrusted
when:
session.integrity: untrusted
tool.egress: [public, external, unknown]
then: ask
- name: private-stays-private
when:
session.confidentiality: [private, secret]
tool.egress: public
then: block
So in the GitHub attack: the agent reads the issue (untrusted), reads the private file (private), then tries post_comment (public). That's blocked, no matter what the model thinks it's doing.
"Ask" can send a push notification to your phone with Allow / Deny buttons (through ntfy). For Claude Code's built-in tools (more on that below) it shows Claude Code's normal permission prompt instead.
The labels use MCP's draft trust-annotations format, and the checks run as interceptors from the SEP-2624 draft. I didn't want to invent a new format if one was already being worked on.
Trying it on your own setup
If you already use MCP servers in Claude Code, this imports them:
npx -y @adtl/gateway init -c adtl.yaml --from .mcp.json # shows what it would do
npx -y @adtl/gateway init -c adtl.yaml --from .mcp.json --write # does it (keeps .bak copies)
It moves your servers into adtl.yaml, writes a starting rule for every tool (there are presets for GitHub, filesystem and fetch, and strict defaults for everything else), and points .mcp.json at the gateway. Then you go through the rules marked review and loosen what makes sense.
The gap I had to close first: built-in tools
The gateway only sees MCP traffic. Claude Code also has its own tools: WebFetch, Bash, Read. A web page fetched with WebFetch never went through ADTL, so it never tainted the session.
So v0.3.1 added a Claude Code hook. It runs before and after every tool call, labels the output, and checks the same policy:
{
"hooks": {
"PreToolUse": [{ "matcher": "*", "hooks": [{ "type": "command", "command": "npx -y @adtl/gateway hook --config /path/to/adtl.yaml", "onFailure": "block" }] }],
"PostToolUse": [{ "matcher": "*", "hooks": [{ "type": "command", "command": "npx -y @adtl/gateway hook --config /path/to/adtl.yaml" }] }]
}
}
The gateway and the hook share one session label (Claude Code passes the same session id to both), so a WebFetch taints the session for a GitHub post through the gateway, and the other way around. If ADTL would allow a call, the hook just stays quiet, so your normal Claude Code permissions still apply. ADTL never approves anything on its own.
Then I thought about Tuesday
With all that working, I tried this:
-
Monday: the agent fetches a web page. Hidden in it is an instruction for AI agents. The agent saves the page into
notes.md. The session is untrusted, but it doesn't do anything bad, so nothing gets blocked. The session ends. -
Tuesday: you start a fresh session and ask it to look at yesterday's notes. It reads
notes.md, finds the instruction, and posts the attacker's link as a public comment.
ADTL let it through. Tuesday's session never saw the web page, and reading a file from your own project is trusted. Every individual step looked fine.
Session labels end when the session ends. The data doesn't.
The ledger
v0.4 adds a label ledger. The idea is simple: labels should follow the text, not the process.
- When a session that has read untrusted or private data sends text anywhere (writes a file, stores something in a memory server, hands a prompt to a sub-agent, even lines a shell command appended to a file), ADTL hashes that text and stores the hashes with the session's label.
- When any result comes back, in any session, ADTL hashes it the same way and looks it up. If it matches, the old label comes back too.
It hashes the whole text, each paragraph and each line (normalized for case and whitespace, and skipping short lines like }), so a paragraph copied into a bigger file still matches. If the agent rewrote the text in its own words, that's fine too, because whatever a tainted session writes is recorded with its label.
Clean sessions record nothing, so the ledger stays small and you don't get your whole codebase flagged.
Update: this hashing only works if what comes back is the text that was sent. Some memory servers (Mem0, for example) extract facts with a model or rewrite records, so nothing matches. Since v0.5, ADTL can stamp the session's label into the record's metadata and read it back, and keep a tainted session's messages out of clean sessions' context. The comments below go through how we found that.
It's one SQLite file (~/.adtl/ledger.db), using Node's built-in node:sqlite. Entries are hash-chained, so adtl-gateway ledger verify can tell if someone edited or deleted entries. If you've checked a file and want to trust it again, you can clear its label:
adtl-gateway ledger declassify notes.md
The hook asks you before the agent can run that itself, and it won't let the agent edit the ledger file directly.
There's a demo that runs the real processes twice, once without the ledger and once with it:
git clone https://github.com/probita-ai/adtl && cd adtl
npm install
npm run demo:ledger
Without the ledger, Tuesday's read of notes.md comes back trusted and the link gets posted. With it, the read comes back as untrusted, written by session mon, and the post is stopped.
It works the same with real Claude Code across two separate sessions, which was a relief.
What it doesn't do
I'd rather be clear about this than have someone find out the hard way:
- Matching is by content hash. If a person rewrites the text by hand, or it's binary, or an MCP server returns it base64-encoded, it won't match.
- The ledger is hash-chained but not signed yet. An agent with shell access could rebuild the whole file, and
verifywouldn't catch that. The hook makes it harder, not impossible. (Update: since v0.6.0, entries and declassifications are signed with a per-machine key, andverifyreports entries signed by another key. Someone who can read the key can still sign a rebuilt file, so keep the key out of the agent's reach.) - The hook checks shell commands against the policy, but once a command is allowed, the shell can do anything. Keep a sandbox. ADTL is one layer, not the only one.
- It only knows about tools you've described. Unknown tools get strict defaults, which is safe but means more "ask" prompts until you write rules.
What's next
-
Signed session receiptsUpdate: shipped in v0.6.0 asadtl-gateway receipt <session>. - Running the GitHub demo against the real
github-mcp-server, not just my fake one. - Carrying labels across agents (A2A). Update: planned for v0.7; signed ledger entries already shipped in v0.6.0.
I've also proposed the "ask a human" idea to the MCP Interceptors working group as a spec PR. It's under review, so we'll see where it goes.
If you try it, I'd really like to hear what breaks. Issues are open on GitHub, and some are marked help wanted.
Top comments (15)
A memory server is the sink in that list where a later read is expected to return what was written, and often does not. The ledger hashes what the tainted session sends, but a server that extracts facts with a model on write stores sentences the session never sent, and at least one widely used memory API does that by default unless the caller sets infer to false. On Tuesday the read returns an extracted fact, no whole text, paragraph or line of it matches a recorded hash, and the label falls back to the tool's own rule, the same way notes.md came back trusted before v0.4. Consolidation has the same shape from the other side: a server that merges a tainted note with clean ones into one record produces text that matches nothing, while the strictest label in the merge is the one that should survive.
For that sink the label has to travel with the record rather than with the bytes. When the server takes per-item metadata, as that same API does, the gateway can write the session label into it at store time and read it back from the result, and keep the hash ledger for files and shell output, where the bytes do survive. A server that drops the field or rewrites it during a merge then counts as a tool whose results need the strict default, which the policy file can state once per server instead of discovering it per read.
A cheap test for the demo: run Tuesday against a memory server with extraction on, and check whether the read still comes back untrusted, written by session mon.
you're right that the hosted docs contradict it, I'll run the probe and report back, and here's the fail-closed plan meanwhile" is enough. Hold off on claiming it's fixed until you've run the test.
@izgorodin Thanks, this is a real gap. I'd been treating memory servers as covered by the ledger, and they're only covered when they store what was sent.
I ran your Tuesday test against a fake memory server with extraction on, and it failed the way you predicted: the extracted facts matched no recorded hash, and the read came back trusted. Merging records failed the same way.
So I went with your proposal: the label travels with the record.
On write, the gateway stamps the session label into the record's metadata (
labelInto: metadatain the config). Any stamp the agent supplied is replaced.On read, stamps found in the result are joined into its label (
readLabels: true). Anyone with access to the store can write metadata, so a stamp can only make a label stricter, never looser.The hash ledger stays for files and shell output, where the bytes survive.
A server that drops metadata, for example when it merges records, is declared strict once per server in the config. That covers merges by being strict, not by keeping the strictest label through the merge, since the stamp doesn't survive.
Your test is in the repo now, and it passes: Tuesday's read comes back untrusted, written by session mon.
It's an experimental hobby project, so comments on the PR are very welcome, especially if you know memory servers that keep metadata through merges.
On metadata through merges, the open-source Mem0 code on main does not merge records when it adds with inference on. Each extracted fact becomes a new record with a copy of the call's metadata, an exact duplicate of a retrieved memory is skipped, and update() keeps the stored payload and lays the caller's metadata over it. A stamp in metadata survives that path, so it needs no strict declaration.
The label gets lost one step earlier, in a buffer the stamp never touches. Each add saves the raw messages in a table keyed only by the user, agent and run ids, with no metadata column, keeps the last ten per scope, and hands them to the extractor as Last k Messages with the instruction to resolve references and pronouns from them. If Monday's tainted session and Tuesday's clean one write under the same ids, a Tuesday message like "post the link in the same place as before" can be extracted into a self-contained fact that carries Monday's target and Tuesday's label. The stamp is right about which call wrote the record and wrong about whose text is in it.
The scope key is an exact match on the ids the call sets, so a separate run id per session, or at least per label, keeps tainted messages out of a clean session's buffer. Existing memories are searched more widely, by whichever ids the call sets, but the prompt limits those to deduplication and linking. The Tuesday test has a sharper variant for this server: Monday writes the injected target, Tuesday writes only the reference under the same ids, and the read should still come back untrusted.
You're right, and thanks for reading Mem0's code that closely. I checked it against 2.2.1 and every point holds: with inference on, each extracted fact is a new record with a copy of the call's metadata, exact duplicates are skipped, and nothing is merged. So the stamp survives the add path, and my "declare it strict" advice doesn't apply to Mem0. I had the wrong step.
The buffer is the real gap, and it showed up exactly as you described. Your sharper test is in the suite now: Monday writes the injected target, Tuesday writes only "post the announcement in the same place as before" under the same user_id, and without a fix the fact names Monday's target with Tuesday's clean stamp.
I went with your per-label idea. A new
scopeInto: run_idoption gives a tainted session's writes a run id named after its label (for exampleadtl-untrusted-public), so its messages stay out of clean sessions' buffers, while clean sessions keep sharing theirs. A clean session can't name a tainted scope itself.While checking this, I found a second gap:
update()lays the caller's metadata over the stored metadata, so a clean update replaced a tainted stamp. Each session now stamps under its own key, so an update adds a stamp instead of replacing one, and the read takes the stricter label.history()returns text without metadata, so the docs now say to give it a strict rule. The same goes forlist_eventsandget_event_statuson the hosted MCP server.One thing I couldn't check: Mem0's docs say the hosted
update_memory"overwrites" metadata. Do you know if the platform merges it the way the open-source code does, or replaces it?The hosted docs point to replace, in two places. The hosted MCP server page describes update_memory as "Overwrite a memory's text and/or metadata after confirming the ID", and the platform CLI reference describes mem0 update --metadata as "Replace the memory's metadata with this JSON". The open-source changelog records the opposite fix for update(), which is what you saw in 2.2.1. Docs are not behavior, so a probe on a real key settles it: add with {"a": 1}, update with {"b": 2}, read it back.
If it replaces, a per-session key does not survive a clean update, since the call carries only its own key, and the hosted server lands in your README's replace case. The gateway could read the stored metadata and send the union, but that is two calls, and two sessions updating one record in between can still drop a stamp.
The finding that nothing is merged may not carry over either. The Dream page lists Merge as always on, on every plan: a fuller version of a fact folds the barer one in, and the merged record is hidden from default reads and returned with include_merged=true. The pricing page now lists Dream (memory consolidation) under the custom plan, with a dash in the free column. So whether merge runs on your key is part of what the test settles. Where it runs, the Dream page does not say whose metadata the canonical record keeps, so the case to add is a merge where the barer record is the tainted one, read by default and with include_merged.
Agreed, and that answers the question I left open. In v0.2, a plan with a fixed-window hold will carry a signed recovery clause. The clause says whether off-session re-authorisation is consented, up to what amount, and which saved mandate it refers to. If there's no consent, the coordinator knows when the plan is signed that recovery needs the payer on session, so it escalates to the payer early. If there is consent, it can re-authorise up to the cap. An authentication_required decline is handled like no consent. Thanks, this thread has become most of the v0.2 changelog.
A plan can set escalation.leadSeconds. An in-doubt final step escalates that far before the first hold ends, so a card window like capture_before leaves a human time to act.
After escalating, the coordinator keeps asking. A late answer is recorded, with whether each hold is still live or has lapsed. Recovery is offered, never performed. A linked transaction says whether the payer must be present, based on recovery.offSessionReauth (consented, up to what amount).
holds-first: the holds are placed before anyone is asked, so the plan the approver signs includes each hold's end and an approval deadline that fits inside it.
Thanks, both of you. This thread shaped most of the release. npmjs.com/package/hatp-protocol
Follow-up on hosted Mem0: v0.8.0 handles the "update replaces metadata" case without relying on the stamps. With
recordIds: idon the memory tools, the ledger also remembers a tainted session's writes by record id (the idsadd_memoryreturns and theidthatupdate_memoryis given). A read that returns that id gets the label back, even after a clean session's update has replaced every stamp.For Merge, I added a merge mode to the fake memory server and tested it:
include_merged, keeps its label by id.What I still haven't done is run your three checks on a hosted key, so #48 stays open until I have real answers rather than what the docs say: github.com/probita-ai/adtl/issues/48
this is how it will work.
The "labels should follow the text, not the process" framing is exactly right — this is classic information-flow control, and the honest limitations section is what makes me trust the design. One caveat from running taint-based systems: declassification is where these things rot in practice. Manual
declassifystarts principled and ends as reflex, because the 'ask' friction arrives exactly when someone is mid-flow. If you're planning signed receipts, consider signing declassifications too — who cleared the label, when, and why — since that's where the forensic questions actually land.Thanks, this is really useful. And yes, it's IFC at heart. I tried to build on that line of work (same lowest-integrity / highest-confidentiality labels as FIDES) rather than invent something new.
One thing that might ease the reflex problem: in ADTL, approving an "ask" and declassifying are separate actions. An approval lets one exact call through (bound to that call's hash, single use, with an expiry), but it doesn't clear the session's label or the ledger. So the mid-flow friction ends in "allow this one call", not "trust this content from now on". Declassify is its own command you run on purpose.
You're right that it's still where the forensic questions land, though. Today a declassify records who, when and an optional reason in the hash-chained ledger, but it isn't signed and the reason is optional. I've added signed declassifications, a required reason and a review list to the receipts issue:
github.com/probita-ai/adtl/issues/26
Curious what kept declassification honest in the systems you ran: required justification, expiry, two-person approval, something else?
dev.to/murthyg/my-spec-called-the-...
Follow-up on this: both are in now.
ledger declassifyrequires a--reason(since v0.5.0), and in v0.6.0 every declassification is signed with a per-machine key along with the rest of the ledger, recording who cleared it, when, which file and why.adtl-gateway ledger declassifiedlists recent ones for review, so a reflexive clear at least leaves a trail someone can look at.It doesn't stop the reflex itself, which was your real point. I'm still curious what worked for you there: expiry, two-person approval, something else?
Release notes: github.com/probita-ai/adtl/release...
try probita-ai.github.io/adtl/playground