| Internet-Draft | Tap-to-Record Agent Evidence | November 2026 |
| Gupta & Mih | Expires 6 May 2027 | [Page] |
When an AI agent finds a counterparty, interacts with it, and pays it, the interaction crosses every layer of the stack: a physical tap between two devices, the hardware that holds their keys, a transport session, peer discovery and gossip, and finally an application record of what was agreed, paid, and delivered. Each layer produces its own evidence, and today nothing joins them. This document puts the near-field tap at the center and follows one progression, from tap to rendezvous, authenticated session, interaction, payment, and evidence record. For each layer it states what evidence the layer can contribute, what a verifier has to trust, and how a single verifiable record can cite all of it by digest. It treats hardware attestation and a transparency log checked by independent witnesses as complementary roots of evidence that answer different questions, describes how light nodes can check one interaction through evidence requests instead of replicating a swarm, and asks which measurable observations can independently corroborate such a record. It is a problem statement and research agenda for discussion in MAPRG, not a protocol specification.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Agents are starting to meet and transact in person as well as online. Two people's agents find each other across a table and exchange a credential; a delivery robot hands a parcel to a building's concierge agent; a phone agent pays a vending agent. The natural first step in each case is a near-field tap. The tap is short-range, needs physical presence, and can carry a key.¶
The first thing a tap does is let two agents find each other. After the tap the interaction moves up the stack along one progression:¶
tap -> rendezvous -> authenticated session -> interaction
-> payment -> evidence record
The two devices use what the tap carried to open an encrypted transport session to each other, possibly find other peers through a distributed hash table, share state over gossip, interact, and, in some cases, pay and deliver. Afterwards someone who was not present, such as an auditor, a dispute handler, or the payer's own employer, may need to check what happened.¶
Evidence exists at every one of those layers. A secure element can sign what it read. A processor can trace what it executed. A transport handshake binds a session to a key. A DHT record and a gossip message can be signed. An application can seal a record of the agreement. What is missing is the connection: a checker today gets either every layer's raw logs or nothing, and has no way to know that the key in the tap is the key in the session is the key that signed the payment record.¶
This document argues that the tap is the right anchor to build that connection from, because it is the one moment where both parties are physically present. Discovery is the general case and the one this document leads with; payment is the second scenario, and the one that shows most clearly why knowing that a tap occurred is not enough. The contribution is the layered evidence model, not an NFC payment protocol.¶
Section 3 through Section 6 walk the stack. Section 7 covers checkers who cannot hold everything. Section 8 gives two end-to-end cases. Section 9 asks what can be measured, which is the reason this belongs in MAPRG.¶
This document marks each component as implemented, prototype, or future work. The core of this revision is the tap, the tap record, secure-element evidence, the move from the tap to an authenticated transport session, the record and bundle that cite them, and how these layers relate. Processor tracing, richer attestation, witnessed logs beyond the basics, gossip, and most of the light-node work are future work and are described only so the model shows where they fit.¶
A tap is small, so what it carries has to be chosen. The useful minimum:¶
For payments, the tap may additionally carry the payment terms, or start a contactless payment whose cryptogram is itself evidence produced by hardware.¶
A recorded tap establishes that a device holding a given key took part in a near-field exchange that included a given nonce. With a secure-element signature, it also establishes which hardware produced that statement, to the extent the signing key's provenance is known.¶
It does not establish distance. A relay attack can stretch a near-field exchange across any distance unless the protocol bounds round-trip time. It does not establish who the person is, or that the key holder was authorized to act for anyone. It does not by itself establish trust in the peer. Each record that cites a tap has to say which of these it relies on.¶
For two agents in the same place, a tap replaces a lookup. Instead of asking a DHT for a peer, the device already has the peer's key and can dial it directly. This removes one source of manipulation (a poisoned lookup) and one privacy leak (announcing interest in a peer to the swarm), at the cost of requiring presence. The tap exchanges the minimum needed to set up a rendezvous; everything stronger happens in the authenticated session that follows.¶
A tap record is an ordinary record with a tap-specific field. No new record type is needed. Each side seals its own tap record: its own key, the peer's key, both nonces, and the time by its own clock. Neither signs the other's record. A checker that holds both records can confirm they name the same keys and nonces; a checker that holds one has one party's account. This is the same two-sided pattern used for settlement in [I-D.mih-agent-settlement-records].¶
The tap-specific field separates two kinds of content:¶
Keeping these apart is what makes the security analysis in Section 10 tractable. Replay, relay, and substitution attacks act on different parts: a replay reuses intrinsic content in a new interaction, a relay stretches the intrinsic exchange across distance, and a substitution swaps the corroborating artifact. A checker can see which part a given claim rests on.¶
A trusted execution environment, a TPM, or a secure element can sign a statement about its own state, in the RATS sense [RFC9334], for example as an Entity Attestation Token [RFC9711]. A record cites such a statement by digest, and a checker verifies it with the issuer's own verifier. The runtime extension for Agent Action Capsules [I-D.palanisamy-scitt-aac-runtime] already defines this citation (attestation_refs), and a verifier there never reports a grade higher than the foreign verifier's result. Secure-element evidence for the tap is in scope for this revision; richer platform attestation is future work.¶
Processor trace facilities can record the control flow a core actually executed. As evidence, a trace answers "what code ran" more directly than any software log, but traces are large, and tying a trace to one interaction needs the same nonce discipline as the tap. A record can cite a trace, or a digest of a trace summary, without carrying it.¶
Hardware attestation and a witnessed transparency log are complementary roots of evidence that answer different questions. They are not interchangeable roots of trust.¶
Hardware attestation answers what ran, under keys whose provenance runs back to a manufacturer. Not every device has such hardware, and not every checker trusts the manufacturer.¶
A witnessed log answers a different question. Each record is appended to a log whose checkpoints are cosigned by independent witnesses, or registered with more than one transparency service [RFC9943]. That does not say what ran. It says that a record existed by a certain time and has not changed since, and it depends on no single operator.¶
The two compose. A record can cite a hardware statement and also be covered by a witnessed log; the first speaks to the device, the second to the record's history. A checker should report each claim against the root that supports it and should not present one as a substitute for the other.¶
With a transport that dials peers by public key, such as libp2p or Iroh [IROH] over QUIC [RFC9000], the key exchanged in the tap is the address and the session's authenticated identity. The handshake then binds the session to the same key the tap carried. A record that names its counterparty by that key is naming the peer it physically tapped, if the tap record is available. This step is in scope for this revision.¶
Beyond the tapped peer, agents find others through a Kademlia-style DHT [KADEMLIA], often within a private swarm. A signed provider record says what a peer advertised, not what it later did. Lookups are a privacy cost (they reveal interest) and an integrity risk (a poisoned routing table returns attacker-chosen peers). The tap avoids both for local peers; the DHT remains for everyone else.¶
Gossip protocols such as gossipsub [GOSSIPSUB] spread state through a swarm. Signed messages give per-message authenticity, but full gossip means every node receives every message, which is the resource cost light nodes (Section 7) are meant to avoid. Gossip is also where operational telemetry about the network itself can be published in a verifiable form, the subject of [MAPRG-126].¶
At the top, each party seals a record of the action itself: what was agreed, paid, or delivered [I-D.mih-scitt-agent-action-capsule] [I-D.mih-agent-settlement-records]. Each party appends its records to its own checkpointed log [I-D.mih-scitt-checkpointed-local-log], so that removing or rewriting one later is detectable. The record cites the lower layers by digest. The last column marks what is in scope for this revision.¶
| Layer | Artifact | Cited as | Scope |
|---|---|---|---|
| Tap | each side's tap record | typed digest reference to the record | core |
| Secure element | signed NFC record or attestation token | attestation_refs entry | core |
| Transport | peer's public key | counterparty key in the record | core |
| Log | checkpoint and inclusion proof | carried in an evidence bundle | core |
| Discovery | provider record, when the peer was not tapped | typed digest reference | future |
| Gossip | message identifier | typed digest reference | future |
| Processor | trace or trace summary | typed digest reference | future |
An evidence bundle [I-D.mih-zhang-agent-disclosure-bundle] packages a record with the artifacts it cites that the holder chooses to disclose, plus the proofs a checker needs, so the whole chain can be checked offline.¶
A checker rarely needs the whole swarm. It needs one interaction. Rather than downloading every message, a light node asks for evidence about the specific records it cares about, using the request model of [I-D.mih-agent-evidence-request]: a request names the records, the holder answers with a bundle, refuses, or reports that the records do not exist, and each of those outcomes is itself recorded.¶
The minimum a light node needs to check one record is the record, its inclusion proof, the checkpoint that covers it, and either a witness cosignature on that checkpoint or a transparency service receipt [RFC9942]. That is small and fixed in size, whatever the size of the swarm. Partial messages in the gossip layer and evidence requests at the record layer are two forms of the same idea.¶
A partial verifier establishes a bounded claim about one interaction. It never establishes the global state of the swarm, and its result must not be presented as if it had.¶
Two people's agents tap phones. The tap carries each device's transport key and a nonce from each side. Each phone dials the other by key over an authenticated QUIC session, and the session handshake binds the session to the tapped key. The agents exchange a credential over that session. Each side seals its own tap record and a record of the exchange that cites the tap record by digest, and appends both to its own log. A checker who later holds both sides' records can confirm that the key in the tap is the key in the session is the key that signed the exchange record. It cannot confirm, from these records alone, that the two devices were near each other unless the tap bounded round-trip time.¶
A phone agent taps a vending agent. The tap carries the vending agent's key, both nonces, and the price terms. The phone dials the vending agent over a key-addressed QUIC session; the phone pays (for example x402 on a testnet, as in [I-D.mih-agent-settlement-records]); the vending agent delivers. Each side seals its own records of the tap, the terms, the payment it observed, and the delivery, and appends them to its log. A light node later requests the payee's records and checks them offline.¶
Payment shows why knowing that a tap occurred is not enough: a checker has to connect the payment to the identities, the transport session, and the record of what was delivered, and the citations in Table 1 are what make that connection checkable.¶
The payment rail has run end to end in a reference implementation (implemented). The tap record, the secure-element signature, and the binding of the session to the tapped key have not yet run together (prototype at best). The processor trace has not been built (future). Both devices in any run the authors show will be operated by the authors, so the examples demonstrate separate devices, not separate parties.¶
The central question for MAPRG is which measurable observations can independently corroborate a record made at the tap or the application layer, and what limits those observations have. A record is one party's statement. A network observation made by someone else can support it, contradict it, or say nothing about it. The questions below are organized around that.¶
Which of these existing libp2p telemetry can already collect, using the framework in [MAPRG-126], and with what limitations, is an open item for the next revision. None of the questions above is answered by this document.¶
The main threats follow the layers. Near-field relay attacks defeat proximity unless round-trip time is bounded. A replayed tap reuses intrinsic tap content in a new interaction; fresh nonces from both sides and, where available, a counter limit this. A substitution swaps a corroborating artifact; citing it by digest makes the swap detectable but does not make the artifact true. A compromised secure element signs whatever it is told. A poisoned DHT returns the wrong peer. A party can withhold records; the evidence-request model makes a refusal visible but cannot force disclosure.¶
Throughout, a citation only says that a record named an artifact. A checker has to verify the artifact itself, with that layer's own verifier, before relying on it, and must not report a stronger result than that verifier gave.¶
A tap can expose a stable hardware identifier; devices should use per-interaction keys and randomized identifiers. DHT lookups reveal interest. Gossip metadata reveals who talks to whom. Processor traces can contain secrets. Records should carry digests of these artifacts, never the artifacts, and bundles should disclose only what a given checker needs.¶
This section records the status of known implementations at the time of posting, per [RFC7942], and is to be removed before publication.¶
The evidence layer has reference implementations, and the settlement records have run end to end on two payment rails. No implementation of the tap record, the secure-element citation, or the processor-trace citation described here is known to the authors.¶
This document has no IANA actions.¶
The authors thank Johanna Moran (libp2p) for her contributions to the ideas in this document, in particular the work on verifiable telemetry and measurement for libp2p deployments on which Section 9 builds.¶