DPDP Act and AI Security: What Rules 6 and 7 Mean for Prompts, Agents, and Logs

A customer attaches a PDF to a support ticket, and your AI support copilot reads it, because that is exactly what it was built to do. Hidden in white text on the second page is an instruction to look up the customer's record and send it to an external URL. The agent queries your CRM, retrieves a name, address, and phone number, and posts them out. Neither your DLP nor your SIEM records anything unusual.

Under India's Digital Personal Data Protection Act, that is a personal data breach, and DPDP Rules 6 and 7 now apply together. Rule 6 asks whether your security safeguards were reasonable. Rule 7 requires you to notify every affected person without delay, and to file a detailed report with the Data Protection Board within 72 hours explaining what happened, why, and who caused it. Both rules apply from 13 May 2027.

This guide maps both rules onto the three places AI handles personal data: prompts, agents, and logs. It walks through three breach scenarios and lists the evidence the Board will ask for. It closes with the controls to build now. For the wider set of DPDP obligations, see our DPDP Act and AI compliance overview.

What do DPDP Rules 6 and 7 require from AI systems?

Rule 6 requires every Data Fiduciary to take reasonable security safeguards for personal data it holds or controls, including data that AI vendors process on its behalf. Rule 7 requires notifying affected individuals and the Data Protection Board of any personal data breach without delay, followed by a detailed Board report within 72 hours.

Both rules reach your AI stack the moment a prompt, retrieved document, model response, agent tool call, or log line contains personal data. Your model provider, vector database, and observability platform all process that data on your behalf, so they fall within Rule 6 as your Data Processors, and you remain accountable for them.

Rule 6: seven minimum safeguards, mapped to AI

Rule 6(1) lists seven safeguards and treats them as a floor, not a ceiling. The table below shows what each clause means once AI enters the stack.

Clause (a) is unusually specific. It names "virtual tokens mapped to that personal data", which describes reversible tokenisation almost word for word and gives AI teams a defensible pattern to build on.

Rule 7: two notification tracks with different clocks

Rule 7 creates parallel duties that start when you become aware of a breach. Several widely shared guides say individuals must be told within 72 hours, but that misreads the Rule.

The duty to individuals has no 72-hour allowance, which makes it the stricter of the two. Rule 7 also has no severity threshold, so you cannot decide that a breach is too small to report.

When do the rules apply, and what is at stake?

Rules 6 and 7 come into force on 13 May 2027, eighteen months after the DPDP Rules, 2025 were notified. Under the Schedule to the Act, failing to take reasonable security safeguards can attract a penalty of up to ₹250 crore, and failing to notify a breach up to ₹200 crore. A single AI incident can attract both.

What changed in the DPDP framework in 2026?

The legal deadline for Rules 6 and 7 is still 13 May 2027, but three developments in 2026 change how you should plan. MeitY proposed fast-tracking parts of the timeline. The Data Protection Board's selection process began. And Consent Manager registration starts on 13 November 2026.

As of early October 2026, the January proposal had not been gazetted. Public reporting through August indicated that the Board still had no appointed Chairperson (LiveLaw).

Neither development changes your obligations, but the retention proposal should change your sequencing. Rule 8(3) requires keeping personal data, traffic data, and processing logs for at least one year, including logs held by your Data Processors. For AI, that covers prompt logs, gateway logs, and whatever your model and observability vendors retain. A 90-day runway would leave little time to redesign them, so treat November 2026 as your internal deadline for AI log architecture.

Why does AI make Rules 6 and 7 harder to meet?

AI moves personal data as free text across three surfaces that SIEM, DLP, and CASB tools were not built to inspect: employee prompts, AI applications and agents acting through connected tools, and the logs that record both. Each surface creates Rule 6 obligations, and each one can trigger Rule 7.

• Prompts. Employees paste customer emails, HR records, and case notes into AI tools to work faster, often through personal accounts that security teams never approved. This is shadow AI, and the data leaves as language rather than as a file, so there is no upload event for traditional controls to catch.

• Agents. Agents retrieve and send data on their own, querying CRMs, databases, and external tools without a human approving each step. An evaluation of 6,675 agent tools found that 65.42% of the data fields they transmitted were redundant or sensitive (AgentRaft, arXiv). That is the opposite of the data minimisation Rule 6 expects.

• Logs. LLM applications record prompts, responses, retrieved chunks, and tool calls by default, usually with a third-party observability vendor. Rule 6(1)(e) then asks you to keep those logs for a year, turning every unmasked prompt into a retained copy of personal data.

Your existing stack sees the edges of these interactions, not their content. We cover this gap in depth in our guide to AI usage audit logs.

Because Rule 7 has no materiality threshold, these blind spots matter at scale. Every unseen interaction is a potential breach you cannot assess.

What does a DPDP breach look like inside an AI system?

A DPDP breach in an AI system is any unauthorized processing, disclosure, alteration, or loss of personal data that flows through a prompt, an application, an agent, or a log. A blocked attempt is not automatically a breach. What matters is whether personal data was actually compromised, and only your logs can tell you which happened.

