#Apple Is Rewriting Consent for AI Agents. The DPDP Act Won't Require the Same Until May 2027

Correction (1 November 2026). An earlier version of this article said the Chairperson and Members of the Data Protection Board of India were appointed in June 2026. That was wrong. On 6 June 2026 MeitY issued a further notice in its call for applications for those posts; it did not appoint anyone, and as of 1 November 2026 no appointments have been made. The affected passage has been corrected.

On 2 October 2026, Apple said it will make macOS harder to hand over wholesale to an AI agent — new controls so that full disk access can only be granted "with very explicit user action." It is the most consequential consent design decision of the year for Indian users, and it was made in Cupertino, because the DPDP Act's own consent provisions do not commence until 13 May 2027.

That is the gap worth understanding. For the next nineteen months, the operative consent layer on an Indian professional's laptop is a settings panel shipped by an American hardware company. Indian law has nothing to say about it yet — and when it finally does, it will ask a question the settings panel was never built to answer.

#What Apple announced, and what provoked it

Apple's statement, reported on 3 October, is unusually blunt about other people's software. "Some developers are using full disk access in ways that could put users at risk," the company said, "exposing everything on their systems — including files, mail, messages, and even browsing history — without users' full knowledge and understanding."

Full Disk Access is the macOS permission that does exactly what it sounds like. It was designed for backup utilities and disk tools: software that legitimately needs to see everything. It is a single toggle, and it is all-or-nothing. Apple's concern is that the class of software now asking for it has changed. "As AI agents become increasingly capable and autonomous," the company said, "the risks associated with this level of access will grow substantially."

Apple has not said which macOS version will carry the change, when it ships, which apps are affected, or whether Apple Intelligence will be held to the same standard — a set of omissions MediaNama flagged in its coverage on 5 October.

The provocation is not in dispute even if the facts are. Meta launched Muse, its autonomous personal AI agent, on 8 September 2026, with a Mac app following on 17 September. Two days later, Inc. columnist Jason Aten wrote that Muse had synced his Mac Messages database — to row 187,462, by his account — and that he had never authorised it. He said he remembered explicitly declining to give Muse access to his messages and calendar. He also said Full Disk Access was switched off, and that Muse did not appear in macOS Security and Privacy settings at all.

Meta denies it. Vice president of communications Andy Stone said Muse "can't read your Messages unless you do this," pointing to two separate opt-ins: Full Disk Access at the operating system level, and a Messages connector inside Muse itself. Business Today reported the exchange on 29 September. It was not Meta's first consent dispute of the year: in July the company pulled Muse Image days after launch when it emerged that the tool was linking users' images to their Instagram accounts without asking.

#Nobody outside the companies can settle this dispute

Here is what makes the Aten episode structurally interesting rather than merely noisy: both accounts may be sincere, and no third party can adjudicate between them.

Aten can see his own settings panel and his own Messages database. He cannot see what Muse requested, what macOS granted, or what was transmitted. Meta can see its server logs. It cannot produce them to a columnist's satisfaction, and it has not. The user holds no record capable of proving the negative. The vendor holds the only records that matter, and discloses them at its discretion.

Under a mature data protection regime, that asymmetry is the regulator's entire reason for existing. The DPDP Act's architecture agrees in principle: Section 8 makes a Data Fiduciary responsible for compliance regardless of any agreement with the Data Principal, and the DPDP Rules, 2025 require fiduciaries to maintain logs and monitor access as part of reasonable security safeguards. A Data Principal who suspected what Aten suspected would, in a functioning system, complain to the Data Protection Board of India, and the Board would ask Meta for the logs.

Except that the complaint mechanism and the consent obligations that would make the complaint meaningful are not yet in force.

#Why Full Disk Access cannot be consent under the DPDP Act

This is the part Indian compliance teams should sit with, because it survives the Aten dispute entirely. Assume Meta is completely right. Assume the user did grant Full Disk Access and did enable the Messages connector, knowingly, in two deliberate steps. That sequence still does not produce valid consent under the DPDP Act.

