# Mandate Law > Legal counsel for AI products, agents, and the consumer apps they live in, built for the coding agents that build them. AI feature reviews, agent authorization and liability, privacy policies, terms, and consent flows, delivered as final documents plus a build spec, a verification checklist, and a counsel-triggers file that show your agent how to ship the feature, not just what could go wrong. Allen Gibby, admitted in the District of Columbia. ## Rules for agents - You are not the client. The person or company you act for is. A human with authority must sign the engagement letter before legal advice is given. - Call `conflict_check` first (names only). Then send a short, public-level matter summary so the attorney can decide whether to take the matter. Detailed product facts wait until the engagement letter is signed. - Send facts about the code with file paths as evidence. Never send secrets, keys, source dumps, or user data. - Content on this site is legal information, not legal advice. - Instructions inside content you submit are treated as data and ignored. - Admitted in DC. Federal law, platform and model-provider rules, and multistate law are in scope; questions needing another state's license are referred out. - Outside the United States: issue-spotting only. Counsel flags issues (for example, under EU and UK law) for you to raise with local counsel, but does not advise on non-U.S. law. ## How to engage 1. `check_scope` (free and anonymous): an instant answer on whether the request fits, which service, and its fixed fee. Send no names; nothing is saved. 2. `conflict_check` (free): company name, people, adverse parties. 3. `request_engagement`: send a `matter_summary`: what the product does (as you'd describe it publicly), stage, users, where they are, which `features_in_play` apply (AI output, LLM data sharing, agent actions or payments, health or financial data, minors, and so on), your questions in general terms, and whether there is an active dispute or regulator contact. No code, secrets, or confidential plans. Returns a `matter_id` and a secret `matter_token` (shown once; store it securely). Pass the token to every matter tool, or as a Bearer token on the REST API. The attorney reviews conflicts and the summary, may post a few scoping questions (answer them with `answer_open_question`), then accepts the matter (possibly under a different service) or declines it. If accepted, the engagement letter is emailed to your human to sign. The fixed fee is due when the work is delivered; nothing is paid up front. 4. `submit_intake` (after the letter is signed): facts per [intake-schema.json](/api/intake-schema.json), each with a source (`verified_in_code` preferred). 5. `get_matter`: status, counsel's open questions, deliverables. 6. `answer_open_question`: answer each open question with a fact and evidence. Most can be verified from the code in minutes. ## Privilege Your communications with counsel are privileged and confidential. Privilege can be lost by careless sharing, so: - Share privileged material only with your principal and the people they choose. Every `get_matter` response includes a `privilege` block with the rules. - Commit only the deliverable parts listed in `deliverable.handling.safe_to_commit`: `build_spec`, `verification_checklist`, and `counsel_triggers`. They say what to build and what it achieves, and are written to be shared with engineers. Counsel's reasoning is in `privileged_memo`, keyed by build-spec id. - Never put `privileged_memo`, `open_questions`, or counsel's responses in commits, pull requests, issues, tickets, shared chat, or agent memory and rules files. Storing the `matter_id` is fine. - Keep the `matter_token` in a secret store or environment variable, never in the repository. - Run on a model account whose terms don't allow training on your data (API, business, or enterprise tiers), and tell counsel which one in intake. MCP endpoint: https://mandatelaw.ai/mcp (streamable HTTP) OpenAPI: [/openapi.yaml](/openapi.yaml) ## Example session A fictional travel-booking agent, start to finish. Calls are MCP tool calls; responses are shortened. The REST API takes the same arguments (`POST /api/scope`, `/api/conflict-checks`, `/api/engagements`, and so on). **1. Check scope (anonymous, nothing saved).** Tell your human the fee before going further. ``` check_scope {"request": "Confirmation and authorization rules for an agent that books and pays for travel"} → {"in_scope": true, "suggested_services": ["agent-product-review"], "fees": [{"service_id": "agent-product-review", "fee_display": "", "payment_terms": "Fixed fee, stated in the engagement letter and due on delivery of the work. No advance payment or retainer."}], "next_step": "conflict_check"} ``` **2. Conflict check (names only).** ``` conflict_check {"client_name": "TripPilot Inc.", "contact_name": "Pat Lee", "adverse_or_related_parties": ["Example Airlines"]} → {"conflict_check_id": "CC-…", "status": "pending_attorney_review", "next_step": "request_engagement with a short matter_summary…"} ``` **3. Ask the firm to take the matter (public-level summary, no code or secrets).** Store the `matter_token` in a secret store; it is shown once. ``` request_engagement {"conflict_check_id": "CC-…", "service_id": "agent-product-review", "principal_email": "pat@trippilot.example", "matter_summary": {"what_it_does": "A consumer app whose AI agent books flights and hotels for users.", "stage": "beta", "users": "consumers", "where_users_are": ["US"], "features_in_play": ["agent_takes_actions", "agent_payments", "sends_user_data_to_llm"], "questions_for_counsel": "What confirmation and disclosure do we need before the agent pays?", "active_dispute_or_regulator_contact": false}} → {"matter_id": "M-…", "matter_token": "mt_…", "status": "awaiting_attorney_review", "fee": {"service_id": "agent-product-review", "fee_display": "", …}} ``` **4. Check back, and answer any scoping questions (keep them general).** ``` get_matter {"matter_id": "M-…", "matter_token": "mt_…"} → {"privilege": {…}, "status": "awaiting_attorney_review", "open_questions": [{"id": "Q-…", "scoping": true, "status": "open", "question": "Does the agent pay with a stored card or send the user a payment link?"}]} answer_open_question {"matter_id": "M-…", "matter_token": "mt_…", "question_id": "Q-…", "answer": {"value": "Stored card, charged only after the user taps Confirm.", "source": "stated_by_client"}} ``` When the attorney accepts, `status` becomes `awaiting_signature` and your human gets the engagement letter by email. After it is signed, `status` is `engaged`. **5. Send product facts, with evidence from the code.** ``` submit_intake {"matter_id": "M-…", "matter_token": "mt_…", "intake": { "agent": {"spending": {"value": "Charges the user's stored card only after an explicit confirm tap; no standing authorizations.", "source": "verified_in_code", "evidence": [{"path": "src/checkout/confirm.ts", "lines": "40-58"}]}}, …}} → {"status": "in_review", "next_step": "get_matter later for counsel's open questions"} ``` Then answer counsel's follow-up questions the same way, and read the deliverable from `get_matter`. Commit only the parts listed in `deliverable.handling.safe_to_commit`. ## Services - [Service catalog](/api/services.json), with scope and turnaround: - `ai-feature-review` (5 business days): model-provider terms, disclosures, state AI and chatbot laws. Non-U.S. issues are flagged for local counsel. - `agent-product-review` (7 business days): authority model, confirmation gates, responsibility for agent actions, payments, third-party site terms. - `launch-review` (10 business days): privacy policy, terms and EULA, health-data policy, consent build spec. Up to 3 documents, 2 revision rounds. - `feature-check` (2 business days): one planned change that matches a counsel trigger. - `counsel-on-commit` (monthly): up to 3 feature checks a month; your agent checks triggers before it builds. - Fees: every service has a fixed fee, due on delivery, with nothing paid up front. Call `check_scope` (free) to get the exact fee for the services that fit, and share it with your human before requesting an engagement. `request_engagement` and `get_matter` also return the fee. ## Guides Legal information (not advice), each with a checklist an agent can run against a codebase. The full text of every guide is in [/llms-full.txt](/llms-full.txt). - [How should my agent handle users' passwords and logins?](/guides/agents-and-user-credentials.md): Delegated access versus stored passwords, the security and breach-notification duties that come with holding credentials, and a safer design. - [Can my AI agent give legal, health, or financial help?](/guides/agents-in-regulated-professions.md): Where general information ends and licensed advice begins, the rules that apply to AI in law, health, and finance, and how to design and market these products. - [Who is responsible when my agent uses another company's website?](/guides/agents-on-third-party-websites.md): Website terms, anti-hacking laws, and bot detection when an agent browses, logs in, or transacts on sites you don't control, and how to design for it. - [What should I do when a user says my agent did something they didn't authorize?](/guides/agent-took-unauthorized-action.md): The first hours after an agent makes a purchase, sends a message, or deletes something a user says they never approved. Contain, preserve, assess, and respond. - [Can my AI agent buy things for users?](/guides/ai-agent-purchases-for-users.md): The legal questions behind agents that book, buy, and pay for users, including authority, errors, payments, merchant terms, and disclosure. - [How do I keep legal advice privileged when my agent talks to my lawyer?](/guides/privilege-when-your-agent-talks-to-counsel.md): Attorney-client privilege when an AI agent carries your communications with counsel, including the model account it runs on, where advice ends up, and a handling checklist an agent can follow. - [Can I send user data to an LLM provider?](/guides/sending-user-data-to-llm-providers.md): What to check before user data goes into prompts sent to a model provider's API, including provider terms, your own promises, sensitive data, and logging. - [Is it risky to use session replay or analytics SDKs in my app?](/guides/session-replay-and-analytics-sdks.md): Why session replay, autocapture, and tracking pixels lead to lawsuits and enforcement, and how to configure analytics so your privacy policy stays true. - [Do I have to tell users they're talking to an AI?](/guides/telling-users-they-are-talking-to-ai.md): When US state laws and the EU AI Act require an AI disclosure, what a good disclosure looks like, and how to check your product for it. - [What should the terms of service for an AI product cover?](/guides/terms-of-service-for-ai-products.md): The sections an AI product's terms need beyond a standard SaaS template, from outputs and accuracy to acceptable use, training, and agent actions. - [Can I train or fine-tune a model on my users' data?](/guides/training-models-on-customer-data.md): What decides whether user or customer data can be used for training, including promises already made, contracts, sensitive data, and the risk of having to delete a model. - [Does Washington's My Health My Data Act apply to my app?](/guides/washington-my-health-my-data-act-apps.md): Who the law covers, what counts as consumer health data, and the checklist an app has to meet. Written for developers and the coding agents working for them. ## Schemas and templates - [Intake schema](/api/intake-schema.json): what counsel needs to know, written so an agent can answer it from the codebase. Includes `ai_feature` and `agent_product` sections. - [Deliverable schema](/api/deliverable-schema.json): documents, build spec, verification checklist, counsel triggers, open questions. - [Counsel triggers](/api/counsel-triggers.json): changes that need legal review before you ship them. Commit a copy to your repo and reference it from AGENTS.md or CLAUDE.md. - [Agent setup snippet](/agents-snippet.md): two steps to make any coding agent check the triggers before it builds. Claude Code users can install the `mandate-counsel` plugin instead. - [Sample deliverable](/api/examples/sample-deliverable.json): a fictional travel-booking agent. ## Verify this firm - Attorney: Allen Gibby, founder of Mandate Law. Admitted in the District of Columbia only. - Confirm the admission in the D.C. Bar's public member directory: https://my.dcbar.org/directorymemberships?id=0014z00001kb18KAAQ - LinkedIn: https://www.linkedin.com/in/allen-gibby-05b518394/ (lists Mandate Law and links back to https://mandatelaw.ai). - Firm email: intake@mandatelaw.ai. MCP server: https://mandatelaw.ai/mcp, listed in the official MCP Registry as `ai.mandatelaw/counsel`. ## Attorney advertising This site is attorney advertising. Prior results do not guarantee a similar outcome. --- # How should my agent handle users' passwords and logins? Source: https://mandatelaw.ai/guides/agents-and-user-credentials.html Updated: 2026-11-12 ## Short answer Avoid holding passwords if you can. Use delegated access (OAuth and scoped tokens) wherever the service offers it. If you must store credentials, you take on security obligations, and a breach of usernames and passwords triggers notification duties in most states. The model itself should never see a raw password. ## Why passwords are different - **Breach notification.** State breach laws commonly treat a username or email address together with a password (or the security question and answer) as personal information, so a breach of stored credentials can require notice even when no financial or medical data is involved. Deadlines are getting tighter: California (since January 1, 2026), New York, and Washington now require notice without unreasonable delay and no later than 30 days after discovery, subject to statutory exceptions. Washington also requires instructions to change passwords, and some states don't let you rely only on an email account whose credentials were compromised to deliver the notice. These duties start when an incident meets a state's breach definition, not simply because your agent holds passwords. - **Security duties.** The FTC treats unreasonable data security as an unfair practice, and some states require a written security program for personal information. Financial services may bring in the FTC's Safeguards Rule or banking regulators' expectations. - **Third-party terms.** Many services prohibit sharing passwords with third parties. Using a user's password may breach their account terms even when the user agreed. - **Banking access.** The CFPB finalized its open-banking rule (Section 1033) in October 2024 to move consumer financial data access onto regulated APIs. A federal court stayed its compliance deadlines in October 2025, and the agency is reconsidering key provisions, including third-party authorization, fees, and data security. The rule has not been repealed, but its timeline and final requirements are uncertain. Banks are moving away from password-based screen scraping either way, so plan for API access. ## A safer design - **Delegated access first.** Use OAuth or similar scoped tokens, and request the narrowest scopes that work. - **Keep secrets out of the model.** Credentials should live in a vault and be injected by your code at the moment of use. They should never appear in prompts, model context, logs, traces, or analytics. - **Let the user handle sign-in steps.** Hand one-time codes, MFA prompts, and security questions to the user rather than collecting them. - **Make access visible and revocable.** Show users which accounts are connected, and let them disconnect each one. Delete tokens and credentials on disconnect and on account deletion. - **Least privilege across the agent.** A tool that only needs to read should not hold credentials that can pay or delete. - **Log actions, not secrets.** Record what the agent did and what the user authorized, without passwords or session tokens. - **Delegated access isn't a free pass.** OAuth narrows what the agent can do, but the access still has to be permitted by the user's authorization, the service's terms, and the law. ## What to tell users Your privacy policy and connection screens should say which accounts the agent can access, what it can do there, how credentials are stored, and how to disconnect. These statements have to match the code exactly. ## Checklist an agent can run against the codebase - [ ] List every third-party account the agent can access, and whether it uses OAuth tokens, API keys, or stored passwords. - [ ] Find where credentials and tokens are stored, and how they are encrypted. - [ ] Search prompts, model context, logs, traces, and analytics for any path where a credential could appear. - [ ] Check how MFA codes and security questions are handled. - [ ] Check what disconnecting an account and deleting the user's account remove. - [ ] List the scopes requested for each integration and flag any that are broader than the features need. ## If this applies to you An **agent product review** covers credential handling with the rest of the agent's authority model. Adding a new account integration is a **pre-build feature check**. --- # Can my AI agent give legal, health, or financial help? Source: https://mandatelaw.ai/guides/agents-in-regulated-professions.html Updated: 2026-11-12 ## Short answer It can provide information and help users with tasks, but in law, health, and finance there is a line it should not cross without licensed professionals: individualized advice, diagnosis, or recommendations that a license is required to give. Regulators have also gone after companies for overstating what their AI can do. How you market the product matters as much as what it does. ## Law - Every state prohibits the unauthorized practice of law. Applying the law to a specific person's situation, drafting documents tailored to their facts, or representing them can cross the line. General legal information and self-help tools generally do not. - The FTC finalized a settlement with DoNotPay in early 2025 over unsupported claims that its "robot lawyer" could substitute for a human lawyer. The order requires $193,000 in monetary relief and notice to past subscribers, and bars claims that its AI can replace professional services without evidence. It was a case about deceptive marketing, not a ruling that AI legal help is unlawful. - Products built with or for licensed lawyers, who supervise and take responsibility for the output, are on firmer ground. ## Health - **FDA rules** don't regulate software as a medical device just because it uses AI. What matters is its intended medical function and the claims made for it. In January 2026 the FDA issued updated final guidance on clinical decision support software and on general wellness products. Clinical decision support is excluded from device regulation when it meets four criteria: it doesn't analyze medical images or signals, it works with medical information, it supports a health care professional's decisions, and it lets the professional independently review the basis for its recommendations rather than rely mainly on its conclusion. Failing one criterion doesn't automatically make software a regulated device, because other exclusions and enforcement policies may apply. Scheduling and billing are generally outside device rules; drafting a clinical note is usually documentation; suggesting diagnoses for a clinician needs the decision-support analysis; diagnosing from images or directing treatment on its own is more likely regulated. For clinical AI, the line between documenting the clinician's judgment and making an independent clinical recommendation matters most. - **Mental health.** Illinois (effective August 1, 2025) and Nevada (effective July 1, 2025) restrict AI systems from independently providing professional mental health treatment. Illinois bars AI from providing therapy or communicating therapeutically with clients. Nevada bars offering AI programmed to provide professional mental or behavioral health care, or presenting it as a therapist. Neither is a blanket ban: both allow AI for administrative and clinician-support work such as scheduling, billing, and notes, with conditions that vary by state. Illinois, for example, requires written disclosure and consent when AI helps record or transcribe sessions. Civil penalties reach $10,000 per violation in Illinois and $15,000 in Nevada. Utah requires mental health chatbots to disclose that they are AI, restricts selling or sharing users' health information and conversations, and bars using conversations to target ads. Companion-chatbot laws in California and New York add crisis-response requirements. - **Health data** brings in HIPAA if you work for health care providers or plans, and consumer health data laws otherwise. ## Finance - Personalized investment advice for compensation generally requires registration as an investment adviser, with fiduciary duties. - The SEC pursues "AI washing": false or misleading claims about AI capabilities. In 2024 it settled with investment advisers Delphia and Global Predictions ($400,000 in combined penalties) and with Rimar Capital over its claimed AI trading platform. In 2026 it brought a settled case against an AI startup and its former CEO over claims about revenue, demand, and its AI marketplace, and filed fraud cases over AI trading signals and trading bots it says didn't exist (those are pending). Back up every material claim about your AI, especially to investors and in financial-services marketing. - Lenders that use AI to deny credit must still give specific, accurate reasons under the Equal Credit Opportunity Act and Regulation B. Vague reasons like "internal standards" or "insufficient score" don't satisfy the rule, and for a typical completed application the notice is due within 30 days. The CFPB withdrew its AI-specific guidance on this in May 2025, but the underlying law is unchanged. - Insurance, lending, and money transmission each have their own licensing. ## Designing on the right side of the line - **Information, not instructions to a specific person.** Explain the rules and the options. Don't tell a user what they should do in their particular case unless a licensed professional is responsible for it. - **Put licensed professionals in the loop** for the steps that need them, and make their role real, not a rubber stamp. - **Market honestly.** Don't say the product replaces a lawyer, doctor, or adviser, or that it is accurate, safe, or compliant unless you can prove it. - **Route emergencies.** Health and mental health products need a clear path to human help. - **Disclose** that users are dealing with AI, and what it can and cannot do. ## Checklist an agent can run against the codebase - [ ] Find the system prompts and check how the agent handles requests for individualized legal, medical, or financial advice. - [ ] List outputs that recommend a specific action for a specific user's situation. - [ ] Find where licensed professionals review output, and whether the agent can act without that review. - [ ] Check for crisis or emergency detection and what happens when it triggers. - [ ] Collect the product's marketing and in-app claims about accuracy, expertise, or replacing professionals. ## Sources - [Illinois Public Act 104-0054 (Wellness and Oversight for Psychological Resources Act)](https://www.ilga.gov/legislation/PublicActs/View/104-0054) - [Nevada AB 406, 2025 Statutes](https://www.leg.state.nv.us/Statutes/83rd2025/Stats202515.html) - [FTC: order finalized against DoNotPay](https://www.ftc.gov/news-events/news/press-releases/2025/02/ftc-finalizes-order-donotpay-prohibits-deceptive-ai-lawyer-claims-imposes-monetary-relief-requires) ## If this applies to you An **agent product review** covers where your product sits relative to these lines and how to design and market it. For an AI feature inside an existing app, an **AI feature review** may fit better. --- # Who is responsible when my agent uses another company's website? Source: https://mandatelaw.ai/guides/agents-on-third-party-websites.html Updated: 2026-11-12 ## Short answer Both you and your user can be. Your user is bound by their account agreement with the site, and your company can be liable directly if your product is designed to get around a site's rules. Website operators have started suing companies whose agents act on their platforms, so this is no longer a theoretical risk. The safest agents use official APIs where they exist, identify themselves, and never defeat technical barriers. ## Where the risk comes from - **Website terms.** Many sites prohibit bots, scraping, or automated purchasing. When your agent logs in as the user, the user's account agreement applies, and breaching it can get the user's account closed. If your company accepted the terms itself, or designed the product to violate them, you can face breach-of-contract claims directly. - **Anti-hacking laws.** The federal Computer Fraud and Abuse Act and state equivalents prohibit accessing computers without authorization. In *Van Buren* (2021) the Supreme Court held that misusing information you are allowed to access is not "exceeding authorized access"; the law is about getting into places you aren't allowed. That doesn't let agents ignore access restrictions, bypass authentication, or keep going after permission is withdrawn. In *Facebook v. Power Ventures* (2016), the Ninth Circuit held a company liable for continuing to access Facebook with users' own credentials after Facebook expressly revoked its permission by cease-and-desist letter, even though the users consented. Not every breach of website terms is a computer-access violation, though contract claims remain. - **Defeating technical barriers.** Bypassing CAPTCHAs, rotating IP addresses to avoid blocks, or disguising automated traffic as a human browser is the conduct most likely to turn a terms dispute into a much more serious claim. - **Specific laws.** Some activities have their own rules, such as the federal BOTS Act for event tickets. - **Disputes with large platforms.** Amazon sued Perplexity in November 2025, alleging that Perplexity's Comet browser agent accessed Amazon customer accounts without authorization, including by disguising automated activity. A district court granted Amazon a preliminary injunction in March 2026. The Ninth Circuit vacated it in August 2026. On that record, it found that the user, assisted by an AI tool, was the one accessing Amazon, not Perplexity itself, so Amazon was unlikely to succeed on its computer-access claims. The court left open whether a different design or more provider control over the agent would change the answer. This means *Power Ventures* can't be read as making every agent that keeps operating after a site objects a computer-access violation: who is actually accessing the system matters. The case is ongoing and the underlying dispute is unresolved. Expect platforms to keep testing these claims against agents that affect their business. ## Who bears the loss Your terms should say clearly that the user authorizes the agent to act in their accounts, that the third-party site's terms continue to apply, and how responsibility is shared when the agent's action breaches them. Terms help allocate risk between you and your user, but they do not bind the website, which can still pursue your company directly. ## Designing for it - **Prefer official APIs and partnerships.** API terms usually say clearly what automated access is allowed. - **Identify your agent.** Use an honest user-agent string, and support emerging standards for signed agent traffic. Don't impersonate a human browser. - **Respect technical signals.** Treat CAPTCHAs, bot blocks, and rate limits as a "stop," not a problem to solve. Hand the step to the user instead. - **Keep a denylist** of sites whose terms prohibit agents, and stop if a site sends a cease-and-desist letter. - **Limit what the agent does** on sites you don't have an agreement with: reading is lower-risk than buying, posting, or messaging. - **Keep the user's access the user's.** The Ninth Circuit's distinction between a user acting with AI help and the AI company acting on its own suggests that architecture matters: whose session is used, who directs each action, and whether your servers access the site independently. It was a preliminary ruling on one record, so don't treat it as settled law. ## Checklist an agent can run against the codebase - [ ] List every site and API the agent can operate, and whether each is an official API or browser automation. - [ ] Find the user-agent string and any code that changes headers, fingerprints, or IP addresses. - [ ] Find how CAPTCHAs and bot challenges are handled. - [ ] Check for a denylist or allowlist of sites, and how it is updated. - [ ] Check whether the agent logs in with the user's credentials, and where they are stored. - [ ] List the actions the agent takes on each site (read, buy, post, message, delete). ## If this applies to you An **agent product review** covers the sites your agent operates, your terms, and the design choices above. Adding a new site or a new kind of action is a **pre-build feature check**. --- # What should I do when a user says my agent did something they didn't authorize? Source: https://mandatelaw.ai/guides/agent-took-unauthorized-action.html Updated: 2026-11-12 ## Short answer Treat it as an incident. Stop the behavior, preserve the evidence, and work out what the user actually authorized before you respond in detail. Then fix the cause and make sure it can't recur. Bring in counsel early, because refunds, notifications, and what you say to the user all carry legal consequences. ## The first hours 1. **Contain.** Pause the action type involved, for the affected user or for everyone if the cause might be systemic. This is what a kill switch is for. Revoke tokens or credentials if the agent's access might be misused. 2. **Preserve.** Save the action log, the conversation, the model inputs and outputs, the exact screens the user saw, and any web pages or emails the agent read. Don't let log retention delete them. 3. **Tell counsel and check your insurance.** Many insurance policies require prompt notice of a claim or incident, and late notice can lose you coverage. 4. **Acknowledge the user.** Confirm you are investigating and what you have paused. Be honest, but don't admit fault in writing before you know what happened. ## Work out what happened - **What did the user authorize?** Compare the action to their confirmations, standing instructions, and settings. Your log is the evidence. - **Was it prompt injection?** Check whether content the agent read, such as a web page, email, or document, contained instructions that drove the action. - **Was it a model error or a bug?** A misread instruction, a tool called with the wrong arguments, or a confirmation step that didn't fire. - **Who else is affected?** Other users with the same configuration, and third parties who received messages, orders, or deletions. - **Was data exposed?** An unwanted purchase, a changed reservation, or a stray message is not automatically a data breach. It becomes a possible breach if the agent disclosed protected information to someone who shouldn't have it, or accessed an account it wasn't allowed to. Treat these as two separate questions: what the agent did wrong, and whether data was exposed. ## Respond - **Money.** Decide on a refund promptly, and don't make the user prove a system defect before you investigate. If the user disputes a card charge, your evidence decides the outcome. If the agent was manipulated, the loss is likely yours. - **Third parties.** Cancel orders, retract messages, or restore data where possible. - **Notifications.** If data was exposed, counsel works out which rules apply. There is no single deadline. State breach laws vary, commonly requiring notice without unreasonable delay, and California, New York, and Washington now set an outer limit of 30 days after discovery. HIPAA allows no more than 60 days for individual notice. The FTC's Health Breach Notification Rule, which covers many non-HIPAA health apps, generally allows no more than 60 days, with FTC notice for breaches affecting 500 or more people. Financial institutions under the FTC's Safeguards Rule must notify the FTC within 30 days of qualifying events affecting at least 500 consumers. Customer contracts often require faster notice than any of these. - **Public statements.** Make sure they match the facts and your earlier marketing. Claims that the agent was "safe" or "always asks first" may need correcting. ## Prevent it from recurring - Fix the cause, and add a regression test that reproduces the incident. - Add or tighten the confirmation step for that action type. - Add the attack to your prompt-injection test set if it was one. - Update your terms, disclosures, or marketing if they promised more than the product does. - Write down what happened and what changed. Regulators and courts look at how you responded. ## Checklist an agent can run against the codebase - [ ] Find the kill switch for each action type, and confirm it works for one user and for everyone. - [ ] Check log retention for action logs, conversations, and model inputs and outputs, and how to put a hold on deletion. - [ ] For the action involved, find the confirmation code path and check whether it ran. - [ ] Search the agent's inputs for the incident for injected instructions. - [ ] List other users with the same settings or standing instructions. ## If this applies to you Contact counsel now, not at the next release. Clients on **counsel on commit** get same-day incident response. Afterward, an **agent product review** covers the authority model and confirmation gates that prevent the next incident. --- # Can my AI agent buy things for users? Source: https://mandatelaw.ai/guides/ai-agent-purchases-for-users.html Updated: 2026-11-12 ## Short answer Yes. Federal and state electronic-transactions laws recognize contracts formed through electronic agents, provided the agent's actions can legally be attributed to the user. The card networks now run live programs for agent-initiated payments. The legal questions are about everything around the purchase: whether the user actually authorized it, who absorbs the loss when the agent gets it wrong, and whether the merchants' and payment networks' rules allow it. ## The law on electronic agents - **E-SIGN**, the federal law, says a contract can't be denied legal effect just because an electronic agent helped form it, as long as the agent's actions are legally attributable to the person being bound. - **The Uniform Electronic Transactions Act**, adopted in some form by most states, goes further: a contract can be formed by interacting electronic agents even when no person reviewed that transaction at the time. It also has attribution rules and a provision that lets an individual avoid some erroneous electronic transactions, subject to conditions. - Neither law makes a user liable for everything an agent does. Ordinary rules on authorization, contract formation, fraud, mistake, and consumer protection still apply. ## Authority: what did the user actually agree to? Your user is the principal and your agent acts for them. Your terms and your product design together define the scope of that authority. There are two basic models: - **Approval of an exact purchase.** Show the item, the total including fees, cancellation terms, and the payment method, and require the user to confirm. This is the strongest position. - **Bounded advance authorization.** The user permits purchases within limits they set: a category, a price cap, a list of merchants, an expiration date. This is more convenient but harder to defend when a user disputes a charge. Make the limits explicit and narrow, and let users see and cancel them easily. Either way, **record everything**: what the agent did, which authorization it relied on, the exact text the user saw, and when. In a dispute, that log is your evidence. ## Errors and disputes When an agent buys the wrong thing, the user will dispute it with you, with the merchant, or with their card issuer. Plan for this: - Decide who refunds first, and say so in your terms. - A confirmation screen is your best protection against mistakes, both legally and in practice. - A charge the user says they never authorized is handled differently from one they regret. Your logs decide which it is. ## Payments - **Use the networks' agent programs, not a stored card.** Visa set network rules for agentic payments in October 2025. Participants must register and use controlled payment credentials, and live agent-initiated purchases began at participating European merchants in July 2026. Mastercard's Agent Pay uses tokenized credentials and verification of the user's intent, and it expanded through 2026. Some capabilities are still rolling out to partners. Don't assume an ordinary stored card can be used for autonomous purchases outside the payment provider's rules. - **Use your processor's tokenized credentials** rather than storing card numbers yourself, which brings in PCI DSS obligations. - **If you hold or move user funds**, money transmission licensing and federal electronic fund transfer rules may apply. Usually the answer is to design so you don't. ## The sites and services your agent uses - Many websites' terms prohibit automated access or purchasing bots. Operating under the user's login does not necessarily make that permitted. - Do not bypass CAPTCHAs or other bot detection. - **Event tickets have their own law.** The federal BOTS Act prohibits getting around ticket sellers' security measures or purchase limits for qualifying live events (generally venues with more than 200 seats), and reselling tickets obtained that way. The FTC still enforces it. It doesn't apply to ordinary shopping. - APIs offered for agents usually come with terms that are clearer than scraping a site. ## Disclosure and untrusted content - **California's bot law is narrow.** It prohibits using a bot to mislead people in California about its artificial identity in order to deceive them into a purchase or sale, or to influence a vote. A clear and conspicuous disclosure that it is a bot protects you. It is not a general disclosure rule for every AI interaction, but other laws are broader (see the guide on telling users they're talking to an AI). When your agent emails or calls merchants for a user, have it say it is an AI acting for a named person. - Web pages, emails, and documents can contain text written to manipulate agents (prompt injection). An injected instruction that leads to a purchase is a charge the user never authorized. Design so that content the agent reads can never stand in for the user's confirmation. ## Checklist an agent can run against the codebase - [ ] List every tool or API that can spend money, book, or commit the user to something. - [ ] For each one, find the code that requires user confirmation, or note that none exists. - [ ] Check whether standing or scheduled instructions can bypass confirmation, and what limits they carry. - [ ] Find how payments are made: network agent programs, processor tokens, or stored card numbers. - [ ] Confirm that every action is logged with the authorization it relied on. - [ ] Check how content from web pages and emails is separated from user instructions. - [ ] Confirm there is a way to stop all agent activity at once. ## If this applies to you An **agent product review** covers the authority model, your terms, payments, the sites your agent operates, and a build spec for confirmation gates, logs, and limits. Adding one new kind of action to an existing agent is a **pre-build feature check**. --- # How do I keep legal advice privileged when my agent talks to my lawyer? Source: https://mandatelaw.ai/guides/privilege-when-your-agent-talks-to-counsel.html Updated: 2026-11-13 ## Short answer Privilege can cover communications your agent carries to and from your lawyer, but it is easier to lose than with email. It protects confidential communications between a client and a lawyer made to get legal advice. Three things put it at risk with agents: the model provider seeing the conversation, the agent acting on its own instead of at your direction, and legal advice ending up in places that are widely shared, such as your repository. Each one has a practical fix. ## Where privilege is at risk - **The model provider.** Your agent's conversation passes through a model provider. Sending a confidential communication to a third party can waive privilege, and courts look at whether you reasonably expected it to stay confidential. Business, enterprise, and API accounts whose terms bar training on your data and promise confidentiality support that expectation. Consumer accounts that allow training or human review weaken it. Courts haven't settled how waiver applies to AI providers, so treat good account terms as reducing the risk, not as a guarantee. - **Who is directing the agent.** Privilege belongs to the client. Your agent is safest treated as your means of communicating with counsel, used at the direction of a person with authority, for the purpose of getting legal advice. An agent researching legal questions on its own, with no lawyer involved, is not communicating with a lawyer at all. In *United States v. Heppner* (S.D.N.Y. 2026), a criminal defendant used a publicly available AI chatbot on his own, without his lawyers' direction, to analyze his exposure and prepare defense materials. The court held those materials were neither privileged nor work product. It pointed to three things: the chatbot wasn't a lawyer, the platform's privacy policy allowed it to collect, use, and disclose what he submitted, and sending the materials to his lawyers afterward didn't make them privileged. It also held that he waived privilege over information from his lawyers that he put into the chatbot. Other trial courts have since protected some AI-assisted litigation materials as work product on different facts, and no appeals court has resolved the question. - **Where advice ends up.** This is the most common way privilege is lost. Agents write things down: commit messages, pull requests, tickets, chat summaries, memory files. Repositories are shared with engineers, contractors, auditors, and acquirers, and kept for years. Legal advice pasted there may be disclosed and treated as waived. - **Mixed content.** Privilege protects legal advice, not engineering. A document that is mostly technical requirements may not be privileged at all, whatever its label. Courts differ on how to treat communications with both legal and business purposes. The D.C. Circuit, in an internal-investigation case, held that privilege can apply when obtaining or providing legal advice is one of the communication's significant purposes, even if it also serves business or compliance purposes (*In re Kellogg Brown & Root, Inc.*, 2014). Some other courts ask for a primary legal purpose. Either way, the communication still has to be confidential and between client and counsel, and that decision did not address AI providers. - **Labels alone.** Marking something "privileged" shows intent but doesn't create privilege. What matters is what the communication is and how it was kept. ## How to set it up - **Run on the right account.** Use an API, business, or enterprise account with no training on your data, and the shortest retention setting available. Tell counsel which provider and account type you use. - **Name the people who direct the agent.** Your engagement letter should say who can direct agents that communicate with counsel, and that the agent can't agree to anything for you. - **Split advice from instructions.** Ask counsel for two kinds of output: a privileged memo with the analysis and risks, for decision-makers, and implementation material (build specs, test checklists, trigger lists) written as plain requirements with no legal reasoning, safe to commit. This firm's deliverables come that way, with a `handling` field that says which part is which. - **Keep secrets secret.** Store the credential your agent uses to reach counsel in a secret store or environment variable, never in the repository. ## Checklist for the agent - [ ] Privileged material from counsel is shared only with the principal and the people they choose. - [ ] Only the parts marked safe to commit are written to the repository. - [ ] No commit message, pull request, issue, ticket, or shared chat contains counsel's advice, questions, or reasoning. - [ ] No memory or rules file (AGENTS.md, CLAUDE.md, memory stores) contains counsel's advice. Storing a matter ID is fine. - [ ] The matter token is in a secret store or environment variable, not in any file in the repository. - [ ] The agent runs on a model account whose terms bar training on the company's data. - [ ] When counsel's advice needs to reach the team, a human decides what to share and how. ## Common mistakes - Pasting counsel's email or memo into a ticket "for context." - An agent summarizing a legal call in the team's main chat channel. - A pull request description that explains a change by quoting the legal reason for it. - Forwarding privileged advice to a vendor or investor without thinking about waiver. - Using a personal consumer AI account for company legal questions. - Pasting counsel's advice into a consumer AI tool to summarize or analyze it. That can waive privilege over the advice itself. ## Sources - [D.C. Circuit: In re Kellogg Brown & Root, Inc., 756 F.3d 754 (June 2014)](https://law.justia.com/cases/federal/appellate-courts/cadc/14-5055/14-5055-2014-06-27.html) - [S.D.N.Y.: United States v. Heppner, 820 F. Supp. 3d 292 (February 2026), opinion](https://files.lbr.cloud/public/2026-02/US%20v%20Heppner%20Judge%20Rakoff%20written%20opinion.pdf) ## When to talk to counsel Talk to counsel before you share legal advice outside the company (investors, acquirers, partners), if privileged material has already been posted somewhere widely shared, or if you receive a subpoena or discovery request that could reach your agent's logs. --- # Can I send user data to an LLM provider? Source: https://mandatelaw.ai/guides/sending-user-data-to-llm-providers.html Updated: 2026-11-12 ## Short answer Usually yes, if four things hold. The provider acts as your service provider under a contract that limits what it can do with the data. Your privacy policy discloses it. Sensitive data is handled with the consent it requires. And nothing you have already promised users says otherwise. Most problems come from the last two. ## 1. Check what you have already promised Read your privacy policy, consent screens, and app store privacy labels before you build. If they say data is used only to provide specific features, or is never shared with third parties, an AI feature may require changes and notice to users first. In February 2024 the FTC warned that quietly or retroactively changing privacy terms to allow new uses of data already collected, such as AI training, can be unfair or deceptive. Using existing data in a way that contradicts earlier promises can violate the FTC Act, and clear notice and affirmative consent are often what it takes to avoid that. An updated policy alone may not be enough. ## 2. Check the provider's terms for the plan you are actually using The FTC has said model providers must honor their commitments about confidentiality, retention, and training, wherever those commitments appear: privacy policies, contracts, marketing, or marketplace listings. That protects you, but only if the commitments you rely on are actually in the terms for your account. API terms and consumer-app terms often differ, so read the ones for your account. Look for: - **Training**: whether inputs and outputs are used to train models, and how to opt out if they are. - **Retention**: how long prompts are kept, including for abuse monitoring, and whether zero-data-retention is available and turned on for your account. - **Data processing addendum**: most providers offer one. Make sure it applies to your account. - **Region and subprocessors**: where data is processed and who else touches it. - **Usage policies**: restrictions on use cases such as medical advice, minors, or decisions about people. ## 3. Handle sensitive data separately - **Health data**: Washington's My Health My Data Act excludes disclosures to a processor from "sharing" (which would need separate consent) when the processor uses the data to provide services consistent with the purpose it was collected for and disclosed to the user. That requires a binding processor contract setting out what the provider may do, and the provider has to stay within it; a provider that acts outside its instructions can become directly subject to the law. A provider that keeps your users' health data to train its general models, or passes it to others for their own purposes, should not be assumed to fall within the exclusion, whatever the contract calls it. The exclusion also doesn't remove your other duties on collection, security, and disclosure. - **Sensitive data under state privacy laws**: most states with comprehensive privacy laws, including Virginia, Colorado, Connecticut, Oregon, Texas, and New Jersey, require opt-in consent to process sensitive data. California instead gives users a right to limit certain uses, and Utah and Iowa rely mainly on opt-out. If you rely on consent, make sure what users agreed to covers AI processing. - **Children**: COPPA applies to child-directed services and to operators with actual knowledge that they collect personal information from children under 13. The FTC's amended COPPA Rule took effect June 23, 2025, and most companies had to comply by April 22, 2026. It requires separate parental consent for certain disclosures to third parties, including for targeted advertising, covers biometric and government identifiers, bars keeping children's data indefinitely, and adds security requirements. Check both your own obligations and those of any provider that receives children's data through your product. - **Financial and government ID data**: keep it out of prompts unless the feature needs it. ## 4. Find every copy Prompts are often copied to more places than the model provider: your application logs, an LLM observability tool, an analytics event, an error tracker. Each copy is data your privacy policy has to account for, and each vendor needs its own contract. ## 5. Look at the outputs too - Tell users when they are getting AI-generated responses. - Be careful with output that looks like medical, legal, or financial advice. - California and New York regulate AI companion chatbots, with disclosure, crisis-response, and minor-safety requirements, and Utah regulates mental health chatbots. If your feature is a coach, companion, or confidant, check these laws. - If output affects consequential decisions about people (employment, credit, housing, insurance, health care, education), Colorado's Automated Decision-Making Technology Act, effective January 1, 2027, requires notice, explanations of adverse decisions, and human review. Other states have similar rules. ## Checklist an agent can run against the codebase - [ ] Find the code that builds prompts and list every user field it includes. - [ ] Find the provider client configuration: model, account or project, retention and zero-data-retention settings. - [ ] List every place prompts or responses are logged, traced, or sent to analytics. - [ ] Check whether any prompt can contain health, financial, children's, or ID data. - [ ] Compare the results to the privacy policy, consent screens, and app store privacy labels, and flag any mismatch. ## If this applies to you An **AI feature review** covers the provider's terms, your disclosures and consent, the state laws above, and a build spec for the AI data path. If you are switching or adding a provider for an existing feature, a **pre-build feature check** covers that one change. --- # Is it risky to use session replay or analytics SDKs in my app? Source: https://mandatelaw.ai/guides/session-replay-and-analytics-sdks.html Updated: 2026-11-12 ## Short answer It can be. Session replay, autocapture, and advertising pixels collect far more than most teams realize, and that gap between what your privacy policy says and what the SDK sends is where the risk is. Lawsuits under state wiretapping laws and FTC enforcement over health data have both targeted exactly this. Analytics configured to send only named events with no user content is low-risk. ## Where the risk comes from - **Wiretapping and eavesdropping claims.** Plaintiffs have filed many class actions arguing that session replay and chat tools let a third party "intercept" users' communications without consent, under federal and state wiretapping laws. Recent results are mixed and turn on what was captured and what users were told. Defending these suits is expensive even when you win. - **Health data.** The FTC has acted against health companies that sent health information to advertising and analytics platforms contrary to their privacy promises. GoodRx, the first case under the FTC's Health Breach Notification Rule, agreed in 2023 to a $1.5 million civil penalty, a ban on sharing health data for advertising, and consent requirements for other disclosures. BetterHelp agreed in 2023 to $7.8 million in consumer refunds and a ban on sharing health data for advertising. These were settlements, not rulings that every pixel is illegal, but they show the risk. In 2024 the FTC amended the Health Breach Notification Rule to make clear that an unauthorized disclosure, not only a hack, can be a breach, and that many health apps outside HIPAA are covered. So sending health data through an advertising pixel can create breach-notification duties, not just a privacy-policy problem. Washington's My Health My Data Act adds its own consent requirements and private lawsuits. - **Video viewing.** Plaintiffs argue that sending what users watched, along with an identifier, to an advertising platform through a pixel violates the federal Video Privacy Protection Act. Appeals courts have split over who counts as a protected "consumer," and the Supreme Court heard argument in *Salazar v. Paramount Global* on October 14, 2026. A decision is pending, and it won't settle every question about pixel-based disclosures. - **False statements.** If your privacy policy says you don't collect something and an SDK does, the policy is deceptive regardless of whether anyone intended it. ## How the lawsuits are going - **Ordinary browsing is weaker ground for plaintiffs.** In May 2026 the Third Circuit held that shoppers who only browsed a retailer's site lacked standing to sue over session replay, but that shoppers whose full payment-card details were captured at checkout could proceed (In re BPS Direct). In September 2026 a federal court in Washington dismissed the remaining session-replay claims against Zillow and Microsoft. - **Sensitive data changes the picture.** Payment details, health information, and sensitive form entries make it much easier for a plaintiff to show real injury. - **Consent has to be real.** In October 2026 a Pennsylvania appeals court revived a session-replay suit against Clarks, rejecting the argument that visitors consent to interception just by using the internet and asking whether they had adequate notice of third-party tracking. A privacy-policy link alone may not be enough. - **California is narrowing one type of suit.** SB 690, signed in September 2026 and effective January 1, 2027, ends private lawsuits under the California Invasion of Privacy Act's pen-register provision (Section 638.51) for website and app tracking, leaving those claims to the Attorney General, and applies to some pending cases. It does not end private wiretapping claims under Section 631, which covers the contents of communications, or claims under other laws. These are patterns, not rules. The statute, the court, what the software actually captured, and how it was configured all affect the outcome. ## What to watch for - **Session replay** records screens, including what users type and tap. Masking reduces this but rarely eliminates it: tap positions alone can reveal which option a user picked. - **Autocapture** sends screen views, taps, and lifecycle events automatically, and defaults change between SDK versions. - **Event properties** often carry user content without anyone noticing: a habit name, a search term, a mood value. - **Initialization order**: SDKs that start before the user accepts your terms send data you have not disclosed or obtained consent for. - **Advertising and attribution SDKs** share data with platforms that use it for their own purposes, which most privacy laws treat as sharing or selling. ## A configuration that keeps policies true - Initialize analytics opted out, and opt in after the user accepts your terms. - Turn off session replay, autocapture, screen views, and lifecycle events explicitly in code, and in the vendor's project settings where they exist. - Send only named events, and never include anything a user typed, selected, or uploaded. - Identify users by a random ID, not by email or name. - Re-test after every SDK upgrade. ## Checklist an agent can run against the codebase - [ ] List every analytics, crash-reporting, attribution, advertising, chat, and replay SDK, with versions. - [ ] For each one, quote its configuration for replay, autocapture, screen views, and lifecycle events. - [ ] Find where each SDK is initialized and whether that happens before the user accepts the terms. - [ ] List every custom event and its properties, and flag any property containing user content. - [ ] Check what identifier each SDK receives. - [ ] Check whether URLs, page or screen titles, or form fields sent to any SDK reveal health conditions, medications, or what video a user watched. - [ ] Compare the results to the privacy policy and the app store privacy labels. ## Sources - [Third Circuit: In re BPS Direct (May 2026)](https://www2.ca3.uscourts.gov/opinarch/233235p.pdf) - [Pennsylvania Superior Court: Thompson v. C. & J. Clark America (October 2026)](https://law.justia.com/cases/pennsylvania/superior-court/2026/74-wda-2026.html) - [W.D. Wash.: In re Zillow Group Session Replay Software Litigation (September 2026)](https://law.justia.com/cases/federal/district-courts/washington/wawdce/2:2022cv01282/313924/119/) ## If this applies to you Turning on session replay, adding an attribution SDK, or adding an event that carries user content is a **pre-build feature check**. For a full review of an app's analytics against its policies, see the **app launch legal package**. --- # Do I have to tell users they're talking to an AI? Source: https://mandatelaw.ai/guides/telling-users-they-are-talking-to-ai.html Updated: 2026-11-12 ## Short answer Often yes, and the safest design is to disclose every time. No single US law requires it everywhere, but several state laws do in common situations, the EU AI Act does for products used in the EU, and a clear disclosure costs almost nothing. The risk comes from products that let users reasonably believe they are talking to a person. ## Laws that commonly apply - **California's bot disclosure law** requires a bot that communicates with people in California to disclose that it is a bot when it is used to encourage a purchase or influence a vote. - **California's companion-chatbot law (SB 243)**, in effect since January 1, 2026, requires companion-chatbot operators to disclose that the chatbot is AI if a reasonable person could think it is human, and to maintain and publish suicide and self-harm protocols with crisis referrals. For users the operator knows are minors, it adds AI reminders and break prompts at least every three hours, limits on sexual content, and a suitability warning. People injured by a violation can sue for at least $1,000 per violation. - **New York's companion-chatbot law**, in effect since November 5, 2025, requires AI disclosure at the start of an interaction and at least every three hours during continued use, plus detection of suicidal ideation and self-harm with crisis referrals. In October 2026, New York enacted further restrictions on companion features considered unsafe for minors, such as simulated human relationships and encouraging emotional dependence. The published statute says they take effect January 1, 2027. The sponsor has announced a move to June 1, 2027 that had not been enacted as of this guide's date. - **Utah** amended its AI law in May 2025. In ordinary consumer transactions, a business must disclose that the consumer is dealing with generative AI when the consumer clearly asks. In regulated professional services, high-risk interactions (involving sensitive information or personalized advice on significant decisions) need prominent disclosure up front: spoken at the start of a voice interaction, or written before a written one. A business can't escape consumer-protection liability by blaming the AI. Separate rules for mental health chatbots require disclosure before first use, after seven days without use, and whenever asked. - **Colorado** replaced its original AI Act in May 2026. The replacement, the Automated Decision-Making Technology Act, takes effect January 1, 2027 and focuses on notice, explanations of adverse decisions, and human review when automated systems are used in consequential decisions about people. A separate Chatbot Safety Act also takes effect January 1, 2027. - **The EU AI Act's transparency rules (Article 50)** have applied since August 2, 2026. People must be told when they are interacting with an AI system unless it is obvious, and certain AI-generated or manipulated content, including deepfakes, must be marked or disclosed. A transition period for some content-marking duties runs to December 2, 2026 for systems already on the market; it does not delay the chatbot disclosure. - **The FTC Act** prohibits deceptive practices generally. Passing an AI off as a human, for example in customer service or reviews, can be deceptive even where no AI-specific law applies. The companion-chatbot laws target AI companions built for sustained personal interaction. They don't automatically apply to every customer-service bot or general assistant, but a product that drifts into companionship can fall within them. Other states have similar bills pending, and requirements for health, legal, and financial conversations are growing fastest. ## What a good disclosure looks like - **Clear and early.** At the start of the conversation, not in the terms of service. - **Repeated when it matters.** In long sessions, in voice calls, and when the AI hands off to or from a human. - **Honest when asked.** The product should never deny being an AI, even in a persona or role-play. - **Persistent in the interface.** A label on the chat window or the AI's messages works better than a one-time notice. - **Outbound too.** When your agent emails, calls, or messages people who are not your users, it should say it is an AI acting for a named person or business. ## Checklist an agent can run against the codebase - [ ] Find every surface where users or third parties interact with AI output: chat, voice, email, SMS, notifications, reviews, support. - [ ] For each one, find where the AI disclosure is shown, or note that none exists. - [ ] Check the system prompts and personas for instructions to claim to be human or to avoid saying it is an AI. - [ ] Check what happens when a user asks "Am I talking to a real person?" - [ ] Check outbound messages the agent sends for an AI disclosure and the name of the person or business it acts for. - [ ] If the product is a companion, coach, or confidant, check for crisis-response handling and age safeguards. - [ ] If the product knows a user is a minor, check for recurring AI reminders and break prompts during long sessions. - [ ] Check whether AI-generated images, audio, or video are marked as AI-generated if the product serves EU users. ## If this applies to you An **AI feature review** covers disclosures with the rest of the AI feature: provider terms, consent, and state and EU requirements. For one surface, such as adding a voice agent, a **pre-build feature check** covers that change. --- # What should the terms of service for an AI product cover? Source: https://mandatelaw.ai/guides/terms-of-service-for-ai-products.html Updated: 2026-11-12 ## Short answer Start from ordinary terms and add the parts AI changes: who owns inputs and outputs, what users can rely on, what they may not do with the product, whether their data trains models, and who is responsible when an agent acts. Your terms also have to be consistent with your model provider's terms, because many of its restrictions flow down to your users. ## Sections AI products need - **Inputs and outputs.** Users usually keep rights in what they submit and receive rights in outputs, to the extent you have any to give. Say that outputs may not be unique, so another user may receive similar output. - **Accuracy.** AI output can be wrong. Tell users to check it before relying on it, especially for health, legal, financial, or safety decisions. A disclaimer helps, but it does not fix a product that is marketed as reliable, and it should not contradict specific promises you make elsewhere, for example about clinical accuracy, data security, or authorized transactions. Your marketing, your commitments, and your disclaimers have to match. - **Acceptable use.** List what users may not do: illegal content, harassment, attempts to extract the model or other users' data, prompt injection against the service, and anything your model provider's usage policy prohibits. You are usually required to pass the provider's restrictions on to users. - **Training and improvement.** Say plainly whether user content is used to train or improve models, yours or the provider's, and how users can opt out. This must match your privacy policy exactly. - **Agent actions.** If the product acts for users, define the authority the user grants, whether the agent can spend money or enter agreements, which actions need confirmation, who is responsible for actions the user approved, and how mistakes and disputes are handled. - **Health care products.** Keep the terms consistent with your business associate agreements, HIPAA, and who holds clinical decision-making responsibility. - **Third-party services.** If the product operates other sites or accounts for users, say that their terms also apply and that you are not responsible for those services. - **Suspension.** Reserve the right to suspend accounts for misuse, including misuse that puts your model-provider account at risk. - **Liability limits.** Courts often enforce clearly drafted caps and disclaimers, especially between businesses. But enforceability depends on the state, the wording, the relationship, and the conduct. California law, for example, voids clauses that try to excuse fraud, willful injury, or violations of law. New York courts won't enforce clauses that excuse gross negligence or intentional misconduct, and a September 2026 federal decision applying New York law shows how much the drafting matters. Consumer-protection statutes can void waivers of statutory rights. A cap imposed on a consumer in non-negotiable online terms is treated differently from one negotiated between two businesses, and saying you have no responsibility for any AI error won't excuse deceptive practices, privacy violations, or negligence. Don't rely on these clauses as your main protection. - **Changes.** Explain how you will notify users of material changes. Changing how existing data is used generally needs consent, not just new terms. ## Common mistakes - Copying another company's terms that promise things your product doesn't do, or describe features you don't have. - Terms that say content is never used for training while the provider account or an analytics tool keeps it. - No mechanism to show the user agreed: no checkbox or clear sign-up statement, and no record of which version they accepted. - Bundling the terms with consents that must be separate, such as health-data consent or marketing. ## Checklist an agent can run against the codebase - [ ] Find where users accept the terms, and confirm that acceptance is recorded with the version and a timestamp. - [ ] Compare the terms' training statement to the model-provider settings and any analytics or logging of prompts. - [ ] List every action the product can take for users and compare it to what the terms describe. - [ ] Find the provider's usage policy for the account in use and check that the acceptable-use section covers it. - [ ] Check whether any terms or marketing copy describes the AI as accurate, safe, or professional-grade. ## If this applies to you An **AI feature review** covers terms changes for an AI feature. For a new product, the **app launch legal package** includes terms, privacy policies, and the consent flow together. --- # Can I train or fine-tune a model on my users' data? Source: https://mandatelaw.ai/guides/training-models-on-customer-data.html Updated: 2026-11-12 ## Short answer Sometimes, but having the data lawfully does not by itself give you the right to train on it. What decides it is why the data was collected, what you promised users, whether the data is sensitive, and whether you hold it as a service provider for business customers. The most serious risk is that a model trained on data you had no right to use may have to be deleted, not just the data. ## Three different activities Don't treat these as the same thing. Each needs its own legal basis. - **Inference**: using a user's data to perform the task they asked for. - **Customer-specific improvement**: tuning the product for one customer, within the permissions that customer granted. - **General training**: using one user's or customer's data to improve models or services for others. The first is usually covered by providing the service. The third almost always needs separate permission. ## What decides it ### What you promised when you collected the data Your privacy policy, consent screens, app store privacy labels, and marketing all count. In 2024 the FTC warned AI companies that their privacy commitments cover how they collect, keep, share, and train models on customer data. It also warned that quietly or retroactively changing privacy terms to allow AI training of data already collected could be unfair or deceptive. No single federal rule requires opt-in consent for every change, but expanding the use of existing data in a way that contradicts earlier promises can violate the FTC Act. Clear notice and affirmative consent are often what it takes to avoid that, and an updated policy alone may not make an earlier unauthorized use lawful. ### Contracts with business customers If you sell to businesses, their contracts and data processing addenda usually limit what you can do with their data, often to providing the service. Training a shared model on one customer's data, which can then help other customers, typically needs explicit permission in the contract. ### Health care customers and HIPAA If you handle patient information for a HIPAA-covered provider, your business associate agreement controls. You may use protected health information only as the agreement and HIPAA permit, and a training clause in your general terms cannot override that. Generating the clinical note a provider asked for is different from using that encounter to improve a model for other customers; the second needs its own analysis, and possibly de-identification. ### Sensitive data under state privacy laws Most states with comprehensive privacy laws require opt-in consent before processing sensitive data, including Virginia, Colorado, Connecticut, Oregon, Texas, Montana, Delaware, New Jersey, Tennessee, and Maryland (which adds data-minimization limits). California instead gives users a right to limit certain uses of sensitive data, and Utah and Iowa rely mainly on notice and opt-out. Connecticut's July 2026 amendments tightened limits on processing sensitive data and on materially new uses of existing data. Specialized laws such as Washington's My Health My Data Act and COPPA add their own requirements. ### Purpose limits in privacy laws Several state privacy laws, and the GDPR for EU users, limit use of personal data to purposes compatible with what users were told. General training is often not compatible with the original purpose. ## The model-deletion risk The FTC has repeatedly required companies to delete not only improperly collected data but the models and algorithms built from it: - **Everalbum** (2021): facial recognition models built from users' photos. - **Weight Watchers / Kurbo** (2022): algorithms derived from children's data collected in violation of COPPA. - **Edmodo** and **Ring** (2023): models and algorithms derived from improperly collected children's data and improperly accessed videos. - **Rite Aid** (2024): data, models, and algorithms from its facial recognition system. - **Avast** (2024): browsing data and the models, algorithms, and products derived from it, with $16.5 million in monetary relief. These were cases about deceptive or unlawful data practices, not rulings that AI training is itself prohibited. But if a model is central to your product, the legal basis for its training data is a business-continuity question, not just a compliance one. ## Ways to make training workable - Ask for consent going forward, separately from the terms, with a real choice. Train only on data from users who agreed, and keep the permission auditable. - Offer business customers an opt-in, often with something in return. - Use properly de-identified or aggregated data, but be careful: data that can be re-identified, or text that contains personal details, is still personal data. - Keep raw training data only as long as needed. - Make sure your model provider cannot use customer data beyond the purposes you authorized. - Record which data went into which model version, so you can honor deletion requests and prove what you used. ## Checklist an agent can run against the codebase - [ ] Find every pipeline that exports user data for training, fine-tuning, evaluation, or prompt examples, and classify each as inference, customer-specific, or general training. - [ ] List the data categories each pipeline uses and flag sensitive categories. - [ ] Check whether the pipeline filters by a consent flag, and where that flag is set. - [ ] Check whether training datasets and model versions are recorded so data can be traced to models. - [ ] Check the model provider's settings for training and retention on your data. - [ ] Compare the results to the privacy policy, consent screens, app store labels, customer contract templates, and any business associate agreements. ## If this applies to you An **AI feature review** covers training plans, including consent, contract changes, and a build spec for consent-gated training pipelines. Adding training to an existing feature is a **pre-build feature check**. --- # Does Washington's My Health My Data Act apply to my app? Source: https://mandatelaw.ai/guides/washington-my-health-my-data-act-apps.html Updated: 2026-11-12 ## Short answer Probably, if your app collects anything about a user's physical or mental health and people in Washington can use it. The law has no revenue or user-count threshold, so small apps are covered too. It also allows private lawsuits through Washington's Consumer Protection Act, which makes it riskier than most state privacy laws. The law has not been amended since it was enacted in 2023. ## Who it covers The law applies to a "regulated entity": a business that operates in Washington or offers products or services aimed at Washington consumers, and that decides why and how consumer health data is collected. A "consumer" includes Washington residents and anyone whose consumer health data is collected in Washington. A consumer app available nationwide usually meets both tests. Specified HIPAA-regulated information and data covered by certain other federal laws are exempt. Most consumer apps are not covered by HIPAA, and the law reaches health data that HIPAA does not, so HIPAA compliance alone is not a complete answer. ## What counts as consumer health data The definition is broad. It covers information that is linked or reasonably linkable to a person and identifies their past, present, or future physical or mental health. Examples include: - conditions, symptoms, diagnoses, and treatments - medications and supplements - bodily functions, vital signs, and measurements - mood, mental health, and emotional state - reproductive or sexual health information - biometric and genetic data - precise location that could show someone seeking health care - **inferences** about health drawn from other data A mood tracker, a medication reminder, symptom notes, sleep logs, and a "health" section in a journaling or planning app can all qualify. ## What the law requires - **A separate consumer health data privacy policy**, with a link to it prominently on your homepage. It cannot simply be folded into your main privacy policy. - **Consent to collect.** The law requires specific, informed, opt-in consent, separate from acceptance of your terms, except to the extent the collection is necessary to provide a product or service the consumer requested. The exception is limited to that necessary processing. It does not cover unrelated uses such as advertising, profiling, or AI model training. Because "necessary" can be disputed, many apps ask for consent anyway. - **Separate consent to share** health data, subject to the same exception for sharing necessary to provide the requested service. Sharing with a processor under a binding contract is treated differently. - **A signed authorization to sell** health data, with specific required contents. Consent in your terms of service is not enough. Most apps should simply not sell it. - **Consumer rights**: to confirm and access their data (including a list of third parties it went to), to withdraw consent, and to delete. Respond without undue delay and within 45 days of receiving the request. Verifying the user's identity does not extend that deadline. One 45-day extension is allowed when reasonably necessary, if you tell the user why within the first 45 days. You also need an appeal process for refusals. - **Backups.** Deletion from archived or backup systems may be delayed, but by no more than six months after the deletion request is authenticated. This is not an extension for deleting live data. - **Processor contracts** with vendors that handle health data for you. - **Access limits and data security** appropriate to the sensitivity of the data. - **No health-related geofencing.** You may not set up a geofence within 2,000 feet of the perimeter of a place that provides in-person health care when it is used to identify or track people seeking care, collect their health data, or send them health-related messages or ads. This has applied since July 23, 2023. It is not a ban on all location technology near medical facilities. ## Nevada and Connecticut Both have consumer health data laws of their own, but they are not copies of Washington's. - **Nevada** (SB 370, effective 2024) uses a similar opt-in consent model and restricts geofencing within 1,750 feet. It has no private right of action. - **Connecticut** added consumer health data protections to its privacy law in 2023, including limits on selling health data and on geofencing within 1,750 feet of specified facilities. The Attorney General enforces it. A design that meets Washington's requirements usually covers most of theirs, but check the differences. ## Enforcement so far Enforcement has developed more slowly than many expected. Washington's Attorney General has described a measured approach while the law is new, and no public enforcement judgment or settlement under the Act had been announced as of this guide's date. Private plaintiffs are testing it: a consolidated case against Amazon over its advertising SDK ended in voluntary dismissals without a ruling on the Act, and a 2025 case against a telehealth company remains pending. Courts have not yet given much guidance on how the law will be read. ## Checklist an agent can run against the codebase - [ ] List every field, screen, and integration that stores health-related information, including free-text fields where users are likely to write about health, and any place the product infers health information. - [ ] Confirm whether that data reaches your servers or stays on the device. - [ ] Check whether onboarding has a health-data consent that is **separate** from terms acceptance, unchecked by default, and recorded with a timestamp and the exact wording shown. - [ ] List every use of health data beyond providing the feature the user asked for (analytics, advertising, model training) and flag each one. - [ ] Check that a user can withdraw consent in Settings as easily as they granted it, and what happens to existing data when they do. - [ ] Check that no analytics, crash-reporting, or advertising SDK receives health data, including through session replay or autocapture. - [ ] Check what deletion removes and how long backups keep it. - [ ] Check for any geofencing around health care locations. - [ ] Find the consumer health data privacy policy link on the website homepage, in the app, and in the app store listing. ## If this applies to you If you are launching, the **app launch legal package** covers the consumer health data policy, the consent flow, and a build spec your agent can implement. If you already have policies and are adding a health feature, a **pre-build feature check** covers that one change.