India's data protection law, duty by duty, for AI agents.

The Digital Personal Data Protection Act, 2023 (DPDP Act) is India's law on digital personal data. It applies to the processing of digital personal data within India. It also applies to processing outside India "if such processing is in connection with any activity related to offering of goods or services to Data Principals within the territory of India" (Section 3(b)) ¹.

The Digital Personal Data Protection Rules, 2025 (DPDP Rules) were published in the Gazette on 13 November 2025, and they come into force in three steps (Rule 1) ²:

Rules 1, 2 and 17 to 21 on publication;

Rule 4, on Consent Managers, one year later, in November 2026;

Rules 3, 5 to 16, 22 and 23 eighteen months after publication, in May 2027. Those include notice, security safeguards, breach intimation, retention and erasure, children's data, Significant Data Fiduciaries and the rights of Data Principals.

There are two bases: consent (Section 6) and certain legitimate uses (Section 7).

Consent must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action", limited "to such personal data as is necessary for such specified purpose" (Section 6(1)). The legitimate uses are listed in Section 7. They include data the principal "has voluntarily provided" for a specified purpose without objecting, compliance with law or a court order, medical emergencies, disasters and employment.

Neither basis is a general "legitimate interests" ground. That is one of the plainest differences from Europe's GDPR.

Every request for consent comes with, or after, a notice (Section 5). The Rules say the notice must "be presented and be understandable independently of any other information" (Rule 3(a)). In "clear and plain language", it must give at the minimum (Rule 3(b), (c)):

"an itemised description of such personal data";

the specified purpose and "specific description of the goods or services to be provided or uses to be enabled";

how the Data Principal may withdraw consent, "with the ease of doing so being comparable to that with which such consent was given";

how to exercise her rights; and

how to "make a complaint to the Board".

The notice must also be available "in English or any language specified in the Eighth Schedule to the Constitution" (Section 5(3)), which lists 22 languages. Every consent request has to name the contact details of a Data Protection Officer, where there is one, or of another authorised person (Section 6(3)).

For data collected before the Act, a fiduciary must give a notice "as soon as it is reasonably practicable" (Section 5(2)).

What AgentAnywhere does: notices are versioned per purpose and can be written in English or any of the 22 languages; the notice headings ship in English and Hindi. Each consent record names the exact notice version the person saw.

Withdrawal: a Data Principal may withdraw consent "at any time" (Section 6(4)). The fiduciary must then, "within a reasonable time, cease and cause its Data Processors to cease processing" (Section 6(6)), unless the law requires otherwise.

The burden of proof: if consent is ever in question, "the Data Fiduciary shall be obliged to prove that a notice was given … and consent was given" (Section 6(10)).

Consent Managers: these registered intermediaries come into force with Rule 4, in November 2026.

What AgentAnywhere does: a consent ledger per workspace. Each entry records the person, kept as a keyed hash rather than the identifier itself, the purpose, the notice version, given or withdrawn, when, and through which channel. Withdrawing is one call, the same as giving. A "Check consent" step stops an agent workflow, or sends it another way, when there is no consent for its purpose.

Integrating with a registered Consent Manager is a separate interface. It is not built.

Section 8 makes the fiduciary responsible for all processing, including "on its behalf by a Data Processor" (Section 8(1)). The duties that matter most for AI agents:

1. Processors only under contract (Section 8(2)).

2. Accuracy where data drives a decision: where personal data "is likely to be used to make a decision that affects the Data Principal", ensure "its completeness, accuracy and consistency" (Section 8(3)).

3. Reasonable security safeguards to prevent a personal data breach (Section 8(5); Rule 6).

4. Breach intimation to the Board and each affected person (Section 8(6); Rule 7).

5. Erasure when consent is withdrawn or the purpose is no longer served, including by processors (Section 8(7); Rule 8).

6. A published contact for questions (Section 8(9); Rule 9).

7. An effective grievance mechanism (Section 8(10)).

The sections below take them in turn.

