GDPR Compliance for AI Email Agents: Setting Retention and Erasure

When you deploy an AI agent to read and reply to emails, the mailbox it uses accumulates personal data: customer names, addresses, order histories, support complaints. That's not a problem in a demo, but the moment a real person's information lands in that inbox, you've taken on legal obligations under regulations like GDPR.

Why This Matters Right Now (July 2026)

Data protection is no longer optional. Organizations handling customer email are under increasing pressure to prove they have defensible retention policies and can actually delete someone's data when asked. Most AI email demos skip this entirely — the agent reads, files things away, and the inbox just grows. That works fine until a compliance officer or a customer's lawyer asks: "How do you delete my data?" If your answer is "we kept everything forever," you're in trouble.

What Makes an Agent Mailbox Different

An Agent Account is a mailbox the AI model owns — like [email protected] answering to a model instead of a human. Every inbound message lands in it, and because it holds real people's personal data, that data needs two things under GDPR: a documented retention window so it doesn't live forever, and a proven erasure path so you can delete a specific person's messages when they request it.

The good news: the API primitives you'd use anyway — listing, reading, and deleting mail — work exactly the same way they do for regular Nylas integrations. What's new is the control-plane retention policy that sets how long mail survives automatically, and the data-plane erasure operation that deletes one person's data on demand.

These two layers answer different questions. Retention answers "how long do we keep anything?" — a blanket time bound. Erasure answers "delete this person's data, now" — a targeted request. A compliant agent mailbox needs both; one doesn't substitute for the other.

Understanding the Two Layers

Retention is a control-plane setting that lives on a policy — an application-scoped resource that bundles limits and spam settings — attached to the workspace your Agent Account belongs to. Two fields cap how long mail survives:

• limit_inbox_retention_period — days a message stays in the inbox before the platform deletes it automatically.
• limit_spam_retention_period — days a message stays in spam before deletion.

Set these once, and the platform enforces them for you with no cron job on your side. Every account in that workspace inherits the windows.

Erasure is a data-plane operation. To honor a right-to-erasure request for one person, you find their messages filtered by sender, then hard-delete each one. A plain delete only trashes the message (recoverable); a hard delete is true erasure.

One important caveat: the API can delete the message from the mailbox. Any derived copy you made — rows in your database, lines in your application logs, embeddings in a vector store — is yours to purge separately. The Nylas deletion doesn't reach into your Postgres.

Setting Retention Windows on a Policy

On the free plan, retention defaults to 30 days in the inbox and 7 days in spam, and those defaults aren't configurable. Paid plans let you set your own windows. Either way, pick windows that match your documented retention schedule — the number you'd write down for an auditor, not a number you guessed.

Step 1: Create a retention policy

Using curl:

curl --request POST \
  --url "https://api.us.nylas.com/v3/policies" \
  --header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Support Agent Retention Policy",
    "limits": {
      "limit_inbox_retention_period": 365,
      "limit_spam_retention_period": 30
    }
  }'

Or using the Nylas CLI:

nylas agent policy create --data '{
  "name": "Support Agent Retention Policy",
  "limits": {
    "limit_inbox_retention_period": 365,
    "limit_spam_retention_period": 30
  }
}'

Both return a policy_id. Hold onto it — a policy does nothing on its own until a workspace points at it.

Step 2: Attach the policy to your workspace

Your Agent Account auto-creates a default workspace when it's provisioned. Attach the policy to that workspace so every account in it inherits the retention windows.

Using curl:

curl --request PATCH \
  --url "https://api.us.nylas.com/v3/workspaces/REPLACE_WITH_WORKSPACE_ID" \
  --header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "policy_id": "REPLACE_WITH_POLICY_ID"
  }'

Or using the CLI:

nylas workspace update REPLACE_WITH_WORKSPACE_ID --policy-id REPLACE_WITH_POLICY_ID

That's the complete retention story on the platform side. From here, Nylas enforces the windows itself — there's no scheduled job for you to write, monitor, or troubleshoot.

Building the Erasure Path

Retention handles the passive case: mail aging out on a schedule. Erasure handles the active case: when someone asks you to delete their data, you delete it.

To delete a specific person's messages, find their mail by sender address, then hard-delete each one:

