Handing out consent is the easy bit, and it is not the part that worries me. Taking it back so the change reaches systems already using the data, and being able to say afterward exactly what got used and on whose say-so, those are the two that do. Most consent stories skip both of them. Here is how OConsent deals with each.

revoking is something you record, not something you erase

When a subject pulls their consent, we do not delete the record. We write a revocation event and flip the record’s status.

{
  "id": "rev_22b9",
  "consent_record_id": "rec_7f3a",
  "subject": "user_123",
  "revoked_at": "2026-07-10T09:00:00Z",
  "reason": "user_requested_revocation"
}

The next time anything verifies against that record, it gets a no.

{
  "allowed": false,
  "decision": "deny",
  "reason": "consent_revoked",
  "consent_record_id": "rec_7f3a"
}

Deleting the record would feel tidier and would be a mistake. Keep it, and you can still answer two separate questions honestly: was this allowed when it happened, and is it allowed now. Throw it away and you have lost the first answer to clean up the second.

the part nobody likes to say out loud

Revocation cannot reach into a model whose weights already learned the data. It cannot pull back a copy a partner already holds, or one sitting in a cache somewhere. You cannot un-train a model, and any consent product that implies you can is selling something. What revocation can do is make every future check fail and leave a dated record that the cleanup obligations downstream can hang off.

That is the real reason to check at the point of use. If collection was the only place you ever enforced anything, a revocation has nothing to act on. Enforce at use, and a withdrawal takes hold the next time a check runs. The short cache lifetimes from the last post are just how you keep the window between “withdrawn” and “actually stopped” small.

audit is what makes any of this provable

Every verification can write an audit event. This is the thing the verification response was pointing at.

{
  "id": "audit_91ac",
  "consent_record_id": "rec_7f3a",
  "actor": "model_pipeline_7",
  "asset": "conversation_export",
  "purpose": "llm_training",
  "decision": "allow",
  "checked_at": "2026-06-28T10:20:01Z",
  "enforcement_point": "fine_tuning_pipeline"
}

One object that says who used what, for which purpose, under which record, what was decided, and where it happened. The reason it beats a folder of screenshots is that the question you actually get asked is never “do you have a policy.” It is “show me the decision for this asset, on this date, by this pipeline,” and a policy document has no answer to that.

evidence you can edit is not evidence

An audit log you can quietly rewrite later is just a better-looking story. The floor is append-only: events get written, never updated, ordered by time. If you also need to defend the log itself, optional cryptographic anchoring chains each event to the one before it and pins the chain to an outside timestamp, so a missing or altered event shows up rather than slipping by. This is where the older protocol work, the signatures and the anchoring, actually pulls its weight: sitting under the audit trail as proof, not on the front page as a slogan.

making the trail something people use

Write an event for every decision, denials included, since the denials are usually the ones you end up needing to prove you made. And keep the export boring and stable, the kind of thing a legal or security team can pull on their own, because an audit trail that needs an engineer and a one-off query is a trail nobody ever checks.

The revocation and audit objects are specified in the draft spec, and the agent memory example runs through a grant, a use, a revocation, and the denial that comes after.

---

Written by Subhadip Mitra. Found a mistake or want to push back? Open an issue or email [email protected].