Section 6 requires that consent be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, and limited to the personal data necessary for the specified purpose. Rule 3 of the DPDP Rules, 2025 builds the notice that must accompany it: an itemised description of the personal data being collected, the specified purpose, and a specific description of the goods, services or uses that the processing enables. A link to a general privacy policy does not satisfy Rule 3. The notice must stand on its own.

Full Disk Access is the categorical opposite of an itemised description. It is a capability grant, not a purpose grant. The user is not told which files will be read, when, for what, or how often — because the permission model does not know. It cannot know. "Everything on this disk, indefinitely, for whatever the agent decides it needs" is not a specified purpose, and no amount of explicit clicking converts it into one.

This is the same purpose-limitation problem European regulators have been circling. The Dutch data protection authority warned in February 2026 that highly autonomous agents with broad system access create serious data protection risks, and the standing GDPR position is that a blanket "we use AI" acknowledgement does not substitute for specific consent to each distinct processing purpose. India's Section 6 language is, if anything, stricter on necessity than Article 6 GDPR. The difference is not in the standard. It is in the date it starts applying.

Apple's fix — more friction, more explicit action — makes the grant harder to give accidentally. It does not make the grant purpose-specific. A more deliberate click on an unlimited permission is still an unlimited permission. If Indian organisations read Apple's change as solving the DPDP problem, they will have misread it.

#The DPDP Act's consent clock runs to 13 May 2027

The commencement schedule is worth stating plainly, because it is routinely compressed in summaries.

The DPDP Rules, 2025 were notified on 13 November 2025. Rule 4, which switches on Consent Manager registration with the Data Protection Board, commences on 13 November 2026 — about five weeks from now. That date creates a registration route for entities that want to operate as Consent Managers, subject to incorporation in India, a ₹2 crore minimum net worth and demonstrated interoperable technical capability. It does not impose a new obligation on an ordinary Data Fiduciary, and it does nothing about laptop permissions.

The substantive consent and notice machinery — Section 6, Rule 3, and the surrounding obligations — commences on 13 May 2027, eighteen months after notification. Until then, a company processing an Indian user's personal data owes no enforceable Rule 3 notice.

The enforcement apparatus is not in place either. The Data Protection Board has existed in statute since November 2025, but no Chairperson or Members have been appointed: MeitY's calls for applications in May and June 2026, run through a Search-cum-Selection Committee chaired by the Cabinet Secretary, have not produced an appointment, and on 7 October the Union told the Kerala High Court the Board is "not yet functional". Once staffed, the Board can impose penalties up to ₹250 crore. For now, both the obligations and the regulator are pending.

So the honest description of the current position is this: India has a constituted privacy regulator, a notified rulebook, and — for consent on a personal device — nineteen more months of nothing to enforce.

#Muse is not available in India. Section 3(b) still reaches it.

An obvious objection: Muse never launched here. MediaNama confirmed in September that the rollout covered the United States, on iOS, Android and muse.ai, with India excluded and no announced timeline. Meta's chief AI officer said at Connect on 23 September that Muse would reach more countries, naming none.

That objection is weaker than it looks, for three reasons.

First, Section 3(b) of the DPDP Act applies to processing of personal data outside India where that processing is connected to offering goods or services to Data Principals in India. The test is whether the offering is directed at people in India — not where the company is incorporated, not where the servers sit. The day Muse opens to Indian users, the full weight of the Act attaches to it, including whatever consent architecture it shipped with in a market that did not require one.

Second, Muse is not the category. It is one entrant in it. Agentic assistants that request broad local-device access are shipping across the industry, and Indian enterprises are already deploying them on managed fleets. The permission model Apple is revising is the one every such agent on macOS must traverse.

Third, and most immediately: an Indian employee's work laptop frequently holds the personal data of Indian Data Principals who are not the employee. Which leads to the harder problem.

#The people in your Messages database never agreed to anything