curl --request DELETE \
  --url "https://api.us.nylas.com/v3/grants/REPLACE_WITH_GRANT_ID/messages/REPLACE_WITH_MESSAGE_ID?hard_delete=true" \
  --header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY"

For a full identity wipe — deleting the grant itself — use:

curl --request DELETE \
  --url "https://api.us.nylas.com/v3/grants/REPLACE_WITH_GRANT_ID" \
  --header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY"

The hard_delete=true parameter is critical. Without it, you're only moving the message to trash — not truly erasing it.

Why the Split Matters

Separating retention (control-plane) from erasure (data-plane) forces you to think about two different problems. Retention is a blanket time bound you set once and forget. Erasure is the workflow you build to respond to individual requests. Both are necessary. A mailbox with a retention window but no erasure path can still refuse to delete someone's data when they ask. A mailbox with erasure but no retention window can hold messages forever if no one asks for deletion.

Conclusion

Building a compliant agent mailbox means treating data protection as infrastructure, not an afterthought. Nylas handles retention automatically once you set a policy; erasure requires you to have a documented process to find and delete someone's messages when they ask. The two together let you prove to a regulator — or a lawyer — that you have both a time bound and a deletion path. In 2026, that's table stakes for any AI agent that touches real email.

Merits

• Retention is enforced by the platform, not by your scheduled jobs — no risk of the cron failing silently.
• Two separate layers (retention and erasure) cleanly separate "blanket time bounds" from "delete this person's data."
• The API is identical to regular Nylas integrations — no new concepts to learn.
• Free plan has a built-in 30-day inbox default, so even demos have some protection.
• Paid plans are fully configurable, letting you match your legal team's retention schedule.
• Attaching a policy is a one-time action; updating the retention window automatically applies to all accounts in the workspace.

Demerits

• The API deletes only messages in the mailbox, not copies in your own database, logs, or vector stores — you must track and purge those separately.
• Free plan retention is fixed at 30 days inbox and 7 days spam, so it may not match your compliance needs.
• Erasure is a manual data-plane operation, not automatic — you must build the workflow to receive and honor deletion requests.
• A workspace with no policy attached runs accounts at your plan's default limits, which on a paid plan can mean no retention bound at all.
• The platform enforces the retention windows, but you remain responsible for proving compliance if audited.

Caution

This article is educational and explains the Nylas API as documented. It is not legal advice. Before implementing retention and erasure in production, verify that the retention windows you choose (for example, 365 days) match your documented compliance policy and your legal team's requirements. Replace all placeholder values (REPLACE_WITH_NYLAS_API_KEY, REPLACE_WITH_WORKSPACE_ID, REPLACE_WITH_POLICY_ID, REPLACE_WITH_GRANT_ID, REPLACE_WITH_MESSAGE_ID) with your actual values before running any commands. Consult the official Nylas documentation and your organization's legal or compliance team before relying on this guidance.

Frequently asked questions

What's the difference between a plain delete and a hard delete? — A plain delete moves the message to trash, where it can be recovered. A hard delete (?hard_delete=true) is true erasure and cannot be undone.

Do I need to set a retention policy even if I'm on the free plan? — No, the free plan has a built-in 30-day inbox retention and 7-day spam retention by default. If those windows match your needs, you don't need to set a policy. Paid plans require you to configure retention explicitly.

Can Nylas delete data I've already copied into my database? — No. The Nylas API deletes only messages in the mailbox. Any derived copies — database rows, logs, or embeddings — are your responsibility to purge.

What happens if I attach a policy with a retention window shorter than the spam window? — The API will reject it. The spam retention period must be shorter than the inbox retention period so spam clears out ahead of legitimate mail.

Do all accounts in a workspace inherit the same retention policy? — Yes. Every Agent Account in a workspace inherits the retention windows from the policy attached to that workspace.

What if I need to change the retention window later? — Simply PATCH the policy to change the windows. All accounts in that workspace will follow the new schedule immediately.

Can I delete a specific message without hard-deleting it? — Yes, but a plain delete only moves it to trash. To truly erase it (making it irrecoverable), use the ?hard_delete=true parameter.

Is there a way to automate the erasure process? — The API supports automated deletion, but according to the platform, you would build your own workflow to receive deletion requests and call the hard-delete endpoint for each message.

Tags

#gdpr #email #dataprotection #compliance #retention #api #erasure #agentmail