Someone denies sending a message. Not the soft version — I didn't mean it that way — the flat one: that did not come from me.
Non-repudiation is the name for the property that would settle it. It is narrower than people assume, harder to obtain than most systems admit, and claimed all the time by systems that do not have it.
Non-repudiation removes one specific excuse
Non-repudiation is the property that a party cannot credibly deny having sent a message or agreed to a term. That is the whole of it. It says nothing about whether the message was true or the terms fair. It closes exactly one line of retreat.
The classical mechanism is a digital signature. The sender holds a private key; the signature is computed with that key over the message; anyone with the matching public key can check it. Two things follow. Any change to the message invalidates the signature. And — the part that matters here — the person checking could not have produced the signature, because they never had the private key.
Authentication, integrity, and non-repudiation are three properties
They get used interchangeably. They point in different directions and answer to different audiences.
- Authentication asks who are you. It is answered to the system, at the time of the act, by presenting something you know or hold.
- Integrity asks was this altered. It is answered about the message, by detecting modification.
- Non-repudiation asks can you deny it later. It is answered to a third party, after the fact.
A message authentication code makes the difference concrete. Two parties share a key; either can tag a message with it and either can verify a tag. That gives integrity, and authentication between them. It gives no non-repudiation at all, because when one of them shows a third party a tagged message, the tag proves only that one of the two produced it. The person presenting the evidence is not a witness. They are a suspect.
So the mechanism underneath non-repudiation is asymmetry — evidence producible only by the party you want to bind, and checkable by someone who cannot produce it. Every shared-secret scheme fails that by construction, however long the secret.
What even a real signature does not prove
A signature binds a key, not a person. Everything connecting the key to a human — enrolment, device custody, revocation when a laptop goes missing — sits outside the cryptography, and that is where the argument actually happens. Non-repudiation converts I never sent that into my key sent that and I did not, which is a materially worse position to argue from and still not a closed case.
Whether any of it counts for anything in a dispute depends on jurisdiction and is a question for a lawyer rather than a blog post. The engineering property and the legal one share a name and are not the same thing.
Assistant-mediated correspondence has a second denial
Signatures address one denial: I did not send that. Correspondence drafted by AI introduces a second: I sent it, but I did not write it.
That one is harder, mostly because it is frequently true. Plenty of messages go out under a person's name having been skimmed and approved rather than composed, and on the page a considered commitment and a fluent draft that got a nod look identical. Provenance is the record built for that question — which words came from the person, which from the model, and through what process.
A provenance label is a record, not a proof
Here is the honest accounting, which is the reason this page exists.
RelayLink attaches a provenance label to the sender's note. Four labels exist, produced by a single function, so the email, the web view, and a recipient's assistant all render the same string. The strongest, (verbatim, human-authored), is applied only when the sender's final wording differs from what their assistant drafted — echoing the draft back is recorded as (AI-drafted, approved unchanged by the sender). No tool parameter accepts a provenance value, so the drafting model cannot request its own label.
That is a real control. It is not non-repudiation, for four reasons.
- Nothing is signed. The label is an ordinary string stored inside the package record. No signature, no attestation, no tamper-evident hash. It is trustworthy because the write path is gated on the server, not because a recipient can check it.
- The sender's credential is a shared secret. Access to the tool surface is a per-user API key sent in a request header and matched against the stored value. The server holds the same secret it checks, which is precisely the situation that rules out non-repudiation. Whoever holds a leaked key is that account.
- The record's keeper is a party to it. Content is stored as ordinary text and nothing is end-to-end encrypted, so the operator keeping the record can read it. A record's worth tracks the trust you place in whoever keeps it.
- One tier says so on the label. A reply typed through a magic link or sent as plain email carries
(typed by the recipient via magic link / email — not server-authenticated authorship). Possession of the token is the entire authentication, including by anyone the mail was forwarded to. The wording under-claims on purpose.
What remains is a well-kept record. Content is written once and never rewritten — no edit, unsend, or recall path exists — so the entry that survives is the entry that was delivered. The frame around a delivered package includes the phrase "verified account control", which means an account authenticated, not that anyone verified which human was at the keyboard.
Say what you actually have
The failure worth avoiding is describing a process record in the vocabulary of proof. Cannot be forged. Cryptographically guaranteed. Provably human. None of that describes a label a server assigns and stores in plain text.
What it does describe: a message carrying a machine-produced statement about how its words got there, applied by a system the sender does not control, rendered identically wherever it appears. Enough to make a reader's judgement calibrated instead of blind, which is most of the practical value. Not enough to bind a sender against their own denial.
What a record has to contain before anyone can reconstruct events from it is what an audit trail is for, and the case for keeping correspondence at all is made separately. To see a labelled message from the receiving end, connect your assistant.