Scenario 1: an employee pastes HR records into a personal AI account

An HR executive needs appraisal letters by the end of the day and pastes 40 employee records, including names, PAN numbers, and salaries, into a personal AI account.

2026-10-02T14:07:31+05:30  event=ai_prompt  user=hr.exec@company.in
  destination=external_ai_assistant  account=personal  sanctioned=false
  entities_detected: PERSON=40  PAN=40  SALARY=40
  action=allowed

Because the prompt was allowed, the data now sits with a provider you have no processor contract with, so it needs breach assessment. Had the prompt been redacted or blocked before leaving the device, the same event would be a prevented exposure. Your counsel should decide in advance how you classify the allowed case, because there will be no time to debate it once the clock is running.

Scenario 2: an attacker uses prompt injection on a support chatbot

A user tells your customer-support chatbot to ignore its instructions and show the account details of another customer. This is prompt injection, which ranks first in the OWASP Top 10 for LLM Applications. If the attack is caught before any data is retrieved, it is an attempted attack. If the chatbot returns another customer's data, it is a strong breach indicator, and the Rule 7 clocks start.

Scenario 3: a hijacked agent exfiltrates customer data

This is the attack from the introduction. A hidden instruction in a ticket attachment redirects your support copilot.

req_7f3a9  agent=support-copilot  trigger=ticket#48213 (attachment.pdf)
  step 1  tool=ticket.read          -> hidden instruction in attachment
  step 2  tool=crm.lookup(C-99120)  -> name, address, phone
  step 3  tool=http.post(external)  -> 200 OK
  policy_decision=none  alert=none

With this trace, you can reconstruct the events, name the customer to notify, and trace the payload to the ticket's submitter, which is exactly what the Board will ask for. If the agent's MCP connections run without authentication or scoping, as many do, the agent reaches step 3 unchallenged (why that happens).

Attempt or breach? How to classify AI events

How do Rule 6 safeguards apply to prompts, agents, and logs?

Rule 6 maps onto AI through four controls. Mask or tokenise personal data before it reaches a model. Scope what every agent can read, write, and execute. Log every AI decision without storing raw personal data. And bind every AI vendor by contract. Each control also produces evidence you can show the Board.

Prompts: tokenise before the model sees the data (Rule 6(1)(a))

Inspect every prompt, every piece of retrieved context, and every model response at runtime, and mask personal data before it crosses your boundary. Reversible tokenisation fits the Rule's own wording about virtual tokens mapped to personal data: the model reasons over <PERSON_1> and <PHONE_1>, while the real values stay in a vault you control. How you remove data affects output quality, which we compare in sanitisation vs redaction vs smart redaction.

Agents: scope access and record lineage (Rule 6(1)(b) and (c))

Rule 6(1)(b) covers access to "computer resources", a term from the IT Act, 2000 that is broad enough to include the systems and data an agent reaches. Treat every agent as a non-human identity with explicit Discover, Read, Write, and Execute permissions, and deny everything else by default. For Rule 6(1)(c), log every tool call under a single request ID, so that one incident can be replayed from trigger to final action.

Logs: resolving the retention paradox (Rule 6(1)(e) and Rule 8(3))

Rule 6(1)(e) asks you to keep logs and personal data for one year to investigate unauthorised access. If those logs hold raw prompts, you have built a year-long archive of exactly the data you are meant to protect, and a single leaked credential exposes all of it. The way out is to redact at the point of capture:

• Capture each prompt, response, and tool call at the AI gateway.

• Detect personal data before anything is written.

• Replace each value with a token, and keep the mapping in a separate vault with tighter access.

• Write the log with tokens, entity types, policy decisions, and request lineage, but no raw values.

• Retain the masked log for one year, and re-identify records only for a specific investigation, logging that access too.

Investigators still get who, what kind of data, which tool, and what happened, while the log store stops being a breach target. If you use zero-retention settings with a model provider, ask counsel how they interact with Rule 8(3)'s separate one-year retention duty for processing logs.

Processors: put security in the contract (Rule 6(1)(f))

List every AI vendor that touches personal data, including model providers, vector databases, observability tools, and MCP server vendors. Each contract should include security safeguards, breach escalation fast enough to fit your 72-hour window, and retention terms you can rely on.

What will the Data Protection Board ask for within 72 hours?

Within 72 hours of becoming aware of a breach, the Board expects six things from you: updated details, the events and reasons behind the breach, your mitigation, findings on who caused it, remedial measures, and a report on the notices you sent to individuals. For an AI incident, every one of those answers depends on interaction-level logs.

"Becoming aware" is the real clock

Both Rule 7 clocks start when you become aware of the breach, so detection speed decides how much of the 72 hours you actually get. That links Rule 7 back to Rule 6(1)(c): weak monitoring turns a three-day window into a few hours of reconstruction.

