Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Prepare a Court Filing Without Seeing the Client's Identity?
Yes, when the caption and signature block render a handle such as CLIENT_001 and the client's name resolves only at submission, because drafting and formatting work on the facts and the law. Ask what the model receives from the drafting screen and which named person approves the filing.
A litigation team assembles every court filing from a caption, a body of facts and law, a signature block, a certificate of service and the exhibits. The caption names the parties and the court; the body argues. An agent can format the document, check the elements of the claim, cite the authorities and draft the certificate of service, and none of that work turns on the client's name as a value. The name is a field. A firm that hands the draft to an agent has to decide where that field lives: on the page the model reads, in the matter record beside it, or in a filing system that resolves it when the document is submitted. The stakes are concrete. A complaint filed under the wrong party name is a public error, and a client's date of birth printed into a public docket is a harm the court's own rule tries to prevent (U.S. District Court, 2026). The duty to redact sits with the filer rather than with the clerk, so a firm cannot rely on the court to catch a name the model should never have held. The record here is one filing whose caption resolves at submit, and the question is what the drafting screen gives the model while it writes.
Key findings
- For a court filing to be prepared without the model holding the client's identity, the values on the rendered drafting page would have to be replaced with consistent tokens before any model reads it, so the caption, signature block and service list carry CLIENT_001 for the whole run (What Is Render-Layer Tokenization?).
- It would also require a named person approving the submission and a record of the screen the model received, because a filing becomes a public act the moment the court accepts it (What Is an Approved Destination for AI Agent Output?).
- The gap sits in the drafting tool: the caption is typed into the document before the filing step, and the court places the redaction duty on the filer rather than on any system that could catch the value first (U.S. District Court, 2026).
- Persona's documentation defines an inquiry as "a single instance of a Persona identity verification flow" whose details are "wrapped in an inquiry object," so the identity check can complete in a system the draft never opens (Persona, 2026).
- Stripe separates a "document" check from an "id_number" check and keeps the result behind "restricted API keys" that cover "verifications processed in the last 48 hours," a rule about who may read the identity rather than about what the drafting screen shows (Stripe, Access, 2026).
- Harvard's guidance asks teams to "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible," which a filing is (Harvard University Information Security and Data Privacy, 2026).
What does an agent read when it drafts a filing?
The drafting surface is a document and a panel. The document holds the caption, the body, the signature block, the certificate of service and the exhibit list; the panel holds the matter record, with the client's name, the matter number and the parties. An agent asked to draft a motion reads both, because the page draws both. It reads the caption at the top of every page, the client's name in the signature block it is formatting and the service list it is copying, whether or not the sentence it is writing needs any of them. Of the 15 AI agents and 86 AI security products reviewed, none describes replacing the values on a page with tokens the agent can work with, so a caption that renders the client's name reaches the model as text (Do AI Agents Ask Before Making a Payment?).
The work itself is the facts, the elements of each claim, the authorities and the format the court requires: the jurisdiction and venue paragraph, the numbered allegations, the prayer for relief, the certificate that a copy went to opposing counsel. An agent can check each element, format the caption page, correct the citation style and draft the certificate, and the client's name is a string it copies rather than a fact it reasons about.
| Part of the filing | What it holds | What the drafting task needs | What the model receives on a normal screen |
|---|---|---|---|
| Caption | Court, parties, case number, document title | The court, the case number, the document title | The client's full name, on every page |
| Body | Jurisdiction, facts, claims, prayer | All of it | The narrative, including any identifier written into it |
| Signature block | The signer's name, bar number and address | The attorney's details | The attorney's details, and the client's name on a verification |
| Certificate of service | Who was served, at which address | The method and the date | The client's address |
| Exhibit list | The documents attached | The list and the exhibit numbers | Exhibit titles and any identifier in them |
Least privilege does not change the picture, because it governs the actions and credentials an agent holds rather than the content of the page it reads (What Is Least Exposure?).
The documents the agent reads to draft carry a second risk. An intake memo, a demand letter or an exhibit can hold instructions as easily as facts, and EchoLeak showed a production client that "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025). A defense at the agent-tool interface performs well on the benchmarks: the paper describes "a simple, modular, and model-agnostic defense operating at the agent-tool interface" that "achieves perfect security with high utility across all four public benchmarks: AgentDojo, Agent Security Bench, InjecAgent and tau-Bench" (Bhagwatkar et al., 2026). The same paper finds the benchmarks easy to saturate, so the useful question is what an injection collects when a defense misses. A model holding CLIENT_001 gives it a token.
Which fields on a filing screen carry the client's identity?
Four parts carry the client's identity, and they carry different values. The caption carries the party names. The body carries whatever the facts require: an employer, a date of birth, the last four digits of an account, the name of a minor child. The signature block carries the signer and, on a verification or an affidavit, the client's own name and address. The certificate of service carries the address where the client was served.
The court's rule already treats most of that as values to remove. It lists Social Security numbers, financial account numbers, dates of birth and the names of minor children as values that "must be partially redacted from the pleading, whether it is filed traditionally or electronically," and it places compliance on the filer: "The Clerk will not review each pleading for redaction" (U.S. District Court, 2026). Partial redaction keeps the pleading usable while the full identifiers sit in a sealed reference list.
That is the court's own version of a token and a resolution list, and it is the shape a drafting screen can borrow. The party name in the caption is the value the filed document usually keeps, because the docket is public and the parties are named on it. The identity a firm is protecting from a vendor is the full record behind that name: the date of birth, the account, the medical detail, the minor's name, the address in the service list.
Identity verification has its own flow, which is the subject of the vendor pages below. Filling a field from a store while the model sees a placeholder is documented for browser agents (Can a Browser Agent Fill In a Form Without Seeing the Values?), and the same arrangement applies to a caption field that resolves from a party record. The caption can carry CLIENT_001 while the party record holds the name, and the filing system can join them at submission.
What do the vendors themselves say?
Persona documents the identity half as an object with a status. An inquiry is "a single instance of a Persona identity verification flow," and its details are "wrapped in an inquiry object"; the approved, declined and needs_review states "contain results for you to use" (Persona, 2026). The result is retrieved from the dashboard, the Retrieve an Inquiry API or a webhook, so a firm can hold a verified status without printing the underlying document into a draft. The page does not say which fields another system draws from an inquiry, and a reader should not assume it does.
Stripe documents the check as a session with a type. The "document" type verifies "the authenticity and ownership of government-issued identity documents," and the "id_number" type verifies "a user's name, date of birth and national ID number" (Stripe, Sessions, 2026). Redaction leaves the session record in place with "placeholder values in all fields that previously contained personally identifiable information," and "Redaction can take up to 4 days" (Stripe, Sessions, 2026). Access to those fields runs through "restricted API keys," which cover "verifications processed in the last 48 hours," and document and selfie links "must expire within 30 seconds" (Stripe, Access, 2026).
| Vendor | What its documentation states | What a buyer should verify |
|---|---|---|
| Persona | An inquiry object with approved, declined and needs_review states that hold results | Which fields a drafting tool or a matter record draws from the inquiry |
| Stripe | A document or id_number session, redaction with placeholders, restricted keys | Whether the drafting tool can reach the verified outputs at all |
Both pages govern where the identity result lives and who may read it. Neither describes a drafting screen that renders a token in a caption, and a firm that reads only the identity vendor's page will conclude the problem is solved when the verification is done. The verification settles who the client is; the drafting screen settles what the model holds while it writes.
Who approves the filing before it is submitted?
A filing is an externally visible act with a short reversal window. Once the court accepts it, the document is on the docket and a correction costs a motion. Harvard asks teams to "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard University Information Security and Data Privacy, 2026). The OpenAI governance paper calls human approval "a standard way to limit egregious failures," asks that "at least one human entity is accountable for every uncompensated direct harm," and adds that "Actions that can only be reviewed after the fact should be more easily reversible" (Shavit et al., 2023), which a filing is not.
The role question is the one a firm answers on its own systems. BILL's help center describes a role set in which "A Payer cannot enter or approve bills" and the Clerk role "is permission to only enter bills" (BILL, 2026). The Accountant role "is not able to manage users or view/manage banking information," which keeps the record and the money apart (BILL, 2026). The product is a payables system rather than a court, and the pattern it documents is the one a filing needs: the person who drafts is not the person who submits, and the person who submits cannot edit the record of what was approved.
The approval belongs to a named person, not to a role. A permission slip is the reviewable form of a grant: service, resource, operation, destination, lifetime and approver on one page (What Is a Permission Slip for an AI Agent?). For a filing, the grant is narrow: one matter, one document, the court's filing system as the destination, and the attorney of record as the approver.
ABA Formal Opinion 512 states that lawyers "may not abdicate their responsibilities by relying solely on a GAI tool to perform tasks that call for the exercise of professional judgment" (ABA, 2024). A signature on a filing is that judgment, and an approval recorded against a person is the only version of it that survives a docket entry.
What record does the filing leave?
The court keeps a record of the filing, not of the run that produced it. The docket shows the document, the date and the party; it does not show the screen the model read, the token that stood in the caption or the person who approved the submission. A firm that wants to answer those questions has to keep its own record.
Harvard's guidance says to "Treat prompts, outputs, logs, and retained context as organizational data" (Harvard University Information Security and Data Privacy, 2026), which places the drafting transcript in the same category as the file. AWS's guidance asks that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026), a property the firm's log needs before it can answer who filed.
The record has four parts: the screen as the model read it, with CLIENT_001 where the name would print; the token map or resolution list that connects the token to the client; the action, meaning the document that was submitted and the destination; and the approval, with the name and the time. A transcript alone answers none of them, because it shows what the model wrote rather than what the page drew. A sealed reference list at the court does the same job for the bench: the identifiers exist, but not in the public pleading.
What a hijacked agent can leak is bounded by what it holds. If the caption rendered CLIENT_001 and the record maps that token to a name the model never received, an injection can spread the token and nothing that resolves outside the firm's own store (What Can a Hijacked Agent Leak If It Only Has Placeholders?). That is the record to ask for, and it is the one a docket cannot supply.
What does a governed environment change?
The control sits at the render. Values a policy names are replaced with consistent tokens before the agent's view of a page is built, so the caption, the signature block, the service list and the matter panel all draw CLIENT_001 while the court, the case number, the claims and the facts stay readable. Consistency is the part that keeps the task intact: the same token follows the client through the draft, the exhibit list and the agent's own notes (What Is a Protected Browser for AI Agents?).
Real values resolve only at an approved destination, at the moment of an approved action. For a filing, that destination is the court's filing system at submission, after a named person approves the document. The caption page the court receives carries the real party name because the filing system resolves it there; the drafting screen the model read never did. The approval and the resolution are one step, which is what makes the record legible a year later.
Two limits belong with the claim. The control covers the pages the agent renders, not the local file system, not a direct API call and not the court's own database. A draft exported to a PDF and read back into the model puts the name in front of it again, which is why the export step needs the same policy as the screen.
The third limit is the narrative. A facts section can identify a client without ever printing a name, and a token in the caption does not touch that. The attorney reads the facts; the environment can flag an identifier a policy names, and it cannot decide whether a paragraph identifies the client. Masking has to be consistent to be useful (Does Masking Data on Screen Break Browser Agents?).
What the record shows
Replacing the caption, signature block and service list on the rendered drafting page with consistent tokens before any model reads it keeps the facts and the law readable and takes the client's identity out of the model's context, with the real name resolving only at the filing system after a named person approves the submission. The court already asks for partial redaction of the identifiers that matter most and puts the duty on the filer, so the handle and the resolution list are shapes a firm already maintains; what changes is extending the same idea to the whole drafting screen. The identity check can complete in its own system, the approval can sit with the attorney of record, and the record can hold the screen the model read. One motion tests the difference: draft the same complaint twice, once with the client's name typed into the caption and once with CLIENT_001, print the screen the model read each time, and compare what it held.
Methodology and limitations
This page rests on a court's privacy notice, ABA Formal Opinion 512, university guidance, vendor documentation from Persona, Stripe and BILL, two research papers, one governance whitepaper and two RedactSure pages. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
No product named here was tested for this page; all are described from documentation, and "not described in the pages reviewed" means the recorded facts for that page do not cover it: the court notice states a redaction rule for the filed pleading and says nothing about what a drafting tool renders. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a filing whose caption resolves at submit, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the firm's own screens.
Frequently asked questions
Can an AI agent prepare a court filing without seeing the client's identity?
Yes, when the caption, signature block and service list render a handle such as CLIENT_001 and the filing system resolves the real name at submission. The drafting work is the facts, the claims, the authorities and the court's format, and none of it needs the name as a value. On a drafting screen that prints the full caption, the model reads the name before it writes a word, and that screen is the one to change.
Which fields on a filing screen carry the client's identity?
The caption carries the party names, the signature block carries the signer and, on a verification, the client, the certificate of service carries the address, and the facts carry whatever the story requires. The court already requires partial redaction of Social Security numbers, account numbers, dates of birth and the names of minor children in the pleading. The party name is usually public; the identifiers and the address are the values to keep off the drafting screen.
What does the court require to be redacted from a pleading?
Social Security numbers, financial account numbers, dates of birth and the names of minor children must be partially redacted whether the pleading is filed on paper or electronically, and home addresses are redacted only in criminal cases. The clerk does not review each pleading for redaction, so the duty sits with the filer. A firm should read the notice for its own court, because the list and the criminal-case exception vary by district and by local rule.
Who approves the filing the agent prepared?
A named person, recorded against the document rather than against a role. A filing is externally visible and hard to reverse, which is the category Harvard's guidance puts behind human approval, and the attorney of record is the person whose signature the court reads. The reviewer needs the facts, the token and the destination, not a birth date, to decide whether the document should be filed.
What record should the firm keep of what the model read?
The screen as the model read it, the token that stood in the caption, the document that was submitted and the name and time of the approval. A transcript shows what the model wrote, not what the page drew, and a docket shows the filing but not the run. Exported to the firm's own monitoring, the four parts answer what the model held and who is accountable for the submission.
Does identity verification remove the need for a screen control?
No. Verification answers who the client is, and it can do that well or badly; it does not decide what the drafting screen shows when the agent opens the document. A verified client whose name, date of birth and address still print on the caption and the service list is verified and exposed at once. The firm needs both records, and only one of them sits in the identity vendor's system.
How RedactSure Keeps the Client's Name Off the Drafting Screen
A caption that prints the client's name puts that name into every step of the drafting run, and the court's redaction rule arrives after the fact. That duty sits with the filer, and the clerk does not review each pleading (U.S. District Court, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the model reads the caption, signature block and service list with the client's name and address, and they follow the draft into its notes. Inside: those fields render CLIENT_001 for the run, the facts and the court's format stay readable, and the filing system resolves the real name at submission after the attorney of record approves it.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A filing that prints the client's name gives the model a value it carries into later screens. Bring one filing your team prepares and see, with test values, the caption as the model reads it, the approval and the record. Book a demo