DPDP MCP Checklist
Use this DPDP checklist for MCP server privacy design, PII minimization, consent, retention, and audit logs.
Quick Answer / TL;DR
A DPDP MCP checklist should cover data mapping, purpose limitation, consent or notice, PII redaction, access control, audit logs, retention, breach process, and vendor review.
Key Takeaways
- Start with data inventory.
- Use deny-by-default tools.
- Review logs for sensitive leakage.
Checklist overview
Run this checklist before connecting an MCP server to customer, employee, healthcare, education, or financial data.
| Item | Ready signal |
|---|---|
| Data inventory | Every tool lists fields accessed |
| Purpose | Each tool has a business purpose |
| Redaction | Sensitive identifiers masked |
| Retention | Logs have expiry policy |
| Incident response | Breach workflow documented |
Data localization (Section 18)
Host the MCP server and the databases it queries within Indian geographic boundaries, for example AWS Mumbai (ap-south-1), Azure Pune, or GCP Delhi.
Make sure no fallback routing, third-party logging service, or CDN edge cache stores personal data outside India, and get written confirmation of Indian data residency from any managed MCP hosting provider you use.
Consent and purpose limitation (Sections 6 and 7)
The application invoking the MCP server should capture explicit, granular consent before an AI agent accesses personal data, and every tool should be scoped strictly to that consented purpose.
For example, an agent consented to read transaction history should not also have access to a tool that updates a user's profile. Design tools to return only the minimum data needed and avoid unscoped select-all patterns.
Immutable audit logging (Sections 8 and 9)
Every tool invocation should generate an audit log entry that cannot be altered or deleted by the agent or a standard user. At minimum, capture a timestamp, agent identifier, hashed user identifier, tool name, action type, compliance status, and the data elements accessed.
interface MCPAuditLog {
timestamp: string; // ISO 8601
agent_id: string;
user_id_hashed: string; // hashed, never raw PII
tool_name: string;
action: "read" | "write";
compliance_status: "approved" | "blocked";
data_elements_accessed: string[];
}Security, access control, and data principal rights (Sections 11 to 13)
Require authentication such as mTLS, JWT, or API keys for any non-stdio connection, default database roles to read-only unless a specific audited write is required, and validate all tool arguments against strict schemas to block prompt injection or SQL injection.
You must also be able to answer a data principal's right-to-access request by querying MCP audit logs, and be able to purge any cached data or temporary files the server generated upon a valid erasure request.
server.setRequestHandler(CallToolRequestSchema, async (request) => {
const { name, arguments: args } = request.params;
const userId = request.params.metadata?.userId;
if (name === "get_user_financial_data") {
const hasConsent = await checkConsentRegistry(userId, "financial_access");
if (!hasConsent) {
return { content: [{ type: "text", text: "Error: consent not found." }], isError: true };
}
const data = await db.query(
"SELECT account_type, last_login FROM users WHERE id = $1",
[userId]
);
await auditLogger.log({ userIdHashed: hash(userId), tool_name: name, compliance_status: "approved" });
return { content: [{ type: "text", text: JSON.stringify(data) }] };
}
});DPDP MCP Checklist FAQs
Direct answers for developers, operators, and Indian teams evaluating MCP.