Product
One checkpoint between your AI and its data. Your sign-in says who is asking, your EHR says which patient, and TenWall returns only what your rules allow, with a record your privacy office verifies.
01 / How one request works
Illustrative. Patient and staff are made up.
In an emergency, a clinician gives a reason and gets 30 minutes of wider access, and the privacy office reviews it the next day. The same break-the-glass process your EHR already uses.
02 / Running in your systems
Requests come from a clinician in Epic, from Claude through TenWall's connector, and from agents handing work to each other. Each one passes TenWall on its way to the data, and lands in the console's live view in plain words.
| By agent | Requests | Kept back | Refused |
|---|
An illustration with made-up people. The live view itself is built into TenWall's console and tested locally; the wording above is the wording it uses. It shows only what the record holds: never note content, and patients only as pseudonyms. See the privacy office's summary page →
03 / How it fits
Shown for a hospital. Elsewhere, swap the clinician for an agent, banker, lawyer or manager, and the clinical index for their data.
Signs in as usual and opens a patient or work item in Epic.
Built and run by your team, on your model. One URL change.
Works out who, which patient and why. Returns only what's allowed and records it.
Your notes and chart data. Unchanged.
The record's signed checkpoints go to storage your privacy office owns, and events can feed the monitoring tools it already uses (planned). Everything runs inside your network; TenWall the company never sees your data.
The AI team changes one URL. The privacy office gets proof it doesn't have to take on trust.
Only the records your rules allow come back, whatever the AI asks for. Anything else is kept back or refused, the same way every time. Something wrong? Stop one user, one agent, one app or one token, or freeze everything at once and erase what was stored; everything else keeps running.
A tamper-proof record of every AI access. Your privacy office checks it against its own copy, so it doesn't have to trust the AI team.
What each AI agent did, and for whom, as it happens. The live view shows every kept-back or refused call in plain words, with the agent chain behind it, and a Stop button for any agent. Never the note itself.
TenWall sits in front of your AI's data, or runs as an MCP server, the standard way agents connect to tools. The agent reaches patient data only through TenWall, is offered only the tools its scope can use, with the same scope, the same checks and the same record. In real-model tests over MCP, nothing leaked behind TenWall. A hosted version with OAuth sign-in is deployed on a test server and was tried through Claude, with made-up patients.
04 / Example walls
TenWall enforces the policy your hospital configures. It doesn't decide your policy.
Enforced today through signed scopes and sensitivity labels. Connecting them to Epic (launch context, approved patient groups, label mapping) is part of the pilot.
Every search limited to the patient opened in Epic, or an approved group of patients.
Minimum necessary · CA HSC 1280.15Coding, quality, utilization review and research each get the categories your role matrix allows.
HIPAA 164.514(d)Withheld except for the author, or with an authorization on file.
HIPAA 164.508Counseling notes only with recorded consent. Never for legal proceedings.
42 CFR Part 2Restricted visits, including self-pay, withheld for billing and payment.
HIPAA 164.522Every AI retrieval recorded in a form your privacy office can verify.
HIPAA 164.312(b)05 / Integrations
Your identity provider says who is asking, your EHR says which patient, your agents bring the request, and your monitoring tools see every decision. TenWall adds the wall and the proof in between.
Okta, Microsoft Entra ID and others. The user's first scope comes from their own sign-in; the role comes from their groups. The app can't pick either.
Each hand-off between agents gets a narrower token, and the record names the whole chain.
Stop one user, one agent, one app or one token. TenWall refuses it at once, the agents it handed work to stop too, and the sign-in service stops issuing it new access. Lift it when you're done.
SPIFFE or mTLS, instead of a client secret.
The patient comes from the chart the clinician opened in Epic, not from the app. Tested against a demo EHR; Epic's sandbox is next.
The same scope and record for data read live from the EHR.
Point the assistant's vector-store client at TenWall and send a signed scope per request.
Agents reach the data only through TenWall, and are offered only the tools their scope can use: a read-only sign-in never sees an edit tool. 420 real-model runs through it: 0 leaks, no false blocks.
For Claude and other MCP clients: the user signs in at their identity provider and picks the patient on TenWall's page. Deployed on a test server and tried through Claude on 19 October, with made-up patients: a billing coder got only one patient's ordinary notes; a physician got their own patient's notes, including the sensitive one, and nothing of other patients; a user with no role was refused at sign-in; writes were refused. Not yet tried in claude.ai chat, Claude Enterprise or at a hospital.
Two agents acting for a doctor; the summariser never receives what the orchestrator may see. Scripted run passes; real-model run pending.
Every read, write and delete checked, over Qdrant's REST API. Stored embeddings never come back out through TenWall, even when the store would return them unasked.
Runs the 28 attacks against pgvector and checks its row-level security setup.
Enforcing through TenWall on the other stores hospital AI teams often run.
Every decision becomes a span, joined to the agent's own trace. Never content, ids, tokens or raw patient ids.
Each kept-back or refused AI call as it happens, in plain words, with a by-agent table. Never note content; patients only as pseudonyms. Ships read-only with the hosted connector.
See what the patient and sensitive-note rules would keep back before you turn them on: reads are recorded as "would keep back" instead of withheld. Other hospitals' data, every write and sign-in stay enforced; the install check refuses to pass in this mode.
Receiving those spans in hosted accounts.
AI access alongside the activity review the privacy office already does.
Checked on your own machine with one command, plus a one-page auditor report.
An install script that makes every key once, a Helm chart (two replicas, non-root pods, network policies), and an install guide for hospital IT. Next to your vector store; nothing hosted by us.
One command, made-up notes: the right note comes back, another patient's and the sensitive note are kept back, a write is refused, a stopped user is refused and let back in, and the record verifies. Your security team gets its own attack scan and verifier to build from source.
Start with a one-day leak assessment on your own AI, using made-up data. Tell us about the assistant you're building and the decision in front of you.
The assessment uses made-up data only. TenWall runs inside your network and never sees your data. See the dashboard preview →