AI agent audit logs under India's DPDP Rules: what Rule 6 asks for

The short answer

India’s Digital Personal Data Protection Rules, 2025 ask every data fiduciary to keep “appropriate logs, monitoring and review” of access to personal data, and to keep those logs for one year. The duty starts eighteen months after the Rules were published on 13 November 2025, so on 13 May 2027.¹ If an AI agent reads or changes personal data for you, its actions belong in those logs.

This post explains what the Rules say about logs, what the one year covers, and what a useful log of an agent’s actions holds. It is a plain reading of the text, not legal advice. For what the Rules require of your organisation, ask a lawyer who practises in this area.

What Rule 6 asks for

Rule 6 lists the minimum “reasonable security safeguards” a data fiduciary must take, including for processing a data processor does on its behalf. Two of its clauses are about logs.¹

• Rule 6(1)(c): “visibility on the accessing of such personal data, through appropriate logs, monitoring and review, for enabling detection of unauthorised access, its investigation and remediation to prevent recurrence”.
• Rule 6(1)(e): for the same purposes, “retain such logs and personal data for a period of one year”, unless another law requires otherwise.

Three things stand out. The logs are about access, not only changes, so reads count. They exist for a purpose: to detect unauthorised access, investigate it, and stop it happening again. And “monitoring and review” means someone is expected to look at them, not just store them.

The same Rule names the data security measures it has in mind, such as encryption, obfuscation, masking and virtual tokens mapped to personal data. Rule 8(3) adds a separate one-year floor: personal data, associated traffic data and other logs of processing are kept for at least a year from the processing, then erased unless another law requires longer.¹

The Act itself defines personal data as “any data about an individual who is identifiable by or in relation to such data”, and has no separate sensitive or health category.² A patient’s lab result and a shopper’s delivery address are the same kind of data under the Act.

What “one year” covers

One year is a floor in these clauses, not a ceiling. Rule 6(1)(e) and Rule 8(3) both give way to other laws that need a longer period.¹¹ Sector rules, tax rules and hospital standards may ask for more.

What the text doesn’t settle, read on its own:

• Which logs. “Such logs” in Rule 6(1)(e) points back to the access logs of 6(1)(c). Whether an agent’s full tool arguments count as a log, or as personal data held inside a log, is a question for your counsel.
• What starts the clock. Rule 8(3) counts from the date of the processing. Rule 6(1)(e) doesn’t name a start date.
• Format. Neither clause names a format, a hash, or a signature. They ask for logs fit for detection, investigation and remediation.

For hospitals there is more to read alongside the Rules. India’s EHR Standards say all actions on health information, “including viewing”, should be recorded, and list ISO 27789 as the advisory standard for audit trails.³ The NABH Digital Health Standards include an element for a digital system that “captures the audit trails of each transaction”.⁴ The healthcare audit trail entry covers those in more detail.

Where AI agents fit

An agent with database credentials, an API key or a set of MCP tools is one more thing accessing personal data. The Rules don’t mention AI agents, and they don’t need to. A support agent that looks up a customer’s orders is accessing personal data. A coding agent that runs SELECT * FROM users while debugging is too.

Three habits make agents hard to log well:

1. They act under shared credentials. If the agent connects as the same database user as your app, the database’s own log can’t tell the two apart.
2. They act in volume. One request to an agent can become forty tool calls. A log with one line per request loses which records each call touched.
3. Their own account isn’t a log. An agent’s summary of what it did is a claim. It can be wrong, incomplete, or, after a prompt injection, written by someone else. Our post on why logs aren’t evidence goes through why.

So the log has to sit outside the agent, at the point where its calls reach your data.

What an agent action log should hold

For each tool call that touches personal data, a log built for Rule 6’s purposes needs to answer: who, what, whose, on whose say-so, and with what result.

Two properties matter as much as the fields. The log should show if a line was removed or changed later: a hash-chained log does that, because each entry carries a digest of the one before. And it should be readable by someone who doesn’t trust your servers, since the person investigating may be an auditor or the Board.

Keep the record, drop the payload

Here the Rules pull two ways. Logs that help an investigation want detail. Personal data you don’t need is risk you carry, and Rule 6 itself points at masking and tokens.¹

A workable split is to keep two layers:

• A permanent summary with ids, digests, decisions, times and outcomes. It holds no names, addresses or clinical values, so keeping it long costs little.
• The full payload, meaning the tool’s arguments and result, kept only for a set period and then removed. A digest of it stays in the summary, so a copy kept elsewhere can still be matched.

If your counsel decides the payloads themselves are logs you must keep for a year, set the payload period to at least 365 days. Many tools default to less.

Try it. Deedglass, the gate we build, works this way. Its sealed records hold ids, digests, decisions and times, not the request or the result. deedglass ledger prune removes payloads older than the retention you set; the default is 90 days, so set it higher if you need a year. Pruning isn’t automatic yet.⁵ Retention can be set from 1 to 3,650 days, and pruning never removes the sealed records.⁵ In PHI mode, requests and results are reduced to ids and digests as soon as an action is sealed and its checks are done; the limits are that payloads are held while an action waits for approval, and digests of short values can be guessed.⁶ To watch a record being made on a real Postgres, open the playground; to see which of your agent’s tables could be checked, run npx deedglass scan --postgres-dsn-env DATABASE_URL (the grade, explained).

What a log can’t do

• It only covers what passes through it. An agent holding a second, direct credential walks around any gateway log. Revoke the direct route.
• It doesn’t judge. A log shows that an agent read 300 customer records. It doesn’t say whether that was a reasonable thing to do. Someone has to review it, which is what “monitoring and review” asks for.
• It doesn’t settle the legal question. A log helps you answer questions about access. What the Rules ask of your organisation goes much further: notice, consent, breach reporting, contracts with processors.
• Digests aren’t anonymous. A digest of a short value, like a ten-digit phone number, can be found by trying every number.

A checklist

Before 13 May 2027, for every AI agent that can reach personal data:

1. List what it can reach: databases, APIs, MCP tools, files.
2. Give it its own credential, so its access shows up as its own.
3. Put its calls through one point that writes a log outside the agent’s control.
4. Log record ids and digests by default, not raw personal data.
5. Record decisions and approvals beside each call, not in a separate system.
6. Make the log show when an entry is removed or changed.
7. Decide, with counsel, how long payloads stay; set it to at least a year if they count as logs.
8. Check that another law doesn’t ask for longer: sector rules, hospital standards, tax.
9. Name who reviews the log, and how often.
10. Write down what the log doesn’t cover, so an investigator knows where to look next.

For how health data fits into the Act, see PHI and health data. For hospitals, the healthcare page shows what each record helps you show, and what it doesn’t cover.

Written with AI assistance and checked against our claims register.