A Messages database is not a record of one person. It is a record of a conversation, and every counterparty in it is a Data Principal with rights under the DPDP Act — phone numbers, names, photographs, attachments, locations, the contents of what they wrote.

No operating system permission dialog can obtain their consent, because they are not present when it is shown. The user consents on their own behalf. The permission grants access to everyone else's data as a side effect of the file format.

The DPDP Act handles the individual's own copy reasonably well: Section 3(c)(i) exempts processing for personal or domestic purposes, so a person storing their own correspondence is not a Data Fiduciary. That exemption attaches to the individual. It does not travel to a commercial vendor that ingests the same database into its own systems to train, index or act on. Once Meta — or any agent vendor — determines the purposes and means of processing that data, it is a Data Fiduciary for every third party in the thread, and it holds consent from none of them.

For an Indian organisation the exposure is sharper still, because the employee's device is not covered by the domestic exemption at all when it holds customer records, CVs, deal documents or support transcripts. Grant an agent full disk access on that machine and the employer has, in substance, disclosed a corpus of Data Principals' personal data to a third-party processor it has not assessed, under terms it has not negotiated, for purposes it cannot enumerate. After May 2027, that is a Section 8 security-safeguards problem and a Rule 3 notice problem simultaneously.

#Who is the fiduciary when an agent reads your laptop?

The role allocation matters because almost every obligation in the Act sits on the fiduciary.

A Data Processor acts only on a fiduciary's instructions and makes no independent decisions about purpose or means. An autonomous agent that decides which local sources to read, when to read them, what to retain and what to infer is not operating on anyone's itemised instruction. The vendor that built that decision logic is determining the means of processing — and in the case of an agent that indexes a Messages database to improve its own responses, the purpose too.

Vendors will prefer the processor characterisation. The statutory test does not care about preference: a processor that starts making decisions about purpose or means becomes a fiduciary, with notice, consent and accountability obligations attaching directly. Indian enterprises signing agentic AI contracts over the next eighteen months should assume the vendor is a fiduciary in its own right for anything it reads off a device, and should refuse paperwork that assumes otherwise.

#What to do before May 2027

The DPDP consent rules are not in force. The procurement decisions that will determine whether you can comply with them are being made now, and most of them are hard to unwind.

• Inventory what has full disk access today. On managed macOS and Windows fleets, enumerate every application holding broad local access and name an owner for each. Most organisations have never run this audit and are surprised by the result.
• Deny broad local-device access by default. Use MDM to block the permission class outright and grant exceptions on a documented case-by-case basis. This is cheap now and expensive to retrofit.
• Treat agent vendors as data fiduciaries in contract. Demand purpose enumeration, retention limits, log access on request, and a commitment to produce access records to you and to the Board. A vendor that cannot tell you which local sources its agent reads cannot help you write a Rule 3 notice later.
• Map the third-party data. Identify which device-resident stores — mail, messages, CRM caches, shared drives — contain personal data of people who are not your employee. Those are the ones that will not be curable by consent.
• Design consent capture for purposes, not capabilities. The notice you will owe from 13 May 2027 is itemised and purpose-bound. If your consent architecture records "user approved AI assistant," it will not survive contact with Rule 3. Our consent manager guidance covers what a purpose-level consent record needs to contain, and the broader commencement timeline is laid out in our resources.

#The point

Apple is doing something sensible about a permission model that predates autonomous software. But a platform vendor tightening a toggle is product design, not data protection law, and it is accountable to nobody in India. It can be changed, narrowed or reversed in a release note.

India's answer arrives on 13 May 2027, and when it does it will ask a question that is genuinely harder than the one Apple is answering: not did the user click deliberately enough, but was the data limited to what this specified purpose required. An all-or-nothing disk permission cannot satisfy that standard however carefully it is granted. The organisations that understand this now will spend the next nineteen months rebuilding how they capture consent. The ones that read Apple's announcement as the fix will spend them accumulating a permission estate they cannot document.

The agents are already on the laptops. The law arrives in nineteen months. Only one of those timelines is still adjustable.