# Agentsmith A portal that helps a lawyer, a licensed investigator, or the agents working for them learn whether the other side is using stolen data about one client, and prove it. Status: under development. Waitlist open. This document is the canonical machine-readable description; the HTML page at https://agentsmith.law/ says the same things for people. ## The problem A party in litigation or negotiation learns facts about the opponent that appear nowhere in the record: an old password, a document that lived only on a laptop, a private message. The likely source is a data-breach dump or an infostealer log traded on dark-web markets and Telegram. Ethics rules generally do not require the receiving lawyer to say where it came from. Courts can preclude its use, even against counsel who did nothing wrong, but only on proof of provenance. Portals into leaked data exist for corporate threat teams and police. None ties a marker the client planted to its appearance in a leak and then to the adversary's use, with lawful sources ruled out. That correlation is the product. ## Who uses it, and on whom - Users: a lawyer, a paralegal employed by one, a licensed investigator, or an AI agent operated by one of them. - Subject: exactly one named client, with a signed authorization on file. Queries run only on that client's own identifiers. - Never a subject: the opposing party, witnesses, or opposing counsel. Looking them up would retain stolen property, create data-protection duties toward strangers, and hand the other side the provenance argument this portal exists to make. - The client pays, through the lawyer, so the work sits under counsel's engagement and work-product protection. ## Method, in order 1. Baseline. Pull the client's own records from licensed breach engines by API. Hash and timestamp every pull into an immutable store. Sequester anything that is not the client's own, unread. Label each field as breach-only (passwords, security answers, registration IPs, infostealer machine artifacts) or people-search-available (old addresses, phones, relatives). Only breach-only fields can carry an opinion. 2. Seed. Issue true, unique markers, one per channel: a real email alias, a real phone number, a real document, each given to exactly one counterparty or stored in exactly one place. The portal ranks channels and counterparties by breach likelihood and seeds lawful channels too, so a marker that surfaces names its own path. Nothing false, nothing hidden, nothing in a court filing, nothing posted to a dark-web source. 3. Watch. Query licensed breach engines and dark-web crawl archives for the client's identifiers and every marker. Alerts carry date, source, and content. Message contents are stripped. 4. Compare. Read the other side's filings, letters, and discovery against the baseline and the marker register. Pull every lawful source on a dated capture and check it. Rule out compromise of the client's own accounts. A person signs a report built for Rule 702 and its state analogs, with a motion kit for the remedies a court can actually grant. ## Design rules - Never searches anyone but the authorized client. - Never plants a false fact. Every marker is true. - Never hides a tracking beacon. Per-recipient marks are disclosed. - Never buys a dump, never directs a vendor to, never posts to a dark-web site. - Never uses a found credential. - Never files what an AI drafted. The AI labels, triages, and drafts. A person signs. - Holds no breach corpus of its own. Data is licensed per query from established archives and cached per client for that client only. ## Why it works as evidence - Planted data has long been accepted as proof of copying and provenance (fictitious directory entries, seeded databases, single-recipient posts). - Breach-only data classes cannot come from any lawful source. - Seeding lawful channels alongside illicit-prone ones converts a negative proof ("no lawful source could have supplied this") into a positive one ("the marker that surfaced names its path"). - Old addresses, phone numbers, and relatives are never treated as evidence; any people-search site sells them. ## Interfaces for agents - `GET https://agentsmith.law/llms.txt`: short index. - `GET https://agentsmith.law/llms-full.txt` or `GET https://agentsmith.law/` with `Accept: text/markdown`: this document. - `GET https://agentsmith.law/.well-known/agent-card.json`: JSON card describing the site and its one skill. - `GET https://agentsmith.law/waitlist`: JSON Schema for an inquiry. - `POST https://agentsmith.law/waitlist` with `Content-Type: application/json`: submit an inquiry. Required: `name`, `email`, `role` (one of lawyer, investigator, client, agent, other). Optional: `organization`, `jurisdiction`, `situation`, `agent` (`name`, `operator`). Returns 201 `{"ok": true, "id": "..."}` or 400 with `errors`. Example: ``` curl -X POST https://agentsmith.law/waitlist \ -H "Content-Type: application/json" \ -d '{"name":"Jordan Lee","email":"jordan@example.com","role":"agent","organization":"Lee Family Law","jurisdiction":"Oregon","situation":"Client keeps hearing facts from opposing counsel that are not in the record.","agent":{"name":"intake-assistant","operator":"Lee Family Law"}}' ``` Do not include anyone else's private data in an inquiry. A person replies to the email given. Sending an inquiry creates no attorney-client relationship. ## Operator Agentsmith is a project of Newman Brunk, a law firm. Nothing in this document is legal advice.