FAQ
The hard questions, answered straight.
What TenWall is, what it isn't, and why we built it.
01 / Questions
The hard questions, answered straight.
Don't databases already keep patients apart?
Yes, when they're set up correctly. We ran our 28 attacks on Postgres row-level security: with a separate role and the tenant set per request, nothing leaked. Connected as the table owner or a superuser, all 28 did.
What's left open for AI: the app (often the model) chooses the value the database enforces; databases separate tenants, not "this patient, this purpose, never psychotherapy notes"; database logs belong to the operator; and one assistant uses many stores and tools. TenWall is one scope, one policy and one record across all of them.
If you have one database, correct row-level security, a per-request identity, and only need one hospital kept apart from another, you may not need TenWall.
Is this only for AI search over notes?
No. Leaks happen when the AI retrieves or writes while it works. TenWall covers retrieval from a vector store, the AI's own memory, and tool calls through its MCP connector (built and tested locally). Other stores and live EHR data are planned.
What about imaging, and the embeddings made from it?
TenWall decides by the patient and label on each record, so an image study is kept to the right patient like a note is. Stored embeddings never leave through TenWall: the AI gets answers about the right patient's studies, not the raw vectors. Our demo runs this on 1,006 made-up brain-scan studies from 202 made-up patients. TenWall doesn't de-identify the scans themselves.
What about fine-tuned models?
TenWall can't filter what a model memorised during fine-tuning: there's no request to check, and every user shares the weights. Fine-tune for skills on de-identified data, and retrieve sensitive data through TenWall.
Does it work with Claude, ChatGPT or Copilot for business?
The risk applies there too: those platforms reach data through connectors, and a connector can reach whatever its account can open. Through TenWall's MCP connector, 0 of 300 attack runs leaked across three Claude models, against 22–80 of 100 through a plain connector.
The hosted connector with OAuth sign-in is deployed on a test server and was tried through Claude on 19 October, with made-up patients: a billing coder got only one patient's ordinary notes, a physician got only their own patient's notes (including the sensitive one), a user with no role was refused at sign-in, and writes were refused. We haven't tried it in claude.ai chat, Claude Enterprise, ChatGPT or Copilot yet. AI built into a product, such as Epic's or Microsoft 365 Copilot, is out of reach.
How is this different from AI connector and data-security products?
They connect AI to your data sources, copy each source's permissions per user, and make data safer to use, for example by swapping identifiers. TenWall scopes each request to one patient and one purpose, and your privacy office holds the proof. The two can work together.
How is this different from CyberArk, Okta and other agent-identity tools?
They manage who an agent is and the credentials it holds. TenWall decides what each request may touch, for this patient and this purpose, narrows it at every hand-off between agents, enforces it at the data, and gives your privacy office proof. The two fit together: their identity is TenWall's input.
Hand-offs that can only narrow, and the user's sign-in through any OpenID Connect provider such as Okta or Entra, are built and tested locally. Agent sign-in by OAuth client credentials or workload identity is planned.
Isn't this just access control?
Access control decides who may open a chart. TenWall decides what each AI request may retrieve or write, for one patient and one purpose, and proves it to someone outside the AI team.
Can we watch before we enforce?
Yes. In watch-first mode TenWall records what the patient and sensitive-note rules would keep back, without keeping it back, so your committee sees the effect on real work before switching on. Other hospitals' data, every write and sign-in stay enforced even then, and the record marks each entry "not enforced".
What if an agent or an account goes wrong?
Stop it. Security can stop one user, one agent, one app or one token: TenWall refuses it at once, any agent it handed work to stops too, and the sign-in service won't issue it new access. Freeze stops everything at once. Each stop and lift goes into the record.
02 / Why we exist
AI should respect the same walls people do, no matter what it's asked.
We build the checkpoint that enforces those walls outside the AI's control, and the record that proves they held.
Every hospital can prove, not just promise, what its AI touched and for whom.
Hospitals and health systems putting patient records in front of their own assistants and agents.
If the AI can change it, it isn't a security control.
We enforce the rules you already keep.
A record that holds up even against the people who run it.
We only prove what flows through TenWall.
Prove the walls held.
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 →