Build consent, withdrawal, grievance, erasure, and audit workflows for regulated AI agent deployments. Structured consent records, purpose limitation, right to withdrawal, and audit-ready exports — built into the Grantex protocol.
Grantex connects authorization events to structured compliance evidence. Legal review and organizational controls remain your responsibility.
Organizations using AI agents to process digital personal data may need consent, purpose, retention, rights, and grievance workflows under the DPDP Act.
EU AI Act obligations apply in phases and vary by system classification and role. Use Grantex records as technical evidence within a broader assessment.
An industry threat taxonomy for agentic systems, published in December 2025. Authorization infrastructure can mitigate parts of four mapped risk areas; it is not complete protection.
Applications can create a DPDPConsentRecord alongside an authorization and retain the purpose, notice version, legal basis, and lifecycle events for later review.
import { Grantex } from '@grantex/sdk'; const grantex = new Grantex({ apiKey: process.env.GRANTEX_API_KEY!, }); const purposes = [{ code: 'calendar:read', description: 'Read calendar events for scheduling', }]; const notice = await grantex.dpdp.createConsentNotice({ noticeId: 'calendar-access', version: '1.0', title: 'Calendar access notice', content: 'This agent reads calendar events for scheduling.', purposes, }); const consent = await grantex.dpdp.createConsentRecord({ grantId: 'grnt_01J...', dataPrincipalId: 'user_123', purposes, consentNoticeId: notice.noticeId, processingExpiresAt: new Date('2026-12-31').toISOString(), }); console.log(consent.recordId, consent.status);
Each record links a data principal and grant to stored purposes, scopes, a notice identifier and hash, processing dates, and lifecycle status.
Purpose codes and descriptions are stored with the consent record. Applications remain responsible for mapping those purposes to grant scopes and enforcing use.
The authenticated withdrawal endpoint changes record status. API callers can also request underlying-grant revocation; local JWT consumers still need current revocation state.
The principal-records endpoint returns stored consent records. Export requests can include selected consent and audit rows, but do not determine legal completeness.
The notice API stores versioned content and a hash, while consent records reference the notice. That supports comparison during review but does not itself prove presentation.
Inspect tenant-level grant, policy, audit, and consent data in the authenticated dashboard. The screen below is an illustrative mockup with sample values, not live customer data or a compliance score.
| Agent | Principal | Purposes | Status | Granted |
|---|---|---|---|---|
| calendar-assistant | r***@***.com | calendar:read, calendar:write | Active | 2026-04-01 |
| email-summarizer | p***@***.com | email:read | Active | 2026-03-28 |
| doc-analyzer | a***@***.com | files:read, files:analyze | Withdrawn | 2026-03-15 |
| hr-assistant | d***@***.com | employee:read, payroll:view | Active | 2026-03-10 |
| travel-planner | v***@***.com | calendar:read, travel:book | Expired | 2026-02-20 |
The authenticated dashboard lets operators look up stored consent records and withdraw a record. A separate end-user self-service portal and correction workflow are not currently implemented.
Search by data principal ID to retrieve stored purposes, scopes, status, processing expiry, retention date, and withdrawal metadata.
The dashboard calls the consent-withdrawal endpoint. Revoking the underlying grant is a separate optional API behavior and is not implied by local JWT verification.
Review access counts, last-access timestamps, processing dates, and withdrawal metadata returned with each consent record.
Request selected consent and audit records by date range, export type, and optional data principal ID for downstream review.
Authenticated operators can submit a grievance and retrieve its status by ID. Automated DPO or regulator routing is not currently implemented.
Selected operational requirements have corresponding Grantex features. Organizations must validate the mapping and complete their own legal and manual processes.
| DPDP Section | Obligation | Grantex Feature |
|---|---|---|
| Section 4 | Lawful purpose — personal data shall be processed only for a lawful purpose | Purpose-tagged consent records plus application-level JWT scope checks |
| Section 5 | Notice — data fiduciary must give notice before processing | Versioned consent-notice API; consent records link the notice ID and content hash |
| Section 6 | Consent — processing based on free, specific, informed consent | Structured consent records linked to grants, purposes, scopes, and processing dates |
| Section 6(6) | Withdrawal — consent withdrawal must be as easy as granting | Authenticated withdrawal endpoint; optional underlying-grant revocation when requested through the API |
| Section 8 | Data fiduciary obligations — accuracy, storage limitation, security | Processing-expiry and retention-date fields; deployments remain responsible for deletion and infrastructure controls |
| Section 8(7) | Grievance redressal — data fiduciary must have a grievance mechanism | Authenticated grievance submission and status retrieval with an expected-resolution date |
| Section 9 | Children's data — additional protections for minors | No dedicated child-data or guardian-consent workflow is currently implemented |
| Section 11 | Data principal rights — access, correction, erasure, portability | API retrieval of consent records plus an erasure-request workflow; no correction endpoint is currently implemented |
| Section 13 | Grievance mechanism — respond within prescribed period | Grievance status and expected-resolution dates; regulator escalation remains an organizational process |
| Section 16 | Cross-border transfer — restrictions on data transfer outside India | No dedicated cross-border-transfer or data-residency enforcement is currently implemented |
| Section 17 | Data Protection Board — regulatory oversight and penalties | JSON export of selected consent, grievance, and audit records for downstream review |
Request selected consent, grievance, and audit records by date range and export type. The result is technical evidence, not a legal filing, conformity report, or certification.
Returns selected consent records, audit entries, and DPDP grievance summaries in a JSON-backed export record for downstream review.
Uses the gdpr-article-15 export type and can filter stored consent
and audit records by data principal ID. Completeness still requires review.
Uses the eu-ai-act-conformance request type to package selected
consent and audit records. It does not generate an article mapping or conformity decision.
import { requestDpdpExport, requestGdprExport } from '@grantex/dpdp'; const apiKey = process.env.GRANTEX_API_KEY!; const options = { dateFrom: new Date('2026-01-01'), dateTo: new Date('2026-04-01'), format: 'json' as const, includeActionLog: true, includeConsentRecords: true, }; const pack = await requestDpdpExport( options, apiKey, 'https://api.grantex.dev' ); const gdprPack = await requestGdprExport( { ...options, dataPrincipalId: 'user_123' }, apiKey, 'https://api.grantex.dev' );
Regulatory applicability and timelines depend on your deployment and jurisdiction. Grantex supplies technical evidence controls; it is not legal advice or certification.
npm install @grantex/dpdp
Copy
pip install grantex-dpdp
Copy