What Is the TRAIL Protocol? The Beginner's Guide to Auditable, Revocable Agent Calls

CodexFuse Team · 2026-11-05T03:04:02.666Z · 10 min read min read

What is the TRAIL protocol?

Anyone asking what is the TRAIL protocol is really asking who gets to check an AI agent's work — and stop it mid-run if the answer is ugly. TRAIL is an Internet-Draft, a work-in-progress proposal rather than an adopted standard, published in November 2026 and discussed on the [email protected] mailing list. The draft's own pitch says it best: "TRAIL makes this communication auditable and revocable by parties other than the operator." The draft is registered as draft-nassar-agentproto-trail-00, and it names Kareem Nassar, Suhas Nandakumar, and Cullen Jennings of Cisco as authors.

Two confusions to clear up before we go further. TRAIL is not the similarly named Agent Audit Trail draft family — that is a different proposal, and it gets its own section below. It also has nothing to do with hiking trails, or with our Entire Git Forge guide's "Trail Lesson" chapter, which is about version control, not AI agents. The examples in this guide assume the agents live on an ordinary VPS hosting server, the same kind of box most teams rent for always-on workloads. And the trail's tamper-evidence is built from hash-linked structures, whose basic building block you can try yourself with a SHA-256 hash generator.

Why do AI agents need the TRAIL protocol?

Because an agent's records are written by the same operator whose conduct they describe — and the draft argues those records can be dropped, reordered, or rewritten without detection. The draft opens with a stark definition: "An agent is a model running in a loop with tools, credentials, and a goal. It reads untrusted input, acts with real authority, and works faster than people can watch."

That speed and authority is the whole problem. The draft says two things are needed outside the agent: "An enforcement point that the agent cannot see, reach, or turn off," and "A record of what the agent did that the operator cannot quietly rewrite, that parties outside the operator can check, and that those parties can act on while the agent is still running." Today's reality, per the draft, is that "the records of what they did are kept by the operators whose conduct the records describe, and the parties overseeing them learn of problems only afterwards."

What is the TRAIL protocol COSE Action Record?

Every call that crosses a cell boundary is signed by the edge as a COSE Action Record and appended to the edge's tamper-evident trail before the call is allowed to leave. A cell, in the draft's vocabulary, is "Everything behind one edge... one sandbox, a confidential VM, or a whole machine. The cell is the unit at which TRAIL enforces." The edge is "Where traffic leaves a cell. Every call into or out of the cell passes through it. It holds the keys, evaluates policy, signs Action Records, appends them to its trail, and applies holds. The agent cannot reach it."

The Action Record itself is compact by design: "An Action Record is a COSE_Sign1 [RFC9052] structure. It is a SCITT Signed Statement [RFC9943], so it can also be registered with a Transparency Service without conversion." The receiver keeps its copy of the record. And the hard rule is absolute: "Agent-to-agent and agent-to-tool traffic MUST NOT leave a cell unless an Action Record for it has been appended to the edge's trail."

Put together, one call's journey looks like this:

1. An agent issues a call to another agent or a tool.
2. The call reaches the edge at the cell boundary. It cannot bypass it.
3. The edge evaluates policy against the current authority directives.
4. The edge signs a COSE Action Record for the call.
5. The record is appended to the edge's Merkle-tree trail, and at each epoch end a witness countersigns the checkpoint.
6. Only then does the call leave the cell; the receiver keeps its copy of the record.

Who watches the trail: witnesses, authorities, and the liveness rule

Two independent parties keep the system honest: witnesses, who countersign trail checkpoints, and authorities, who publish live directives — backed by a liveness rule that freezes the agent's traffic if either goes stale. A witness, per the draft, is "A party that checks that it has received every record in a trail and countersigns the trail's checkpoints. It has no rights over actions." The trail itself is "The append-only sequence of Action Records of one party, organized as a Merkle tree."

At the end of each epoch, "the edge signs a checkpoint over its whole trail, and a witness that holds every record countersigns it." A cosignature, the draft explains, "states that the witness holds every record the checkpoint covers and that the trail extends the last checkpoint the witness cosigned." The teeth are in the next line: "an edge whose cosignatures grow stale pauses, so stopping the witness stops the agent."

An authority is "A party with rights over some scope that an operator has granted, such as a regulator, a counterparty's inspector, or the operator's own safety team." Crucially, "Authorities, including ones the operator did not list in advance, can watch activity while it runs, require approval before an action, refuse actions, and stop agents." The draft names four directive types an authority can publish:

The liveness rule ties the whole design together, verbatim: "An edge stops an agent's traffic when it loses contact with the authorities it answers to, or when its trail is no longer being witnessed." The draft's summary line is worth memorizing: "Fresh authority state and fresh witness cosignatures keep an edge running."

TRAIL vs Agent Audit Trail: what is the difference?

They attack the same problem from opposite ends: the Agent Audit Trail draft standardizes the log format, while TRAIL builds the enforcement architecture that makes the log checkable and actionable while the agent is still running. Do not treat the two drafts as versions of each other — they are separate proposals by different authors.

