TrustLayer AI

Executive Summary

A clinician pastes a patient's name and diagnosis into a chatbot to draft an insurance letter. It's helpful. It's also a HIPAA incident — and no one in security will ever see it.

This happens thousands of times a day across every regulated enterprise. The tools meant to stop it — CASB, DLP, NGFW — operate at the application layer. They can allow an app or block it. They cannot read the sensitive sentence inside an approved prompt, or stop it without stopping everything.

TrustLayer can.

TrustLayer is an inline gateway between users and AI models that decides on every message. A four-layer pipeline classifies each prompt by sensitivity, redacts what shouldn't leave, keeps regulated content on a local model, and records every decision.

It governs the data boundary — not the model, not the app.

From invisible prompt to auditable decision. From "block the tool" to "govern the message."

Problem Statement

AI is the fastest-adopted workplace technology in history — and the least governed.

Cyberhaven's 2025 AI Adoption Report found that 34.8% of all corporate data employees paste into AI tools is now sensitive, up from just 10.7% two years earlier, and that 71.7% of the AI tools in use present high or critical data-security risk. IBM's 2025 Cost of a Data Breach Report found that 63% of organizations have no formal AI governance policy, and only 34% audit for shadow AI at all.

Two things in that data matter more than the headline. The sensitive share is accelerating — it roughly tripled in two years, so any control sized to today's volume is already behind. And much of this traffic moves through personal accounts no enterprise tool is watching. The problem isn't that employees use AI badly; it's that the useful thing to paste is often the regulated thing.

The stakes are highest exactly where governance is weakest. Healthcare has been the most breach-costly industry for fourteen consecutive years, averaging $7.42 million per incident and 279 days to detect and contain — and a single pasted patient record is all it takes.

Here is the mismatch at the heart of the problem: the unit of risk is the individual message, but the unit of control is the entire application. Security teams can allow an AI app or block it. What they cannot do is see the one sensitive sentence inside an otherwise ordinary prompt.

Why Existing Controls Fail

Organizations are left with three bad options:

Block AI outright — and employees route around it through personal accounts, creating exactly the shadow AI that governance was meant to prevent. This is the failure mode the Cyberhaven data already documents.

Allow AI freely — and sensitive data flows out unredacted and unlogged, or guarded only by a pattern-based DLP dictionary. Those tools match what can be listed in advance: regexes for account numbers, keyword lists, fingerprints. That catches a well-formed SSN but misses the sentence carrying the same risk without one — "the patient in 4B whose glioblastoma recurred after the second resection" is PHI, and no dictionary contains it. And built to block rather than repair, they leave only all-or-nothing enforcement: the prompt dies, the work stalls, the user opens a personal account.

Review manually — which cannot scale to the thousands of prompts an enterprise generates every day.

TrustLayer offers a fourth option: govern every message, automatically, inline.

Our Solution

TrustLayer evaluates every prompt at the content layer, through a four-layer inspection pipeline. What those four layers are, and why they are not one large model, is the core of the approach.

Layer 1. Entity detection. Microsoft Presidio finds named entities and PII spans with exact character offsets, so redaction can target the span rather than the whole message.

Layer 2. Deterministic validators. Luhn, NPI, and SSN checks confirm that a candidate identifier is real. There are no false positives and no model latency, and these checks resolve the common cases instantly.

Layer 3. Semantic classification. Structural checks cannot tell whether a passage is sensitive when no identifier is present at all, and this is the layer that catches the sentence no dictionary contains. Two zero shot natural language inference encoders read the text against the same hypotheses drawn from the governance catalog. DeBERTa-v3 and RoBERTa-large each score whether the passage constitutes protected health information, personal data, or confidential business content, and their per-hypothesis scores are averaged before thresholding. Averaging pulls a single encoder's spurious spike back toward the middle, since a lone high score is damped when the other reads the text as benign, and this is what lowered the false positive rate without giving up recall. Both are small BERT family encoders that run locally in milliseconds, and neither is a large language model.

Layer 4. Fusion and scoring. The signals from the preceding layers resolve into a single governed outcome. Detectors merge by union rather than by blending into one number: any detector that fires a label makes that label present, the reported confidence is the maximum across detectors, and attribution records which one fired it. The merged labels are then ranked by catalog priority, and each is checked against its score floor, which is configuration-owned and never set by a model. Execution across all four layers is cheapest first, so a confident deterministic hit resolves the prompt without invoking the encoders at all. Keyword-identifiable content stays fast, and the models earn their cost on paraphrased material where structural detection fails.

