One consent store, three ways in: designing for Consent Managers and AI agents under DPDP

#ai #dpdp #privacy #agents

What Rule 4 changes in your data model, and what it does not.

On or about November 13, Rule 4 of the DPDP Rules starts. It opens registration for Consent Managers. It does not require an ordinary Data Fiduciary to use one. Still, if a customer picks a Consent Manager, your system has to accept that consent and honour a withdrawal that comes through it.

Here is how I would model that so it does not turn into a second, separate consent system.

One record, more than one channel

A Consent Manager is a new source of consent. It is not a new kind of consent. So it goes into the same table as direct consent, with a field that says how it arrived.

consent_record
  id
  principal_ref        -- the Data Principal
  purpose
  method               -- direct | consent_manager
  status               -- active | withdrawn
  cm_id                -- null for direct consent
  cm_artifact_id       -- null for direct consent
  cm_artifact_hash     -- null for direct consent
  cm_signature         -- null for direct consent
  created_at

The four cm_ fields stay empty for direct consent. When a Consent Manager sends consent, you store its artifact, the hash of that artifact, and its signature next to the record. You can then prove what it sent, unchanged.

You also need a small table for each Consent Manager you connect to: its name, registry ID, API endpoint and public key. The public key is how you check the signature.

One audit log

The audit log should be append-only and hash-chained. Each entry carries the hash of the one before it, so an edit anywhere breaks the chain. Consent given, changed and withdrawn all land in this one log, whichever channel they came from. A withdrawal from a Consent Manager follows the same rule as a withdrawal from your own form.

The part most designs miss: who acted

Consent is only half the story. The other half is who touched the record afterward. A common setup has an enrich agent, a summary agent and an archive agent all running under one service account. The log then says "pipeline-svc did it" and nothing more.

What I would add to each audit entry, as a pattern and not a standard:

audit_log
  seq, prev_hash, hash
  consent_id
  event                -- given | changed | withdrawn | read | copied
  actor_type           -- person | system | agent
  actor_id             -- unique per agent, not a shared account
  ts

With this, the question "who handled this record, and under which consent?" is one query.

What I am not sure about

The Consent Manager artifact format is not final. My draft follows the Account Aggregator consent artifact. The real DPDP format is not yet specified, so expect it to change.
The Board has not published its registration process or technical standard, as far as I can find. Any API you build now is a guess. Keep the Consent Manager side behind a thin adapter.
When consent is withdrawn and an agent has already copied the record, should the system fail the next read, or finish and flag it?

If you have built any of this, I would like to hear what broke.

DEV Community