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.