Reactive to the inbox, schedule-driven, and strictly compile-and-flag — nothing this skill does is reversible-risk, because it never writes to the subject's actual data.

Step 1 — Scan the inbox for DSARs

Search Gmail for new or unhandled data subject requests:

Look for messages that reference access, deletion, erasure, "my data," or GDPR/data-subject rights, in the legal/privacy inbox.
Skip any thread already labeled as actioned by this agent (e.g. dsar-compiled or dsar-flagged) — a fresh session must not reprocess a request that's already sitting with legal.
For each new thread, capture: requester name and email, what's being requested (access, deletion, or both), any identity details supplied, and the date the request arrived.

Step 2 — Verify the requester

Before touching any product data:

Match the requester's email and any supplied identity details (full name, account email, order or account ID) against the account records we hold.
Treat a request as verified only when the identifying details line up with a single, unambiguous account.
If the match is weak, ambiguous, or the request supplies no verifiable detail, do not proceed to Step 3. Compile a short note explaining what's missing and flag it to {{legal_review_channel}} as unverified — legal (or a follow-up request) decides how to proceed.
Record the verification date — it starts the SLA clock.

Step 3 — Locate the subject's data (read-only)

For a verified request, query Postgres read-only across every table that can be keyed to the subject, for example:

sql

-- adapt table/column names to the actual schema
select * from users where id = :subject_id;
select * from orders where user_id = :subject_id;
select * from invoices where user_id = :subject_id;
select * from support_tickets where user_id = :subject_id;
select * from consent_records where user_id = :subject_id;
select * from login_history where user_id = :subject_id;

Follow foreign keys outward until every table that stores something identifiable to this person has been checked — a partial search is not acceptable.
Never issue anything but a read query. There is no delete or update path in this workflow, regardless of what the request asks for.
If a table can't be reached or a query fails, note it explicitly in the report rather than silently omitting that source.

Step 4 — Compile the report

Create a new Google Doc (one per request), formatted as:

Header — requester name/email, request type (access / deletion / both), date received, date verified, SLA deadline (verified date + {{sla_days}} days).
Data inventory — one section per system/table, listing what was found verbatim or summarized (large tables like login history can be summarized with counts and date ranges instead of every row).
Recommended action — fulfill the access request as compiled, or proceed with deletion across the listed tables, with any caveats (e.g. records legal must retain for a legal-hold or billing-compliance reason).
Verification notes — how identity was confirmed.

Step 5 — Flag to legal and label the thread

Post the Doc link, the requester's name, the request type, the SLA deadline, and the recommended action to {{legal_review_channel}}.
Label the Gmail thread as actioned (dsar-compiled, or dsar-flagged if verification failed) so the next day's sweep doesn't reprocess it.
Stop here. Do not reply to the requester, do not run any deletion, and do not mark the request as resolved — that's legal's call.

DSAR fulfillment

Step 1 — Scan the inbox for DSARs

Step 2 — Verify the requester

Step 3 — Locate the subject's data (read-only)

Step 4 — Compile the report

Step 5 — Flag to legal and label the thread

Related skills