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:
  1. Header — requester name/email, request type (access / deletion / both), date received, date verified, SLA deadline (verified date + {{sla_days}} days).
  2. 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).
  3. 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).
  4. 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 — Kortix Marketplace | Kortix