Requests from Mine, Privacy Bee and other agent services

A batch of near-identical deletion requests lands in the privacy mailbox overnight, each naming a different person, most of whom you have never heard of. It looks like spam. Usually it isn't: it is a consumer privacy service working through its users' lists, and how you handle it is a matter of law, not taste.

This post covers what these services are, when their requests are legally valid, what you can ask for before acting, how to deal with people you hold no data on, and how to route the volume so it does not swamp your regular queue. It ends with California's Delete Request and Opt-out Platform (DROP), which changes the picture entirely for data brokers.

What these services do

They fall into a few models, and the model tells you what to expect in your inbox:

The common features: requests arrive in batches, use templated text that cites several laws at once ("under the GDPR, CCPA and applicable state law"), frequently concern people who are not your customers, and sometimes come with a portal where the service would like you to respond.

Are they valid requests?

Mostly, yes, though what you must do depends on the law and on who is sending.

When the request comes from the person's own email address, it is simply that person's request, written with help. The tool that drafted it is irrelevant. Treat it like any other.

When the service submits as an agent, the rules differ by law:

• California. Consumers may use an authorized agent, defined as a natural person or business that the consumer has authorized to act for them. For requests to know, delete or correct, you may require proof of the consumer's signed permission, and you may also require the consumer to verify their identity directly with you or confirm directly that they authorized the agent. You may not make the consumer resubmit the request themselves, and you may not require a power of attorney, though if the agent has one under the Probate Code you cannot impose the extra checks (11 CCR 7063). For opt-outs of sale or sharing, you may deny an agent request that comes without the consumer's signed permission (11 CCR 7026(j)).
• Colorado. The statute expressly lets a consumer authorize another person to opt out on their behalf, and the controller must comply if it can authenticate the consumer and the agent's authority with commercially reasonable effort (C.R.S. 6-1-1306).
• Virginia. The rights are exercised by the consumer, or a parent or guardian for a child. There is no general authorized-agent provision (Va. Code 59.1-577). Several later laws on the same template, Connecticut's and Texas's among them, do let an agent act for the consumer at least for opt-outs, so check state by state. Many companies honor agent requests anyway, because confirming with the consumer is cheaper than arguing about it.
• GDPR. The regulation does not address representatives directly, but the EDPB's access guidelines accept requests made through proxies and third-party portals. You must make sure the third party is acting legitimately for the person, verifying authority where suitable and proportionate, and you still have to handle the request in time. You are not obliged to deliver the data through the service's portal if its security is inadequate or another channel is more appropriate; you can send it to the person directly.

The practical rule: don't ignore agent requests because they come from an app. Do apply your agent-verification step, consistently, and document it.

Verification without turning people away

The cheapest verification for agent requests is a direct message to the consumer. If the request names an email address that matches a record, email that address: "We received a request from [service] on your behalf to delete your data. Click here to confirm." This satisfies California's option to have the consumer confirm the agent's authority, and it is proportionate under the GDPR because you are using contact details you already hold.

Points to settle in your procedure:

• The clock keeps running. Under the CCPA, the 45-day response window starts on receipt, regardless of how long verification takes. Send the confirmation request immediately, not at the end of the batch.
• Opt-outs need less. You cannot require a verifiable consumer request for an opt-out of sale or sharing in California (11 CCR 7026(d)). If the agent supplied signed permission, or the request can be matched to a record, act on it.
• Don't ask for more than you need. Requesting ID documents for every agent request will be read as obstruction, and creates a new pile of sensitive data you then have to protect.
• Silence is an answer. If the consumer never confirms and the agent never provides proof, California lets you deny the request on verification grounds within the deadline. Say so in writing, and say why.

Requests from people you have no data on

Broad-sweep services send requests to companies that might hold a user's data, so a large share of a batch can be no-match. Handle these cleanly:

1. Search properly. Check every identifier supplied (email, phone, name plus postal address) against your systems of record, not just the CRM. "We searched and found nothing" is only safe if the search was real.
2. Reply that you found no data. A short, factual response naming the identifiers searched closes an access or deletion request. You do not need to verify identity to tell someone you hold nothing.
3. Log it. California requires records of consumer requests and your responses for at least 24 months (11 CCR 7101). The log entry is the request and the outcome; it should not become a new customer record.
4. Decide on suppression. If the person asked you never to collect or sell their data, you may want to keep a minimal suppression entry so they are filtered out of future list purchases or imports. Virginia's statute and the California regulations both allow keeping a record for the purpose of ensuring data stays deleted; for a no-match, it is a judgment call. Keep it to a hashed identifier where you can.

Routing the volume

Agent requests arrive in waves, and handling them one at a time in the same queue as customer requests makes both worse. A setup that works:

• Separate the intake, not the process. Use a rule or alias that tags messages from known services, so they land in the same system but a distinct view. Every request still gets its own record, due date and audit trail.
• Parse the templates. These services use consistent formats. Extracting the name, email, request type and claimed jurisdiction automatically saves most of the handling time. Many privacy request tools do this; a script on your ticketing system can too.
• Deduplicate. The same person may ask through two services and through your own form. Merge them into one request against the earliest received date.
• Batch the no-match responses after the search, but send each individually to its requester.
• Track by sender. Record which service sent each request. If one service consistently fails to supply authorization or sends requests for people who deny using it, you have the evidence to adjust your verification for that sender.
• Answer by your own channel. If a service asks you to respond through its portal, you can, but you do not have to under the GDPR, and re-keying into third-party portals is how records get out of sync. Reply to the consumer and copy the agent where the law requires a reply to the requester.

The broader workflow, including deadlines and logs, is in the data subject request automation guide and the working guide to handling requests.

Data brokers: California's Delete Act and DROP

If your business meets California's data broker definition, broadly a business that knowingly collects and sells the personal information of consumers it has no direct relationship with, the agent-request problem has been partly replaced by a state-run one. The Delete Act (SB 362) required the California Privacy Protection Agency to build a single deletion mechanism, and it is now live.

According to the agency's guidance for data brokers:

Matching works on hashed identifiers: brokers standardize and hash their own consumer records and compare them with the list. That means a broker's DROP readiness depends on the same identifier hygiene as any other deletion process: normalized emails and phone numbers, and a clear map of which systems hold consumer records. Consumers verify California residency with the agency before submitting, and the regulations let authorized agents help a consumer submit once that residency check is done.

For brokers, DROP does not replace ordinary CCPA requests. A consumer can still write to you directly or through an agent service, and those requests run on the normal 45-day CCPA clock. Treat DROP as a separate, scheduled intake with its own job, owner and log.

For everyone else, DROP is a signal of where things are heading: regulators building central channels that send requests to you in bulk, on a fixed cadence, with status reporting. A request process that can handle a batch from an agent service is most of the way to handling one from a regulator.

Quick answers