What Is Tap-to-Record Agent Evidence? The Beginner's Guide to NFC Taps, Layered Evidence, and Agent Payments
CodexFuse Team · 2026-11-05T20:48:30.102Z · 23 min read min read
What Is Tap-to-Record Agent Evidence? The Beginner's Guide to NFC Taps, Layered Evidence, and Agent Payments
What Is Tap-to-Record Agent Evidence?
What is tap-to-record agent evidence? It is a model from a November 2026 IETF Internet-Draft for joining the evidence produced at every layer of an in-person agent interaction into one verifiable record, anchored on a near-field communication (NFC) tap. The draft is called From Tap to Record: Layered Evidence for Agent Discovery and Payment over Near-Field Communication, and it was posted as draft-gupta-mih-maprg-nfc-agent-evidence-00 on November 2, 2026.
The idea is simple to state and hard to build. When two AI agents meet in person, each layer of their interaction already produces some evidence, but nothing joins those pieces together. Tap-to-record agent evidence is the proposal for how the tap becomes the anchor that ties them all into a single checkable record.
It is a problem statement and research agenda for discussion in MAPRG, not a protocol specification. That distinction matters for everything that follows: the draft defines no protocol, sets no standard, and answers none of its own open questions. It maps the problem and marks each piece as implemented, prototype, or future work.
Each layer is cited by a digest, which is a short fixed-length fingerprint of a longer artifact. A SHA-256 hash generator produces exactly that kind of fingerprint, and it is the simplest way to see what a digest is. The agents in the draft's examples run on ordinary servers, and VPS hosting is the usual home for a small agent that needs a public address and a persistent process.
At a glance, the draft looks like this:
| Fact | Detail |
|---|---|
| Document | draft-gupta-mih-maprg-nfc-agent-evidence-00 |
| Authors | Manu Sheel Gupta (libp2p) and Steven Mih (Action State Group, Inc.) |
| Posted | November 2, 2026 |
| Current revision | -00 only; no -01 exists as of November 6, 2026 |
| Intended status | Informational |
| Expires | May 6, 2027 |
| Length | 14 pages, 14 sections |
| References | 17 references, all informative; no normative references |
The draft, written by two authors, is 4 days old at the time of writing, and it expires 185 days after it was posted, on May 6, 2027. That short lifetime is normal for an Internet-Draft: the document is work in progress, and it lapses unless a newer revision replaces it. From November 6, 2026, there are 181 days left before that expiry.
The six steps of the progression, in order, are:
- Tap: two devices exchange a public key and fresh nonces at close range.
- Rendezvous: the tap hands each side the key it needs to dial the other directly.
- Authenticated session: the handshake binds the session to the tapped key.
- Interaction: the agents exchange data over that session.
- Payment: one agent pays the other for what was delivered.
- Evidence record: each party seals one record that cites every layer below it by digest.
Why One Tap Needs Six Layers of Evidence
Every layer of an agent interaction already produces evidence, and today nothing joins it. A checker that wants to verify what happened gets either every layer's raw logs or nothing at all. Worse, it 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.
The draft 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. Presence is the one fact no log can fake cheaply, and the tap turns it into a starting point for everything that follows.
Three everyday scenarios open the draft. In the first, two people's agents exchange a credential across a table. In the second, a delivery robot hands a parcel to a building's concierge agent.
In the third, a phone agent pays a vending agent. Each scenario is small, and each one needs the same thing: a record a later checker can verify without trusting either party's word.
The six-step progression is the draft's answer to that need:
| Step | What happens | What it contributes as evidence |
|---|---|---|
| 1. Tap | Near-field exchange of a public key and fresh nonces | Proof that a device holding a given key took part in an exchange that included a given nonce |
| 2. Rendezvous | Each side dials the other directly by the tapped key | Removes a poisoned lookup and a privacy leak from discovery |
| 3. Authenticated session | Handshake binds the session to the tapped key | The session's counterparty is the peer that was physically tapped |
| 4. Interaction | Agents exchange data over the session | Signed records of what was advertised and what was said |
| 5. Payment | One agent pays for what was delivered | A signed payment tied to the same keys and session |
| 6. Evidence record | Each party seals one record citing every layer by digest | One verifiable record a later checker can verify |
That table is the whole model in miniature. The rest of this guide walks each row in turn, then explains the two roots of evidence that back the record up, and finally what a light node needs to check a single interaction without downloading a swarm.
What Does a Tap Actually Carry?
A tap is a near-field exchange between two devices in physical proximity, carrying at least one public key and one nonce. The minimum it carries is the initiating device's transport public key, plus a fresh nonce from each side. That is the whole payload at its smallest: a key, and two numbers that have never been used before.
Optionally, the tap can carry more. An endpoint hint tells the other side where to reach it. A monotonic counter orders taps over time.
A secure-element signature, for example as an NFC Forum Signature record, adds a hardware-produced statement about the tap. For payments, the tap may also carry payment terms, or start a contactless payment whose cryptogram is itself hardware-produced evidence.
| Carried in the tap | Required or optional | Why it matters |
|---|---|---|
| Initiating device's transport public key | Required | The key becomes the peer's address and identity in the session that follows |
| Fresh nonce from each side | Required | Ties this tap to this interaction and stops old taps being replayed |
| Endpoint hint | Optional | Tells the peer where to dial for the rendezvous |
| Monotonic counter | Optional | Orders taps over time so a replayed tap stands out |
| Secure-element signature | Optional | Says which hardware produced the statement, to the extent the signing key's provenance is known |
| Payment terms or a contactless payment start | Optional, for payments | Carries the price into the tap, or produces a hardware cryptogram as evidence |
Short range is the point. A tap needs physical presence, and that presence is what makes it a useful anchor. But the range is also the limit: the draft is careful that a tap on its own establishes far less than it sounds like, which is the subject of the next section.
What a Tap Does Not Prove
A tap proves neither proximity, identity, authorization, nor trust. Each of those sounds like something a physical tap should guarantee, and the draft is explicit that none of them follows from the tap alone. A record that cites a tap has to say which of these it relies on, because the tap itself guarantees none of them.
| What a tap does not establish | Why not |
|---|---|
| Distance | A relay attack can stretch a near-field exchange across any distance unless the protocol bounds round-trip time |
| Who the person is | The tap names a key, not a person; nothing in the tap says who holds the device |
| Authorization | Holding a key does not show that its holder was authorized to act for anyone |
| Trust in the peer | Presence is not reputation; a tap with a stranger proves only that the stranger was there |
With a secure-element signature, a recorded tap also establishes which hardware produced the statement, to the extent the signing key's provenance is known. That is a narrower claim than it sounds like: it speaks to the device, not to the person holding it, and not to whether the device's owner approved the action.
This discipline is what makes the rest of the model work. The tap record keeps two kinds of content apart: what is intrinsic to the tap, such as keys, both nonces, the counter, and the secure-element signature, and what is corroborated later, such as the session bound to the tapped key, the hardware attestation, and the execution trace. Keeping these apart is what makes the security analysis tractable, because each claim is checked against the root that supports it.
From Tap to Rendezvous: Skipping the Lookup
Normally, finding a peer means asking a distributed hash table for it. The tap replaces that lookup: instead of asking a DHT for a peer, the device already has the peer's key and can dial it directly. The tap exchanges the minimum needed to set up a rendezvous, and everything stronger happens in the authenticated session that follows.
Skipping the lookup removes one manipulation source and one privacy leak. A poisoned DHT lookup cannot send the device to the wrong peer, because there is no lookup to poison.
And the device never announces its interest in a peer to the swarm, because it never asks the swarm anything. The cost is that discovery now requires presence: you can only find peers you have physically tapped.
The phrase tap to record NFC agents describes exactly this pattern: the tap is the discovery step, and the record is what the discovery leaves behind. It is a small idea with a large consequence, because every later layer inherits its anchor from a moment when both parties were in the same place.
Discovery does not end at the tap. Beyond the tapped peer, agents still find others through a Kademlia-style DHT, often within a private swarm, and share state over gossip such as gossipsub. Those wider mechanisms are where the later evidence layers come from, and they are also where the draft's future work begins.
How the Tap Binds the Authenticated Session
With a transport that dials peers by public key, such as libp2p or Iroh over QUIC, 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. That binding is what agent evidence NFC is really about: the key you tapped is the key you are talking to.
A record naming its counterparty by that key is naming the peer it physically tapped, if the tap record is available. That conditional matters. The binding holds only when the tap record exists and can be checked; without it, the session is authenticated to a key, but nothing connects that key to a physical meeting.
The first worked example in the draft runs on this binding. Two people's agents exchange a credential across a table: the tap carries the keys and nonces, the session binds to the tapped key, and the credential moves over that session. The tap record, the session, and the credential exchange are three layers of one interaction, and the evidence record at the top cites all three by digest.
This step is in scope for this revision of the draft. The move from the tap to an authenticated transport session is one of the four core pieces the draft covers, along with the tap itself, the tap record, and the secure-element evidence. Everything above the session is built on this binding holding.
How Payment Fits the Evidence Chain
The second worked example is a payment. A phone agent pays a vending agent: the tap carries the vending agent's key, both nonces, and the price terms.
The phone pays, for example with x402 on a testnet as in the settlement-records draft, and the vending agent delivers. Each step leaves its own evidence, and the evidence record joins them.
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 the draft's Table 1 are what make that connection checkable. A payment receipt alone says money moved; it says nothing about who was paid, over which session, or for what delivery.
This is the heart of NFC agent discovery payment evidence: discovery, payment, and delivery joined into one checkable story. The tap discovers the vending agent, the session carries the order, the payment settles it, and the record cites all three. Remove any one citation and the story has a gap a checker cannot close.
The payment rail is the one part of the model that has actually run end to end. The settlement records behind it have run on two payment rails in a reference implementation, which makes payment the most mature layer in the draft and the benchmark the other layers are measured against. The rest of the chain is prototype or future work, as the maturity section below shows.
What Is an Evidence Record?
At the top of the progression, each party seals a record of the action itself: what was agreed, paid, or delivered. A record is a signed, digest-committed statement by one party about an action it took or observed, such as an Agent Action Capsule.
The record does not carry the lower-layer artifacts themselves. It carries typed digest references to them, and a typed digest reference is the artifact's type, a digest algorithm, and the digest.
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. That rule is the draft's guard against overclaiming: the record is a chain of pointers, and each pointer has to be followed and checked on its own terms.
The tap record is an ordinary record with a tap-specific field, and 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 side signs the other's record.
A checker that holds both records can confirm they name the same keys and nonces, while a checker that holds one has one party's account. This is the same two-sided pattern used for settlement in the settlement-records draft.
An evidence 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. Bundles are what make the model practical: a checker receives one package and verifies the chain without going back to the swarm. The agent evidence record draft treats the record as the top of the stack: everything below is cited, and nothing below is carried.
The accounting siblings put this record in context. What Agent Run Metrics is, in one line, is a JSON format for counting what a single agent run costs, and it is the per-run accounting the cross-domain model builds on.
What IoA Usage Accounting is, in one line, is the cross-domain object model for the same problem at the scale of many domains. Tap-to-record evidence is the per-interaction counterpart: it records what happened between two agents that met in person, rather than what a run cost or what a domain billed.
The Seven Evidence Sources at a Glance
The draft's Table 1 lists seven evidence sources, and it is easy to confuse them with the six steps of the progression. They are not the same count.
The progression has six steps, while Table 1 has seven rows, because the table adds evidence sources that cut across the progression: the secure element, the log, and the processor. Four of the seven rows are core for this revision, and three are future work.
| 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 reference 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 |
Four of seven rows are core, which is 57.1 percent of the table, and three of seven are future, which is 42.9 percent. That split is a fair summary of the draft's maturity: the tap, the hardware signature, the transport key, and the log are in scope now, while discovery records, gossip messages, and processor traces are described only so the model shows where they fit.
Two rows deserve a closer look. A signed DHT provider record says what a peer advertised, not what it later did, so discovery evidence is weaker than it looks. And signed gossip messages give per-message authenticity, which is useful, but gossip is future work in this draft, so that evidence is not part of the core model yet.
Hardware Attestation vs the Witnessed Log: Two Different Roots
Hardware attestation and a witnessed transparency log are complementary roots of evidence that answer different questions. They are not interchangeable roots of trust. A record can cite both, but each claim must be reported against the root that supports it, and neither should be presented as a substitute for the other.
| Question | Hardware attestation | Witnessed transparency log |
|---|---|---|
| What it answers | What ran, under keys whose provenance runs back to a manufacturer | That a record existed by a certain time and has not changed since |
| How it works | A trusted execution environment, TPM, or secure element signs a statement about its own state, in the RATS sense | Each record is appended to a log whose checkpoints are cosigned by independent witnesses, or registered with more than one transparency service |
| What the checker uses | The issuer's own verifier, such as an Entity Attestation Token check | An inclusion proof and a checkpoint, plus a witness cosignature or a transparency service receipt |
| What it does not say | Nothing about the record's history or whether it was later changed | Nothing about what code ran on the device |
| Main limit | Not every device has such hardware, and not every checker trusts the manufacturer | Depends on witnesses and transparency services being available and honest |
| Scope in this draft | Secure-element evidence is core; richer platform attestation is future work | Basic witnessed logs are described; witnessed logs beyond the basics are future work |
The runtime extension for Agent Action Capsules already defines the attestation citation, and a verifier there never reports a grade higher than the foreign verifier's result. That rule mirrors the citation rule: a checker reports exactly what the supporting verifier established, and no more.
Processor tracing is the future-work cousin of attestation. A processor trace records the control flow a core actually executed, which 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.
The two roots compose. A record can cite a hardware statement and also be covered by a witnessed log: the first speaks to the device, and the second speaks 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.
How Light Nodes Check One Interaction Without the Swarm
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 the companion draft on evidence requests. 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.
A light node is a checker or peer that verifies specific records on request rather than holding a full copy of a swarm's state. The request model comes from draft-mih-agent-evidence-request-02, posted by Steven Mih on October 30, 2026, which is 3 days before the tap-to-record draft. Its rule is strict: the same subject under the same coverage must yield a byte-identical artifact for every requester, so asking twice cannot produce two different answers.
The minimum a light node needs to check one record is small and fixed in size, whatever the size of the swarm:
| What the light node needs | Why |
|---|---|
| The record itself | The signed statement about the action |
| Its inclusion proof | Shows the record is in the log |
| The checkpoint that covers it | Anchors the record to a point in the log's history |
| A witness cosignature on that checkpoint, or a transparency service receipt | Shows the checkpoint was witnessed by someone independent |
Partial messages in the gossip layer and evidence requests at the record layer are two forms of the same idea: check what you need, and no more. 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. That boundary is the honest limit of light-node checking, and it is why the draft keeps light nodes in the future-work column for most of their details.
Evidence requests are one half of a larger evidence layer, and the companion draft on that layer defines the local store a request is answered from. The companion evidence-layer draft was posted on October 3, 2026, which is 30 days before the tap-to-record draft. What the I2ICF framework is, in one line, is a separate agent framework for verifiable interaction context, and it sits beside this draft as a sibling approach to making agent work checkable rather than as a part of it.
What Exists Today and What Is Still Future Work
Nothing in this section should be read as a shipped product. The draft marks each component as implemented, prototype, or future work, and the honest picture is that most of the model is not built yet. The one piece that has run end to end is the payment rail, and the rest is prototype at best or still on the drawing board.
| Component | Status in the draft |
|---|---|
| Payment rail and settlement records | Implemented: run end to end in a reference implementation, on two payment rails |
| Evidence layer (companion draft) | Reference implementations exist |
| Tap record | Prototype at best: has not run together with the secure-element signature and session binding |
| Secure-element signature and citation | Prototype at best: no implementation known to the authors |
| Tap to authenticated session binding | Prototype at best: same as the tap record above |
| Processor trace and trace citation | Future: not built |
| Richer platform attestation | Future |
| Witnessed logs beyond the basics | Future |
| Gossip layer evidence | Future |
| Most light-node work | Future |
The implementation-status section is blunt: no implementation of the tap record, the secure-element citation, or the processor-trace citation described in the draft is known to the authors. And the worked examples carry their own caveat: both devices in any run the authors show are operated by the authors, so the examples demonstrate separate devices, not separate parties. No independent-party trial exists yet.
The draft is written for discussion in MAPRG, and this guide makes no claim of IETF adoption, working-group endorsement, or deployment beyond what the draft itself states. The research agenda is a set of 8 questions, and the draft is explicit that none of them is answered by the document itself:
| Open measurement question | What it asks |
|---|---|
| 1. Session corroboration | Can transport-level observations confirm that an authenticated session to the tapped key took place when a record says it did? |
| 2. Tap-to-session latency | How long from the tap to an authenticated transport session, with and without a secure-element signature? |
| 3. Evidence size per layer | How many bytes does each citation add, and how big is the bundle a light node receives for one interaction? |
| 4. Light node versus full replication | What bandwidth and time does checking one interaction through an evidence request take, against receiving the same state by gossip? |
| 5. Tap discovery versus DHT discovery | What are the success rate, latency, and lookup leakage for local peers found by tap rather than by DHT? |
| 6. Relay exposure | How often can a tap without round-trip bounding be relayed in realistic settings, and what does bounding cost? |
| 7. Witness coverage | How many independent witnesses does a checkpoint get in practice, and how quickly? |
| 8. Trace cost | What is the overhead of processor tracing for an agent workload, and how big is a trace summary that is still useful as evidence? |
Which of these existing libp2p telemetry can already collect, and with what limitations, is an open item for the next revision. That is the research agenda in one sentence: measure what exists, build what does not, and let the next revision say which questions have answers.
Who should follow this draft, and who should wait? The fit is narrow today:
| Reader | Verdict |
|---|---|
| Agent-infrastructure builders working on in-person agent payments | Follow it: the model names the pieces you will need to build |
| Teams already running agent settlement records | Follow it: the tap record mirrors the two-sided settlement pattern you know |
| Developers who need a shipping NFC payment protocol today | Wait: this draft defines no protocol and nothing here is a product |
| Anyone deciding on hardware attestation or transparency logs | Follow the two-roots section: it states plainly what each root can and cannot prove |
Sources
Every fact in this guide comes from a source fetched on November 6, 2026. The draft itself is the primary source, and the companion drafts and RFCs below are the context it cites.
- Tap-to-record draft, HTML full text: draft-gupta-mih-maprg-nfc-agent-evidence-00
- Tap-to-record draft, text version: draft-gupta-mih-maprg-nfc-agent-evidence-00.txt
- Datatracker document page and history: draft-gupta-mih-maprg-nfc-agent-evidence
- Companion draft, Evidence Layer: draft-mih-agent-evidence-layer-00
- Companion draft, Evidence Request: draft-mih-agent-evidence-request-02
- RFC 9943, Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture: RFC 9943
- RFC 9334, Remote ATtestation procedureS (RATS) Architecture: RFC 9334
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport: RFC 9000
Frequently Asked Questions
Is tap-to-record agent evidence a standard or a protocol?
No. It is a problem statement and a research agenda written for discussion in MAPRG, and it defines no protocol. Its intended status is Informational, which is the IETF label for a document that informs rather than standardizes, and it is an Internet-Draft, which means it is work in progress rather than an adopted standard.
Does a tap prove the two devices were next to each other?
Not by itself. A relay attack can stretch a near-field exchange across any distance unless the protocol bounds round-trip time. A tap establishes that a device holding a given key took part in an exchange that included a given nonce, and anything stronger, such as a claim about distance, needs a separate mechanism and has to be stated in the record that cites the tap.
Does a tap prove who the person holding the device is?
No. The tap names a key, not a person, and holding a key does not show that its holder was authorized to act for anyone. Identity and authorization are separate problems that the tap does not solve, and a record that cites a tap has to say which of these it relies on.
Is there a CodexFuse tool for tap-to-record evidence?
No. This guide is an explainer of an IETF draft, and no CodexFuse tool exists for tap-to-record evidence. The draft itself defines no protocol, so there is nothing to build a tool around yet, and this guide promises none.
When does the draft expire?
The -00 revision expires on May 6, 2027, which is 185 days after it was posted on November 2, 2026. As of November 6, 2026, no -01 revision exists, and there are 181 days left before the expiry. If no newer revision replaces it by then, the draft lapses, and anyone still using its vocabulary would be relying on an expired proposal rather than a live document.
