Your data gets redacted before it leaves, and you get a receipt that proves it.
AYA Privacy-Boundary enforces a fail-closed privacy boundary on everything that leaves your perimeter: consent verified, PHI and PII scrubbed, the egress route itself scanned for leak paths, and an audit receipt written for every send. Built on AYA's local-first architecture (redaction and vault on the device, bring your own keys, the mesh only ever sees tokens), because privacy that lives in a policy document is not privacy.
Book a boundary assessment Read why local-first is doctrine
THE PROBLEM
Your team wants to use LLMs, and your data does not want to travel. Every prompt is a potential disclosure: a patient identifier in a summarization call, customer PII in a support draft, a health detail in a transcript that went to a provider nobody checked for a BAA. The policy says "we redact," but nothing enforces it at the boundary, and nothing proves it happened. So when a compliance officer, a health customer, or an auditor asks the real question, show me that no unredacted identifier left your perimeter, the honest answer is a shrug and a screenshot of the policy. Meanwhile the 2026 state privacy patchwork keeps landing (Indiana, Kentucky, and Rhode Island comprehensive privacy laws took effect January 1, 2026), and healthcare buyers increasingly have to show where patient data went, not just that someone meant well.
HOW IT WORKS
Privacy-Boundary is an enforced pipeline, not a promise. Four gates, in order, and the first three fail closed (if a gate cannot run, the send is denied, never waved through):
- Consent, verified. Before anything moves, Bouncer checks that the user actually granted consent for this egress scope (this LLM call, this ticket filed, this email sent). No consent, no egress. - PHI and PII, scrubbed. The payload is scanned for identifiers (SSNs, medical record numbers, labeled dates of birth, patient names, NPIs, health plan IDs) and either rejected or redacted, your choice per lane. - The route, scanned. The boundary claim covers the road, not just this payload. The egress code paths are scanned for leak routes: unredacted LLM calls, providers without a signed BAA, patient data in logs and exception text. This scanner exists because we caught our own near-miss and turned it into rules. - The receipt, written. Every enforced egress writes an audit entry: who, what scope, what was scrubbed. The ledger is the answer you hand the auditor.
Underneath sits the architecture: redaction and the vault live on the device, keys stay in device secure storage and call your provider directly (BYOK), and the mesh receives tokenized payloads only. Server-side scrubbing is defense-in-depth, not the perimeter.
WHAT YOU GET
- A fail-closed privacy boundary (AYA-3SPN-BOUNCER-PRIVACY-BOUNDARY-v1): consent gate, PHI/PII scrub, leak-path scan, and audit receipt, composed from atoms that already run in AYA's engine. - A leak-path report over your egress code: every route where an unredacted identifier could reach an external provider, log, or exception trace, mapped to the HIPAA 18-identifier set. - A receipt ledger, the standing artifact that answers "show me nothing unredacted left" with entries instead of assurances. - The local-first architecture as an option, not a lecture: on-device redaction policy and PII gazetteer ship as data (overlays), so tightening the boundary is an edit, not a rebuild.
WHO IT IS FOR
Healthcare-adjacent teams first: digital health startups, clinics adopting AI scribes, care-coordination platforms, anyone who must keep PHI inside a HIPAA boundary while using LLMs. Also privacy-serious consumer-AI builders who want local-first as a selling point rather than a roadmap slide, and teams staring down the state privacy patchwork. It sits next to AYA Red Team (AEGIS, the break-in team) and AYA Agent-Sentinel (mesh integrity) as the data-protection member of the AYA security line.
PRICING
Prices are hypotheses we are validating, not commitments.
- Pilot. A boundary assessment on one egress lane: your payload samples through the scrub, your egress code through the leak scanner, findings plus receipt ledger delivered. - Subscription. The boundary enforced continuously on every egress, with the ledger as your standing audit artifact and alerts on any leak-path regression. - Platform. The full local-first stack as your architecture: on-device redaction and vault, BYOK keys in device secure storage, tokenized-only mesh, with the server boundary as defense-in-depth.
A product is only sellable once its deliverable runs with a receipt. The atoms are real and already on disk; a live enforced run on your lane is scoped with you first.
PROOF (we dogfood this)
Local-first is AYA's own doctrine, not a feature we bolted on for this page. Our own architecture keeps redaction and the vault on the device, keys in device secure storage, and hands the mesh tokens. The PHI scrubber this product composes is the same atom that guards AYA's own external bug-report path, and the leak-path scanner encodes rules we wrote after catching our own near-miss (audio headed to a provider without a BAA, found and stopped in review). We built the boundary because we needed it first.
HONEST NOTE
What is true: the four composed capabilities (consent verify, PHI scrub, leak-path scan, tokenization audit) are real, verified files in the pattern engine, and the new boundary span that composes them is PQS-validated (93, grade A). The client-side redaction policy and PII gazetteer exist as data overlays. What has not happened, and we will not pretend it has: a live end-to-end enforced egress with a customer payload producing a receipt as part of this launch build. That needs a booted mesh, and the roadmap flags a span-misalignment bug in the client redaction gate that gets fixed before we sell the on-device tier as running. When the first real boundary run produces its first real receipt, the receipt is the proof, and we will show it.
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*