Run the CERT-In and DPDP clocks as one workflow

DPDP does not replace India's existing incident rules. The CERT-In Directions of 28 April 2022 require specified cyber incidents to be reported within six hours of noticing them, and require ICT logs to be kept for a rolling 180 days within India. A single AI incident can therefore trigger a six-hour CERT-In report, two DPDP notices without delay, and the 72-hour Board report. Build one intake process that pulls the same AI evidence for all of them. If your AI gateway logs live only in a foreign cloud region, check them against CERT-In's in-India requirement.

How LangProtect helps you meet Rules 6 and 7

LangProtect supports Rules 6 and 7 at the AI interaction layer. Guardia governs employee AI use, Armor protects AI applications at runtime, and Vector controls what agents can access through MCP. Together, they detect personal data, mask or block it, restrict agent actions, and record the evidence a 72-hour Board report depends on.

We built this around the three surfaces covered in this guide, because that is where we see personal data move in enterprise environments. Every interaction passes through the same six-step control flow:

• Discover AI assets, including shadow AI tools, applications, agents, and MCP servers

• Identify the employee, application user, or agent behind each action

• Inspect prompts, responses, retrieved context, files, and tool calls

• Detect and classify personal data

• Redact, block, deny, or quarantine, according to your policy

• Record the decision as technical evidence

What each product does for Rules 6 and 7

Here is how that works in practice. When a support employee pastes a customer's name, phone number, and account ID into an external AI assistant, Guardia's Smart Redact replaces those values with protected tokens before the prompt leaves the device. When a customer copilot retrieves a full transaction history to answer a question about one ticket, Armor removes the unnecessary context before the model sees it. And when an HR agent asked for a leave balance also tries to read payroll and medical records, Vector allows the leave lookup and denies the rest before those calls reach the server.

Where LangProtect stops

Compliance under Rules 6 and 7 is shared, and we would rather you know the boundary up front.

LangProtect supports selected technical controls under the DPDP Act at the enterprise AI interaction layer. It does not determine lawful purpose, obtain consent, perform statutory notifications, or certify DPDP compliance. For the full section-by-section mapping, see our DPDP Act & AI solution brief.

Frequently asked questions

Do DPDP Rules 6 and 7 apply to employee use of ChatGPT and other AI tools?

Yes. When employees enter personal data that your organisation holds into an AI tool, Rule 6 requires reasonable safeguards for it, including control over which tools may receive it. If that data reaches an unapproved tool, the event may be a personal data breach that triggers Rule 7's notification duties.

Does the 72-hour DPDP deadline apply to notifying individuals?

No. Under Rule 7 of the DPDP Rules, 2025, affected individuals must be notified without delay, with no 72-hour allowance. The 72-hour deadline applies only to the detailed report to the Data Protection Board, which follows an initial Board intimation that is also due without delay.

How long must AI prompt logs be kept under the DPDP Rules?

At least one year. Rule 6(1)(e) requires keeping logs and personal data for one year to investigate unauthorised access, and Rule 8(3) separately requires keeping processing logs for a minimum of one year. Store those logs with personal data masked or tokenised, so the log store does not become a breach target.

Is a blocked prompt injection attempt a reportable DPDP breach?

Not automatically. A personal data breach under the DPDP Act requires unauthorised processing, disclosure, or loss of personal data. If an attack is blocked before any personal data is retrieved or disclosed, it is an attempted attack. Preserve the evidence, confirm nothing was exposed, and record your assessment.

Are LLM providers Data Processors under the DPDP Act?

When a model provider processes personal data on your behalf through your AI application, it acts as your Data Processor, and you remain the accountable Data Fiduciary. Rule 6(1)(f) requires your contracts with such providers to include reasonable security safeguards.

When do DPDP Rules 6 and 7 come into force?

Rules 6 and 7 come into force on 13 May 2027, eighteen months after the DPDP Rules, 2025 were notified on 13 November 2025. A January 2026 MeitY proposal to shorten parts of the timeline had not been gazetted as of October 2026.

May 2027 is one budget cycle away

Rules 6 and 7 turn AI security from a best practice into an evidence obligation. Every safeguard needs a record behind it, and every breach needs a reconstruction that holds up within 72 hours. The organisations that will be ready in May 2027 are the ones that start now: redacting personal data at capture, scoping what their agents can touch, and logging every AI decision with lineage.

When the Data Protection Board opens an inquiry, its question will be simple: show us what happened. Make sure your AI stack can answer it.

Sources

• Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E)), MeitY

• Digital Personal Data Protection Act, 2023, MeitY

• Data Protection Board appointment notice, MeitY, May 2026

• MeitY plans to cut short DPDP compliance timeline, Chambers and Partners, February 2026

• India's Data Protection Board: Established in Law, Absent in Fact, LiveLaw, August 2026

• CERT-In Directions, 28 April 2022

• OWASP Top 10 for LLM Applications

• AgentRaft: Automated Detection of Data Over-Exposure in LLM Agents, arXiv