Extending coverage with label-specific models. Averaging two zero-shot encoders improves stability rather than reach. Both are entailment heads trained on overlapping inference corpora, so their errors are correlated, and agreement between them sharpens confidence on cases either could already resolve alone. What the pairing cannot do is extend into a domain neither model was exposed to. Clinical shorthand is where this becomes visible. A phrase such as pt c/o SOB, hx CABG, d/c'd on ASA contains no identifier and entails no plain language definition of protected health information, yet any clinician reading it would recognize the content at once. Both encoders miss it for the same reason, so a second opinion of the same kind does not help.

The architecture closes this gap with narrow models fine-tuned on a single regulatory category. A clinical model emits only HIPAA, an EU context detector emits only GDPR, and an identifier-focused precision head emits only PII. Each joins the classifier as an additional detector and participates in the same union at Layer 4, so adding one requires no gateway change. A specialist is never folded into the encoder average, because a fine-tuned model produces sharply peaked probabilities while zero-shot entailment scores are diffuse, and averaging across that difference would let a confidently incorrect specialist dilute a detection the encoders had already made correctly.

Three properties make the arrangement composable. Each specialist is independently tunable, so a threshold change affects one label and nothing else. Each is failure-isolated, so a broken specialist drops its own label from the union rather than taking down the gateway. And because the merge is a union with maximum confidence, adding a detector can only introduce a label or raise a score, never remove one or lower it. A new specialist therefore cannot regress a decision the system made before it was installed, which means validation scopes to the new component rather than to the whole pipeline, and precision and recall improve per label without retraining a monolith.

Label-specific models are a planned extension rather than a current capability. The ensemble already accepts additional detectors, so the integration path requires no gateway change, but no specialist has been trained or evaluated to date. Before one enters the live path it will be measured against a stratified evaluation set covering explicit identifiers, clinical shorthand, oblique health context, and hard negatives that resemble sensitive content without being it. Adoption depends on demonstrating that the specialist catches cases the encoders miss without raising the false positive rate.

Why a Layered Pipeline, Not One Big Model

The obvious build is to send every prompt to a large general-purpose model and ask whether it's sensitive. In a regulated environment that fails three ways.

It leaks. To ask a cloud model whether a prompt is safe to send, you have to send it the prompt. The check itself is the leak. So inspection has to run inside the trust boundary, which rules out the largest models.

It over-flags. A general model trips on text that merely resembles regulated language, and the user pays for it in needless redaction. We hit this ourselves: our zero-shot layer over-applied labels to long documents until we added length-aware thresholds.

It's expensive forever. Inference on a large model is a cost paid on every prompt, indefinitely. A small tuned encoder runs in milliseconds on ordinary hardware at roughly fixed cost.

A small model trained on one domain answers all three: it runs locally, it's accurate on the language it was trained for, and it's cheap enough to sit in the live path. Regulatory language is narrow and slow to change — the ideal case for a specialist over a generalist.

That points to where the defensibility compounds. Today the live path runs general NLI backbones, tuned per label and corroborated across two models — enough to reach 0.92 recall on regulated content in evaluation. The next step is a small model trained on each vertical's language, and that is where the moat forms: the pipeline design is copyable, but the labeled clinical corpus a tuned model needs is not, and neither is the evaluation discipline to promote one only when it beats the general path head-to-head. A domain-tuned HIPAA classifier is in development against exactly that bar. Every vertical we add clears the same test — which makes this a method we can repeat, not a result we got lucky on.

From Label to Action

A catalog-driven policy engine turns the resolved label into an action: allow low-sensitivity prompts through, redact sensitive spans before routing, or keep regulated content on a local model that never leaves the trust boundary. A per-label score floor guarantees that protected categories — like HIPAA data — cannot be under-classified into an external route, independent of any model score. Every decision, with its classification, redactions, and destination, is written to an append-only audit trail.

In effect, the gateway separates what the user wants to ask from what is allowed to leave: the model sees a prompt only after the gateway has cleared it.

Which Models, and Who Can Reach Them

Classification decides what a message is. A separate control, owned by the organization, decides where it may go.

Administrators register the AI models the organization permits — local or external, which vendor, what data terms — and the policy engine routes only to that catalog. A model that isn't listed isn't a destination, so adopting a new provider is an admin decision, never a user's. Policy then ties each label to the models it may reach: HIPAA content resolves only to local models; ordinary business content may reach an approved external one. Because the rule points at the catalog rather than at fixed endpoints, it holds as the model landscape changes.

Identity narrows it further. Each request carries the user's role and the endpoint it came through, and both constrain what the catalog offers: the same text from a clinical role and an admin role can route differently, and a request through an unapproved integration isn't served at all. Roles and endpoints are configuration, not code. The result is three independent levers over one message — what it contains, which destinations exist, and who may reach them.

