Non-Repudiation, in Plain English

Consider why a security term so often sounds like a lawyer’s objection: non-repudiation is about denial after the event, not about making the event happen. In plain English, it asks whether a party can later deny having performed an action once that action has been carried out. The useful answer is not a slogan; it is a record strong enough to survive a dispute.

Non repudiation AI records

Non-repudiation in AI is not a magic property of a model. It is a property of the surrounding record. A model may draft a supplier email, propose a credit-limit change, or ask another system to release a payment. The dispute arrives later, when someone says the action was not theirs, was not approved, or was not performed by the agent named in the ticket.

The baseline definition is narrow. Non-repudiation ensures that the entity responsible for an action cannot deny performing it. That does not tell you whether the action should have been allowed. It does not tell you whether the policy was sensible. It does not tell you whether the business outcome was fair. It answers a smaller question: can the record tie the action to the responsible party tightly enough that a later denial fails?

That narrowness matters. Teams often use the phrase as if it meant general accountability. It does not. Accountability may include approval, policy, review, and remediation. Non-repudiation is one evidential ingredient. It is the part that resists the sentence, “that was not me.”

Non-repudiation ensures that an action recorded in the logs can be definitively attributed to a specific identity.

— LoginRadius, Ensuring Log Integrity and Non-Repudiation for AI Agents, 12 March 2026

That quotation is useful, and also limited. It is from a vendor engineering article, not a regulator. It supports a technical claim about attribution in logs. It does not create a legal obligation, and it does not settle what a court, supervisor, or counterparty will accept in a real dispute.

For AI agents, the practical issue is delegation. LoginRadius describes non-repudiation as especially important where AI agents operate on behalf of users or other systems. That phrasing is careful enough to be useful. A human may have asked for a task. An agent may have selected the next step. A connected system may have carried it out. Non-repudiation asks whether the record can still say who, or what, was responsible for the action being disputed.

This is where identity, permission, and evidence separate. The distinction is not academic. It is the difference between “the agent had a valid identity,” “the agent was permitted to change this record,” and “we can still prove both after the complaint arrives.” The separate identity and permission problem is treated directly in Identity Is Not Authorization Is Not Evidence.

Non repudiation example: a disputed payment transfer

A banking transfer is the clean case. Bitsight puts the split plainly: authentication confirms that the person is the account holder, while non-repudiation prevents that person from denying that they made a specific transfer. The example works because it separates a general identity fact from a particular action.

Imagine the dispute. A transfer leaves an account. The customer later denies making it. The bank has to show more than a successful sign-in. It needs the action record. It needs the transfer details. It needs the timing. It needs the link between the account holder and the instruction that moved the money.

None of that proves the transfer was wise. It may still have been mistaken. It may still have breached an internal limit. It may still require compensation. Non-repudiation is not a defence to every complaint. It is a defence to one specific denial: “I did not do that.”

Think of it like this: Authentication = “It’s really me.” Integrity = “The message/data hasn’t been altered.” Non-repudiation = “I can’t deny that I sent or agreed to this.”

— Portnox, What is Non-Repudiation in Cybersecurity?, 6 October 2025

The same pattern applies outside banking. A purchase order is approved. A customer record is deleted. A support agent changes an address. The later argument is not always about identity in the abstract. It is about whether a particular action can be tied to a particular actor, with a record that has not become a storytelling exercise after the fact.

SecurityScorecard gives purchase orders as an example of non-repudiation where vendors cannot dispute the transaction. That example is stronger than a generic “audit log” claim because it names the business event. A purchase order creates obligations. A later denial has commercial consequences. The evidence has to match the consequence.

A weak record says that something happened. A better record says who did it, what changed, when the action occurred, and what the relevant system accepted at the time. The best record for this purpose is not necessarily the most verbose one. It is the one that can answer the denial without depending on memory, screenshots, or a reconstructed sequence from several dashboards.

Non repudiation vs authentication

Non repudiation vs authentication is the distinction that prevents bad control design. Authentication asks whether a user or system is who it claims to be, while non-repudiation asks whether a party can deny involvement in an action or communication. Both can be present. Either can be missing.

Authentication happens before or during access. Non-repudiation matters after the action is contested. That difference changes the design target. A login screen can be excellent and still leave you unable to defend a later payment release. A service identity can be valid and still tell you nothing about the policy decision that allowed a customer record to be changed.

TechTarget describes nonrepudiation as like authentication, particularly in implementation. That is a fair warning, not a reason to merge the concepts. They may use related machinery and related records. They do not answer the same question.

