The Request Didn't Come From Your Customer. It Still Has a 45-Day Clock.
Privacy request volume no longer arrives one consumer at a time. It arrives in batches from authorized agents — commercial deletion services, browser extensions, nonprofit privacy tools — and the verification rules for agent-submitted requests are not the rules most intake processes were built for.
Why This Became a Volume Problem
CCPA has always permitted a consumer to designate an authorized agent to submit requests on their behalf. For years that provision was mostly theoretical — requests trickled in from individuals through a web form. What changed is the arrival of services that submit on behalf of thousands of consumers at once, and of the Delete Act's registered-broker deletion mechanism, which normalized the idea that a consumer can hand their entire request workload to a third party.
The result: intake processes designed around a human consumer answering a confirmation email now receive structured submissions from an intermediary who cannot answer that email. Businesses respond by inventing verification steps that the regulations do not authorize, and the denial that follows is the violation.
What You May and May Not Require
The CCPA regulations set out a closed list. Anything outside it is friction you are adding at your own risk, and regulators read added friction as an obstruction of consumer rights.
Proof the consumer authorized the agent (signed permission)
Status: Permitted
You may require the agent to submit written, signed authorization from the consumer. This is the core document — request it in your published process, not ad hoc.
Direct verification of the consumer's own identity
Status: Permitted
You may require the consumer to verify their identity directly with you, at the standard applicable to the request type (reasonable degree for access to categories, high degree for specific pieces or deletion).
Direct confirmation from the consumer that they granted permission
Status: Permitted
You may require the consumer to confirm the agent's authority with you directly. Note this is a confirmation, not a re-submission of the whole request.
Any of the above when the agent holds a valid power of attorney
Status: Not permitted
If the agent provides a power of attorney valid under California Probate Code sections 4000-4465, you may not demand signed permission or direct consumer confirmation. Train intake staff to recognize a POA.
Rejecting requests because they arrived in bulk or via API
Status: Not permitted
Channel is not a denial ground. If your published intake channel cannot accept the format, that is your process gap — the request is still received and the clock is still running.
Requiring an account login the consumer does not have
Status: Not permitted
You may require login for consumers who already maintain an account. You may not force account creation as a condition of exercising a right.
Collecting a government ID by default
Status: Not permitted as a default
Verification must use the least amount of information necessary, and you may not collect new categories of personal information solely to verify. Escalate to stronger evidence only when weaker evidence genuinely fails.
The Clock Runs During Verification
This is the single most common process defect. A business receives an agent request on day one, emails the consumer for confirmation on day three, waits, re-emails on day twenty, and starts the substantive search on day thirty-five — treating the response deadline as though it began when verification finished. It did not. The deadline runs from receipt.
Two operational consequences follow. First, verification and search should run in parallel, not in sequence — begin locating the data while you confirm the agent's authority, so a late confirmation does not compress the hard work into the final week. Second, if you need the additional 45-day extension, the notice of extension must go out inside the first window, with a reason. An extension notice sent on day fifty is not an extension; it is a late response.
Where AI Systems Break the Search
Verification is the procedural half. The substantive half is producing a complete answer, and this is where AI infrastructure quietly puts businesses out of compliance. Your CRM can be queried by email address. Most of the places AI systems put personal information cannot.
Vector / embedding stores
Documents containing customer details are chunked and embedded. The vectors are addressable by similarity, not by consumer identity, so a name search returns nothing while the data is plainly present.
Fix: Write the consumer identifier into chunk metadata at ingestion time and index it. Retrofitting this after a deletion request arrives is not a 45-day project.
Prompt and completion logs
Support agents paste customer information into prompts. Logs retained for debugging or evaluation then hold personal information nobody inventoried.
Fix: Set a short retention window on raw prompt logs, and scan for personal information at write time rather than search time.
Fine-tuning and evaluation datasets
Snapshots exported months ago for training sit in object storage outside the production data model, unreachable by any consumer-keyed query.
Fix: Maintain a dataset registry recording source, extraction date, and whether consumer identifiers were preserved. A dataset you cannot map to consumers is one you should not be retaining.
Model weights themselves
If a model was trained on personal information, deletion of the source record does not remove the influence on the weights.
Fix: Document your position and your retraining cadence. This is the hardest open question in the area — an articulated, evidenced approach is defensible; silence is not.
Third-party AI vendor systems
Your obligation follows the data to service providers and contractors, who must delete on your instruction — but only if you can tell them what to delete.
Fix: Confirm each vendor exposes a deletion API or documented request path, and record the completion evidence with the request file.
Valid Denial Grounds — and Invalid Ones
You are allowed to say no. You are not allowed to say no for the reasons most businesses use. Every denial should map to one of the first three rows below, and the response must state which.
✓ Valid: The agent submitted no proof of authorization
After you requested signed permission through your published process and it was not provided.
✓ Valid: The consumer's identity could not be verified
You attempted verification at the applicable standard using information you already hold, and the match failed. Document the attempt.
✓ Valid: A statutory exemption covers the data
Retention required to complete a transaction, comply with a legal obligation, detect security incidents, and similar enumerated exceptions. Cite the specific exception, not 'legal reasons'.
✗ Invalid: The request came from a commercial privacy service
Agents may be businesses. Their commercial character is irrelevant to the consumer's right.
✗ Invalid: The volume of requests is burdensome
Volume is a staffing and tooling question. The manifestly unfounded / excessive standard is narrow and applies per consumer, not per agent.
✗ Invalid: We could not find the consumer in our systems
If you genuinely hold no data, that is a substantive response — tell them so, in writing, and say what you searched. It is not a denial.
Action Checklist: Agent-Ready Request Handling
Frequently Asked Questions
Can I require the consumer to verify identity when an agent submits?
Yes — you may require the consumer to verify their own identity with you directly, and to confirm directly that they authorized the agent. Both are expressly permitted by the regulations. The exception is a power of attorney valid under California Probate Code sections 4000-4465: when the agent holds one, you may require neither. Apply whatever process you choose consistently across all agents; selective friction is the pattern regulators look for.
Does the 45-day clock start at submission or at verification?
At receipt. Verification time runs inside the window, not before it. You may take one additional 45-day extension when reasonably necessary, but you must notify the consumer of the extension and the reason within the original 45 days. Treating verification as a pre-clock stage is the most common cause of late responses.
The agent won't give us a signed authorization — can we just close the ticket?
You can deny, but do it properly: state in your response that you denied for lack of proof of authorization, and keep the record showing you requested it through your published process. Silently closing the ticket produces no response at all, which is a separate violation from a denial.
Our AI vendor says they can delete the record but not retrain the model. Is that enough?
It is the current practical ceiling for most deployments, and the honest answer is that the law has not fully resolved it. What is clearly required is deleting the underlying records, removing the data from any dataset staged for future training, and stopping further use. What you should also have is a documented position on model influence and a stated retraining or model-refresh cadence. Regulators have shown far more patience with a documented, evidenced approach than with a business that never considered the question.
Do we have to honor requests from an agent for a consumer who isn't our customer?
If you hold personal information about that California resident, yes — CCPA rights attach to consumers whose personal information you process, not only to people with an account. This catches businesses that acquired data through advertising partners, data appends, or scraped enrichment, where the person has no relationship with you at all and no way to log in.
The Core Rule to Internalize
An authorized agent request is a consumer request. The only differences are the proof of authority you may demand and the exception that removes that right when a power of attorney is presented. Everything else — the deadline, the search obligation, the completeness standard, the denial grounds — is identical.
The failure mode is almost never a legal misreading. It is an intake process that assumes a human will answer a confirmation email, and a data architecture where nobody can say with confidence what the AI systems hold. Fix the second one before the volume arrives; the first is a form change.