Neody is a framework for using regulated data with large language models. Card numbers, patient records, inside information and customer PII are protected field by field, before any model sees them. The model works on format-preserving stand-ins; only the people and systems you approve ever see the real values — and every access is on the record your examiner will ask for.
Every claim on this page is enforced by a test that gates our build. If a test is ever disabled, the claim comes off this page the same day.
Card 4111 1111 1111 2847
Cardholder Maria Lopez
SSN 123-45-6789
statement.pdf (scanned)
Draft: refund $412.60
Card 4111 11XX XXXX 2847 pv_01HX…
Cardholder [PII:name#a1]
SSN [PII:ssn#b7]
statement.pdf → 14 spans protected
Draft: refund $412.60
PCIPII
“Start PCI-free with KYC or TPRM. Add card data when the on-premises protection zone is live.”
PHI · HIPAAPII
“Prior auth and fraud on PHI, with the minimum necessary enforced per field.”
MNPIPII
“A deal wall that's enforced, not a policy — with detection limits stated plainly.”
PCIPII
“The model works on card-number stand-ins that still validate and match — never the card itself.”
PIIPCI
“Review the whole loan file without the model ever seeing who the borrower is.”
PIIPCI
“Player identities and payment details stay protected, case after case.”
Encrypting a whole document makes it useless to a model; redacting it removes what the model needs. Neody protects individual values and leaves the structure readable.
Each value carries its data class — PCI, PHI, MNPI, PII, trade secret — inside documents, emails and tool calls, including scanned PDFs, verified by re-extraction.
The model gets format-preserving tokens and short references — a tokenized card number still validates and joins, but it isn't the card. The model never handles ciphertext.
Per data class and per agent: platform-managed, per-agent keys, or sealed so the platform itself cannot read it. Written into the agent's charter and enforced — not configured.
Nothing unprotected crosses the egress boundary. Destinations come from a list your institution approves; keys are per tenant, customer-held and revocable.
Ours, your vendors' or your own: autonomy earned on measured agreement with your reviewers, and one evidence record per field, ready for model risk, third-party risk and audit.
Card numbers are protected on your premises before anything reaches Neody.
The goal is that Neody stays out of your PCI scope: cardholder data is sealed so the platform cannot read it, and the model sees only a format-preserving stand-in.
Available. We say “out of your PCI scope” only with a QSA scoping opinion in writing — ask us about its status.
Minimum necessary, enforced per field, per agent.
Each agent sees only the PHI its task requires, on stand-ins wherever possible; every access is recorded with its purpose.
Available. HIPAA is a contract as well as controls — ask us about BAA readiness and terms.
Only the deal team's agents see the deal.
Access scoped to named people and data classes, wall-crossing and restricted lists enforced at run time, and a record of who saw what and when.
We detect MNPI and enforce barriers — and state the limits plainly: there is no checksum for materiality.
The model reasons over stand-ins, not your customers.
Names, SSNs, account numbers and addresses are tokenized consistently, so the model can still match and compare records without seeing who they are.
Available.
Every statement on the left is enforced by a test that gates our build. If that test is ever disabled, the claim comes off this page the same day.
| We say | We don't say |
|---|---|
| Regulated data is protected before it reaches a public model, and nothing unprotected crosses the egress boundary | “End-to-end encrypted” — we run the agents, and at some tiers we decrypt to process |
| Cardholder data never leaves your premises unprotected | “We never see your data” — true only for sealed data classes |
| Per-tenant keys, customer-held and revocable | “Your data never leaves your building” — impossible while we run your agents |
| MNPI detection plus barrier enforcement, with the limits stated in the product | That MNPI is reliably detectable — materiality has no checksum |
| Sealed data classes make us unable to read a value | That per-agent keys keep data confidential from us — they limit the blast radius of a key compromise |
We map every field — its class, who can read it, where it goes — in a Data Path Report before anything runs, then pilot in shadow mode alongside your reviewers and measure how often they agree.