Kingsfield
Two products How it works PII Tokenizer Writing
Connect the Judge
Kingsfield · Trust posture

The math is the artifact, not an auditor's letter.

Why a SOC 2 report does not answer the privilege question for legal AI.

When you send a matter to a cloud AI tool, the vendor hands you a SOC 2 report and the conversation is supposed to end there. It shouldn't. A SOC 2 report attests that one vendor followed its own controls during an audit window. Your client's confidences travel much further than that one vendor. Follow the path a single prompt actually takes.

WHAT A SOC 2 REPORT ATTESTS — ONE VENDOR, DURING THE AUDIT WINDOW the red path is your client's PII, in the clear, the entire way PERSISTENT STORE PERSISTENT STORE ...and every sub-processor each layer calls OUTSIDE THE SOC 2 BOUNDARY — THE LETTER IS SILENT ON THESE CDN WAF provider hyperscaler compute GPU operator logging platform billing database moderation API Your prompt + client PII names, matter facts, account numbers 01 API gateway TLS / WAF / auth / rate-limit / validate ~5ms 02 Load balancer Envoy / NGINX to GPU clusters ~2ms 03 Tokenization text to BPE token IDs ~3ms 04 Model router capability-aware queue 05 Inference engine prefill / KV-cache / decode / GPU 250-300ms THE MODEL IS ONE LAYER 06 Post-processing sampling + safety models + format ~5ms 07 Response & billing usage written to data warehouse 08 Logging & observ. request body + ids + timestamps logged Answer returns and the prompt now rests in logs & caches

One prompt, ~400ms, fourteen infrastructure layers. The model is one box on the path. Your client's PII rides through, and comes to rest in, the rest, plus every sub-processor outside the dashed line. A SOC 2 report covers the front-most vendor. It does not cover the journey.

Why the letter doesn't answer the question

A SOC 2 Type II report is a real document about a real thing. It is just not the thing a privilege analysis turns on. Four reasons.

01The PII doesn't stop at the vendor boundary.

Once the prompt enters the API gateway, it travels to every sub-processor each subsystem depends on: CDN, WAF, hyperscaler compute, GPU operator, logging platform, billing database, moderation API. The vendor's SOC 2 report says nothing about what those parties do with the bytes once they arrive.

02Each layer is a real handler with its own breach surface.

The observability pipeline logs the request body. The billing warehouse records token-level usage. Both are persistent stores of prompt content that live outside the model, and each inherits the trust posture of whoever operates it.

03The safety boxes are themselves models.

The moderation and safety-filter layers ingest the prompt to classify it. Each is its own model, with its own training-data retention, its own sub-processor chain, and its own audit boundary. The vendor's letter does not bind them.

04A past audit window does not cover this morning's call.

SOC 2 Type II is retrospective and periodic. A busy firm puts tens of thousands of prompts through this pipeline between audit periods. The attestation describes processes that existed at audit time, not what touched the specific bytes of your privileged document today.

What Kingsfield does instead

We do not try to win the attestation contest. We remove the thing the attestation was invented to reassure you about.

A cloud legal-AI tool

Client PII enters layer 1.

The raw prompt, identifiers and all, crosses into the pipeline above. Every box, every log, every sub-processor handles it. The SOC 2 letter is the only thing standing in for inspection, and it covers one box.

Kingsfield

Only tokens enter layer 1.

Client identifiers are stripped on your own machine before anything leaves, and a fail-closed firewall rejects anything PII-shaped at the judge's door. Every box on the path still runs. None of them sees the client's PII, because what entered the gateway was already tokens.

Two gates, both outside the cloud. A tokenizer on the lawyer's own computer strips client identifiers before egress, and a lawyer-confirmed egress gate shows the outbound payload before it sends. At the judge's ingress, a default-deny firewall rejects any submission in which PII is detected. The cloud holds no token-to-PII map, so client names are restored only on your machine, on a clean verdict.

Nothing to attest, because nothing is there. No client matters, documents, or PII are stored in the cloud. A tenant is an authentication identity and a usage counter. The one durable record is the PII-free Audit Capsule chain. That is why the DPA's scope is near-empty by design: it is a selling point, not a gap.

The artifacts

A firm doing diligence does not have to take the architecture on faith. These are the documents that back it.

Data Processing Agreement

Near-empty scope by design, because no PII reaches the cloud. A working draft, open for review.

Draft · available now
Privilege opinion

An independent outside-counsel opinion on whether the architecture preserves privilege and work-product.

Forthcoming
Audit Capsule

Every verdict signed and hash-chained, content-addressable, and PII-free. Verifiable without trusting our tooling.

Shipped
PII Tokenizer

The local application that strips client identifiers before egress and holds the map on your machine.

The first gate

Read the architecture in one line

They can publish a diagram of every system your client's PII passes through before the model even sees it. We send the model tokens instead.

See how it works Contact WalkerNash
Kingsfield

The judge for legal AI.
A WalkerNash Development LLC product.

© 2026 WalkerNash Development LLC. All rights reserved.
Built in the United States. No third-party trackers.
Product
  • Two products
  • How it works
  • Audit Capsule
  • Practice areas
  • Cloud Judge · MCP
  • PII Tokenizer
For Firms
  • Pricing
  • Privilege opinion
  • DPA
  • Verified attorneys
  • Status
Company
  • About WalkerNash
  • Crucible (compliance)
  • Writing
  • Trust posture
  • Contact
  • Careers
  • Press
v0.9.4 · 2026.05.26kingsfield.ai