SecurityScorecard states the operational risk more sharply.

Conflating authenticity with non-repudiation can leave critical visibility gaps in incident response, legal defensibility, and compliance posture.

— SecurityScorecard, What’s the Difference Between Authenticity and Non-Repudiation in Cybersecurity?, 19 June 2025

The word “can” is doing real work there. Confusion does not automatically make every record useless. A system may accidentally keep enough evidence to answer the later denial. But accidental sufficiency is not a control. If the record was built for troubleshooting, it may omit the actor, the approval, the exact object changed, or the condition that made the action acceptable.

A simple test helps. If the question is “who are you?”, you are in authentication territory. If the question is “were you allowed to do this?”, you are in authorisation territory. If the question is “can you later deny that you did this?”, you are in non-repudiation territory.

That third question is close to accountability, but not identical to it. SecurityScorecard says authenticity confirms origin, while non-repudiation can contribute to accountability and trust between parties. The phrase “contribute to” is the point. Non-repudiation helps accountability. It is not the whole of accountability.

This also explains why transparency is not enough. A clear explanation of why an AI system produced an output may help review. It may not prove who approved a payment release or who accepted a deletion. The neighbouring distinction between explanation and accountability is covered in AI Transparency Tools.

What this means if you have to produce evidence

The hard audience for non-repudiation is not the engineer who built the workflow. It is the person who was not there. An auditor, reviewer, customer, bank, supplier, or internal risk owner will not accept “the system knows.” They will ask to see the record.

SecurityScoreCard says the focus for non-repudiation should shift to preserving the integrity and origin of digital actions and materials. That sentence is a useful operating rule. It tells you what the record must protect. The record has to preserve the action and its source, not merely prove that a user once had an account.

For an AI agent, the evidence should be built around the disputed action. The unit is not a session. It is not a chat transcript. It is not the model response alone. The unit is the event that changed something outside the model: a released payment, a deleted record, a changed limit, an approved order.

That creates an awkward but necessary standard. If the action matters, the record must be understandable without replaying the whole system in someone’s head. It should show the actor, the instruction, the target object, the decision that permitted the action, and the resulting change. If any of those are missing, a later denial becomes easier to sustain.

There is another limit. Non-repudiation does not remove the need to ask whether the actor had authority. A person can be unable to deny pressing the button and still have pressed it wrongly. An agent can be tied to the record and still have exceeded its mandate. Non-repudiation proves involvement. It does not bless the action.

This is why evidence design has to sit beside runtime permission, not after it. A permission step such as GREENLIGHT is relevant only if the later record can show what was permitted and what happened next. A demonstration can show the workflow, but the evidential question remains the same; the useful prompt for a product demonstration is the disputed action you would have to defend.

Practical steps for a record you may have to defend

1. Name the disputed action. Do not start with “AI governance” or “agent monitoring.” Start with the concrete event: payment released, credit limit changed, supplier approved, record deleted. Non-repudiation attaches to actions and communications, not to aspirations.
2. Separate identity from denial. Record who or what acted, but do not stop there. Authentication can confirm the account holder while non-repudiation addresses denial of the specific transfer.
3. Record the permission fact. If an action required approval, the evidence should show the permission that existed at the time. Otherwise the record may prove involvement but leave the authorisation question open.
4. Keep the object specific. A record that says “customer data updated” is weaker than one that identifies the record and the change. General activity is useful for operations. Specific change evidence is useful in a dispute.
5. Preserve origin and integrity. Non-repudiation work should focus on preserving the integrity and origin of digital actions and materials. If either is unclear, the denial argument gets room to move.
6. Design for the absent reviewer. The person assessing the evidence later will not share the team’s memory. Write and retain records so that the sequence can be understood without private context.
7. Do not overclaim. Non-repudiation does not prove fairness, necessity, or regulatory compliance. It supports one claim: the responsible party cannot credibly deny involvement in the action.

For teams applying this to agents, the position is narrow: prove the permission before the action, keep the record after it, and treat identity as necessary but not enough; the adjacent pieces are Identity Is Not Authorization Is Not Evidence and GREENLIGHT, with a product demonstration only when the operating question is concrete.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Identity Is Not Authorization Is Not Evidence — separates who acted, what was permitted, and what can later be proved.
• AI Transparency Tools — compares explanation with accountability for AI systems.
• GREENLIGHT — the permission step for agent actions.
• Product demonstration — a way to test the evidential question against a concrete action.