TRAIL protocol: MOQT or HTTP — which binding should you use?

Both: TRAIL defines bindings to HTTP and to Media over QUIC Transport (MOQT) that produce the same evidence, with MOQT preferred for the evidence plane. Over MOQT, the draft notes, "holds reach edges as soon as they are published" — a live revocation can propagate near-instantly instead of waiting on the next poll.

Nothing is lost by staying on plain HTTP: "Every TRAIL property is available over HTTP." The two bindings are evidence-equivalent by design; MOQT is the recommended fast lane for the evidence plane and for calls where both sides support it, while HTTP keeps the protocol deployable anywhere.

Where does agentproto TRAIL fit in the protocol landscape?

TRAIL is one of several late-2026 drafts discussed on the agentproto list, and it owns the auditability-and-revocability lane: it sits underneath agent communication as the layer that records calls and enforces outside control. In short, the TRAIL protocol gives AI agents something they have never had: an outside party that can both see their calls and stop them. Related drafts on the same list cover different lanes — rule provenance profiles the Agent Audit Trail format, identifier drafts handle agent naming, and architecture drafts sketch the overall stack — and none of them implements TRAIL's edge-and-authority mechanism.

Two sibling explainers on this site cover adjacent lanes: AER-1 for post-hoc execution receipts, and the Mitra protocol for signed envelopes with token budgets. TRAIL's lane is different from both: cross-organization audit plus live revocability. And a final status note, said once and plainly: TRAIL is an individual draft, not a working-group draft and not a standard — everything in this guide describes a proposal that may change or expire on 6 May 2027.

What are TRAIL's limits right now?

It is a -00 draft with no documented independent implementations yet, and it asks operators to deploy edges, witnesses, and authority integrations — real operational cost for a proposal that could still change. As of this writing, the only public writing about TRAIL beyond the draft itself is a November 4, 2026 overview that calls it "an early individual draft, not a standard." There are no dedicated explainers, no implementation reports, and no mailing-list threads devoted to it.

That thin field is normal for a days-old draft, but it means every mechanism claim in this guide traces to the draft text itself, not to field experience. The draft expires 6 May 2027; like all Internet-Drafts, it may be revised, replaced, or simply lapse. Evaluate it as a direction the industry is exploring, not as infrastructure you should build on today.

Sources

• draft-nassar-agentproto-trail-00 (Internet-Draft, November 2026, expires 6 May 2027) — https://datatracker.ietf.org/doc/html/draft-nassar-agentproto-trail-00 — the draft text; every verbatim mechanism quote in this article; fetched 2026-11-05.
• Carla, "When Agents Talk to Agents, Who Keeps the Record?" (Medium, 2026-11-04) — https://medium.com/@carla_1448/when-agents-talk-to-agents-who-keeps-the-record-0196741b9b75 — the "early individual draft, not a standard" characterization.
• draft-sharif-agent-audit-trail-09 idnits record (author-tools.ietf.org, via web search 2026-11-05) — the Agent Audit Trail draft's abstract (JSON record structure, SHA-256 chaining per RFC 8785, EU AI Act motivation), used for the comparison table.

Frequently Asked Questions

Is the TRAIL protocol an official IETF standard?

No. It is an individual Internet-Draft (draft-nassar-agentproto-trail-00), published in November 2026 and expiring 6 May 2027. It has not been adopted by any working group, and a November 2026 overview describes it as "an early individual draft, not a standard."

What is a COSE Action Record in the TRAIL protocol?

A COSE_Sign1 structure (RFC 9052) that is also a SCITT Signed Statement (RFC 9943). The edge signs one for every call that crosses a cell boundary, appends it to its Merkle-tree trail, and the receiver keeps a copy. Because it is a SCITT Signed Statement, it can be registered with a Transparency Service without conversion.

How is TRAIL different from the Agent Audit Trail draft?

The Agent Audit Trail draft (draft-sharif-agent-audit-trail-09, CyberSecAI, Standards Track) defines a JSON logging format with SHA-256 hash chaining, motivated by EU AI Act record-keeping. TRAIL defines an enforcement architecture — edge, witnesses, authorities, live directives, and a liveness rule. One standardizes the log; the other makes the log checkable and actionable while the agent runs.

What happens if a witness stops countersigning the trail?

The edge's cosignatures grow stale, and a stale edge pauses: per the draft, "an edge whose cosignatures grow stale pauses, so stopping the witness stops the agent." The liveness rule is explicit: "An edge stops an agent's traffic when it loses contact with the authorities it answers to, or when its trail is no longer being witnessed."

Does TRAIL work over HTTP, or does it need MOQT?

Both. TRAIL defines HTTP and MOQT bindings that produce the same evidence, and every TRAIL property is available over HTTP. MOQT (Media over QUIC Transport) is preferred for the evidence plane because holds reach edges as soon as they are published.