How It Works

1. Inspect — Every prompt passes through the four inspection layers. Most are resolved on a fast path; only ambiguous prompts escalate to the heavier semantic layers.

2. Score — Signals fuse into a priority-ranked policy label. The highest-priority match wins, and a detected prompt injection wins regardless of priority.

3. Decide — The policy engine chooses allow, redact, or block based on the label, its score floor, and the destinations the catalog permits for that label, role, and endpoint.

4. Route — Sensitive spans are redacted before anything leaves; regulated content stays on a local model with no internet egress.

5. Log — Classification, redactions, decision, and destination are written to an append-only audit trail for compliance review.

Who It's For

People doing ordinary work — finishing a discharge summary, checking contract language, drafting client correspondence. They are not thinking about governance and should not have to. TrustLayer removes regulated identifiers before the request leaves the boundary, states in one line what was withheld, and returns the answer. The workflow does not change, which is the point.

Compliance and privacy teams — who need proof, not assurance. Every decision is scored, recorded, and reviewable, turning "we think our data is safe" into an auditable control.

Security teams — who gain visibility into what actually leaves the organization through AI, and the ability to enforce policy at the level of the individual message rather than the entire application.

The asymmetry is deliberate: one prompt produces two artifacts — a one-line notice for the person who wrote it, and a full decision record for the people accountable for it. Adoption never depends on getting users to care about governance; the control works precisely when they don't notice it.

TrustLayer is built for regulated verticals — healthcare, legal, and financial services — where governing the data boundary is mandatory, not optional.

Current Status & Future Work

For this capstone, we built and demonstrated the live governance path end to end. Everything under Delivered is implemented and running in the demonstrated system. Everything under Future Development is planned work and is not yet built.

Delivered

• Inline FastAPI gateway with content-layer inspection
• A four-layer inspection pipeline in the live decision path: Presidio entity detection, three deterministic validators (Luhn, NPI, SSN safe-harbor), and a zero-shot semantic classifier built from two BERT-family NLI encoders (DeBERTa-v3 + RoBERTa-large) combined by soft-vote
• Priority-ranked policy labels (HIPAA, GDPR, PII, sensitive business data) with a per-label score floor that pins regulated content to local handling
• Redact-then-route enforcement with allow/redact / block routing to local or external models
• Append-only audit logging, review queue, and full observability (Prometheus, Grafana, Loki)
• Held-out evaluation of the classification path across chat and file channels, with a standing false-positive monitor on both
• A reference chat application, governed end-to-end by TrustLayer

Future Development

• Domain-tuned small models promoted into the live path on head-to-head metrics — a HIPAA-trained clinical classifier first, then legal and financial, each with its own labeled corpus
• Bidirectional inspection of model responses, not just prompts
• Synthetic-media detection on inbound model output, so generated images, audio, and video returned to users are inspected before they are trusted or stored
• API key issuance and device management, binding each key to a registered device and role so credentials can be scoped, rotated, and revoked centrally
• Third-party integration with collaboration tools such as Microsoft Teams and Slack
• Encryption at rest for stored messages and audit records, with per-tenant key separation
• Post-quantum cryptography for data in motion, adopting hybrid key exchange on gateway and model-egress connections ahead of harvest-now-decrypt-later exposure
• Reduced inspection latency, through quantized runtimes and wider fast-path coverage, so governance stays imperceptible under production load
• Multi-AZ, fail-closed cloud deployment with managed secrets and tamper-evident (WORM) audit storage
• Per-tenant isolation and expansion into legal and financial verticals

Key Capabilities

These describe the delivered system as demonstrated.

• Content-layer governance — decisions on individual prompts, not entire apps
• Four-layer inspection — entity detection, deterministic validation, zero-shot semantic classification, and cross-model corroboration, all in the live decision path
• Priority-ranked labels with per-label score floors — HIPAA and other regulated data cannot be under-routed, independent of any model score
• Redact-then-route — sensitive spans removed before anything leaves the boundary
• Local-vs-external routing — regulated content stays on an on-prem model with no egress
• Administrator-controlled model catalog — the organization decides which AI models exist as destinations; unlisted endpoints are not reachable
• Role- and endpoint-bound policy — the same content resolves differently depending on who submitted it and through which interface
• Inspection inside the trust boundary — every classification runs locally, so governance never becomes its own exfiltration path
• Complete audit trail — every classification, redaction, and routing decision recorded
• Role-based notices — detailed scoring for compliance, plain-language actions for end users