Yes. Each audit event is signed with HMAC-SHA256 and linked into a per-workspace hash chain, so a changed or removed entry shows when the trail is verified. "Verify the trail" on the Audit page reports either that every entry is signed and chained, or the first entry that was changed or is missing.

That makes a change detectable. It does not make one impossible: the signing secret is held by the deployment's own services, so whoever holds it could rewrite the trail, and removing the newest entries leaves no gap for the check to find.

"On becoming aware of any personal data breach", the fiduciary must tell two audiences.

Each affected Data Principal must be told "without delay", "in a concise, clear and plain manner", through her user account or registered contact (Rule 7(1)):

a description of the breach (nature, extent, timing);

the consequences likely for her;

the measures taken to mitigate risk;

the safety measures she may take; and

a contact who can answer her questions.

The Board must be told (Rule 7(2)): "without delay", a description including nature, extent, timing, location and likely impact; and "within seventy-two hours of becoming aware of the breach", or a longer period the Board allows on written request, the updated details, "the broad facts related to the events, circumstances and reasons leading to the breach", the mitigation, any findings about who caused it, remedial measures, and "a report regarding the intimations given to affected Data Principals".

What AgentAnywhere does: the audit trail and run records establish what happened, when, by whom and to which runs. They are searchable by date and exportable, and an evidence pack is available for each run.

A breach-incident record starts the 72-hour clock and drafts both the plain-language intimation to each person and the detailed report to the Board.

Deciding that something is a breach, and sending both notices, stay yours.

Section 8(7): erase "upon the Data Principal withdrawing her consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier", and "cause its Data Processor to erase" too, unless another law requires the data to be kept. The Act's own illustration is a bank that keeps a closed account's identity records for ten years because banking law requires it.

Rule 8(1) and the Third Schedule: set periods after which purposes are deemed no longer served, for certain classes of fiduciary.

Rule 8(2): "at least forty-eight hours before" erasure on that ground, the fiduciary must tell the person that the data will be erased unless she logs in or makes contact.

What AgentAnywhere does today:

Agent memory: an erasure by person removes every entry tagged with them, and its search-index entry. It also catches entries that mention their email address. The person is stored as a keyed hash, not as their email. Each erasure is an audit event, reports how many rows and index entries it removed, and contains no memory text.

Knowledge: one document, or a whole collection, can be deleted, removing its passages and their embeddings.

Document-field fingerprints: a subject's fingerprints can be erased.

Expiry: session memory, long-term memory past its retention, audit events and run records are deleted when their periods end.

One erasure request fans out to memory, knowledge, document fingerprints and run records. It returns a receipt: what was removed in each system, what was kept and why, and what no request can reach, with when it ages out (service logs, backups). The notice due at least 48 hours before erasure under Rule 8(2) is drafted and recorded.

Each audit event is written once and chained. An erasure is recorded in the audit trail as an event of its own; it does not delete past audit entries.

An access report per person, giving counts and locations in each system; correction notes; and a grievance record with its clock.

The model provider and model are named on every model step's answer, so you can list which processor saw which run. That is part of what an access request asks for.

A child is anyone under 18.

Before processing a child's personal data, the fiduciary must "obtain verifiable consent of the parent" or lawful guardian (Section 9(1)). The same applies to a person with a disability who has a lawful guardian.

It must not "undertake tracking or behavioural monitoring of children or targeted advertising directed at children" (Section 9(3)).

Rule 10 sets out how to check that the person giving consent is an identifiable adult: by "reliable details of identity and age" already held, or by details or "a virtual token" provided voluntarily. That includes tokens issued by an authorised entity or a Digital Locker Service Provider.

What AgentAnywhere does: a principal can be flagged as a child or as a person with a lawful guardian. Their consent then records how the parent or guardian was verified, not the documents themselves. A purpose can be marked as not allowed for children, so the consent check refuses it.

A Significant Data Fiduciary must (Section 10(2); Rule 13): appoint a Data Protection Officer "based in India"; appoint an independent data auditor; and carry out a Data Protection Impact Assessment and an audit "once in every period of twelve months", sending the Board a report of the significant observations.

For a Significant Data Fiduciary, Rule 13(3) asks for due diligence that technical measures, "including algorithmic software", are not likely to risk Data Principals' rights. In our reading, AI agents an SDF deploys fall within that.

Rule 13(4) lets the Government specify personal data that an SDF may not transfer outside India, together with its traffic data.

What AgentAnywhere records: what each agent did and on which evidence (the run's evidence pack); who approved a held step, when and with what note; and which model and which checks were involved. Those records feed a DPIA and an audit.

A Significant Data Fiduciary can keep a structured record of each DPIA and audit: the scope, the observations, the Rule 13(3) algorithmic-software check, the measures, the date the report went to the Board, and the next due date. The platform records the assessment; it does not carry it out.

Yes, subject to restriction. The Government "may, by notification, restrict the transfer of personal data … to such country or territory outside India as may be so notified" (Section 16(1)). Data transferred abroad remains subject to "such requirements as the Central Government may … specify" about making it available to a foreign State or its agencies (Rule 15).

What AgentAnywhere does: AgentAnywhere is designed to run in your own environment. Whether a step calls an outside model provider is set per step and shown. Such a step runs on the account your workspace connected, and its answer names the provider and model, so you know which processor each run used and whether data left your environment. AgentAnywhere Swaraj is designed to run with no outside provider at all.

The platform records where each processor processes data and flags those outside India or not recorded; it does not decide whether a transfer is allowed.

Five differences decide how you build:

Lawful bases: consent, or the listed legitimate uses (Section 7). There is no general "legitimate interests" ground.

No special categories: the Act defines no separate class of sensitive data. Sensitivity enters through Significant Data Fiduciary notification and the Rules.

Children: a child is anyone under 18, with verifiable parental consent and a bar on tracking and targeted advertising.

Consent Managers: registered intermediaries through which a person manages consent.

Penalties: fixed maximum amounts in rupees, per breach, not a share of turnover.

A bank's RFP will often say it plainly: governed by DPDPA, not GDPR, and GDPR controls are not assumed equivalent. Map your controls to the Act's sections, not to GDPR articles.

An AI agent can touch personal data in several places at once: the prompt sent to a model, the documents it searches, the memory it keeps between conversations, the logs of what it did, and the systems it writes to.

Every one of those must be inside your safeguards, your retention periods and your erasure. A model provider is a processor, and needs a contract. A memory that outlives its purpose, or a search index that still holds a deleted document, is personal data you were obliged to erase.

For the ten fixes to make in your AI agents before May 2027, see the DPDP Rules and your AI agents.

1. Map every agent to a purpose and a lawful basis. List what personal data it touches: the prompt, documents, memory, logs, and the systems it writes to.

2. Mask before the model wherever a prompt may carry personal data, and record which model provider processes what.

3. Set retention to a year or more for audit and run records, and for service logs.

4. Test erasure end to end. Delete a person and confirm their data is gone from memory, from the search index and from documents, and that the receipt says what was kept and why.

5. Rehearse the 72-hour report: find the facts from the audit trail, draft both notices, and time it.

6. Write the notice in English and the languages your customers read, and record which version each consent saw.

7. Contract every processor, model providers included.

8. If you may be notified as a Significant Data Fiduciary, start the DPIA now, with the evidence your AI layer already records.

It does not make you DPDP compliant, and nothing it records replaces a decision the Act leaves to you.

A call to an outside model provider sends the prompt to that provider under your agreement with it, so mask first when the prompt may carry personal data.

Logs and records are kept for the periods the deployment sets, and those are shorter than a year until changed.

Service logs age out on their own schedule, and so do backups. An erasure does not reach them until they do.

The masking step's own input, the original value, stays in its run record until that record's retention period ends.

It is not a registered Consent Manager.