Get started

Find your leaks. Then install the wall.

A leak test of the AI tool you're about to approve, then a pilot where your own security team tries to break TenWall. Made-up data throughout.

01 / Get started

First, find your leaks. Then install the wall.

Step 1 · Leak assessment · one day

Can your AI show someone data they shouldn't see?

We run it with your team, on the assistant you're about to approve, such as Claude or ChatGPT Enterprise with connectors to SharePoint or Drive. Nothing to install. Made-up patient records only.

  1. Sign off. Written approval, two test accounts: user A, and user B who owns the restricted records.
  2. Plant made-up records. Our kit generates fake patient notes with hidden markers. If your network forbids bringing files in, one script you paste in generates them instead. You put them where user A shouldn't reach: B's private folder, a restricted folder, an over-shared one, plus two documents with hidden instructions.
  3. Ask six questions as user A, 10 times each in fresh chats, and save the answers and the assistant's logs.
  4. Score it against your own rules. We write your access rules down once, and each one passes or fails: which marker leaked, to whom, and how. A run that can't prove anything says so instead of passing.
  5. Clean up the planted files, chats and test accounts.

The report is yours to keep: what leaked, through which path (sharing, permissions or instructions hidden in documents), and what to fix. If you go on to a pilot, the same prompts run again through TenWall. If your team builds its own retrieval pipeline, a probe tests that layer directly, with the same made-up records.

Step 2 · Install for a pilot

One container inside your network. One URL change.

TenWall runs next to your assistant's vector store. No patient data leaves your network, and nothing is hosted by us.

  1. Install TenWall beside the vector store your assistant already uses: one machine with Docker, or Kubernetes with our Helm chart. The install script makes every key once.
  2. Point the assistant at TenWall instead of the store, and send each request's signed scope: 
    - STORE_URL = "http://qdrant:6333"
+ STORE_URL = "http://tenwall:8080/vector"
+ Authorization: Bearer <signed scope for this request>
  3. Your privacy office writes the policy: which roles, purposes and sensitive labels each assistant may use. A scope issuer you run signs each request's scope.
  4. Notes going into the index carry their patient and any sensitive labels.
  5. Checkpoints go to the privacy office, which verifies the record on its own machine with one command.
  6. Prove it on your install. One command checks it with made-up notes: the right note comes back, other patients' and sensitive notes are kept back, a write is refused, a stopped user is refused and let back in, and the record verifies.
  7. Watch first, if you like, for a short trial your privacy office signs off. Watch-first mode records what the patient and sensitive-note rules would keep back without keeping it back, so your committee sees the effect before switching on. Writes and other hospitals' data stay enforced.
  8. Run the leak scan before go-live and keep the report.

The install kit and its check are built; CI runs the check against real Qdrant and Postgres, and the first install on a hospital's own machine is part of the pilot. Scopes from your sign-in and the Epic launch are built and tested locally and get connected to your systems in the pilot. Engineers can also try the agent connector on their own machine with a local kit and made-up notes.

02 / The pilot

Try to break it. Your team, 3 to 4 weeks.

TenWall runs in your test environment in front of a test store of made-up patient notes. Your security team installs it, runs the attacks and checks the record themselves. Nothing touches production.

How it runs
  • Week 1: your IT installs it, with the founder on a call
  • Weeks 2 and 3: your security team attacks it, as often as they like
  • The last days: a written result, every number from your team's own runs
What we need
  • One Linux test machine with Docker
  • A few hours of IT time in week 1
  • A named contact on your security team
  • A place for the privacy office's copy of the record
It passes when
  • Every line of the install check says PASS
  • 0 of 28 attacks get through
  • The record verifies against the copy your privacy office holds
  • It refuses, not serves, when its database is down
  • Ordinary work isn't blocked

Your team gets the source of the tools that judge TenWall (the attack scan and the record verifier) and builds them itself. Each check passed on our own pilot install on 28 October; your team's runs are the ones that count. After a pass: connect one AI tool to TenWall in the test environment. Production use needs a business associate agreement and your security review.

What TenWall does not do
  • It covers assistants your hospital runs. It can't control Epic's built-in AI or Microsoft 365 Copilot.
  • It enforces the policy you configure. It doesn't decide what your policy should be.
  • It only proves what flows through it.
  • It doesn't mask or replace identifiers before data reaches a model. It works alongside tools that do.
  • It isn't independently penetration-tested yet; that comes before production use.
  • It decides by the patient and label on each record. It doesn't de-identify images.
  • It can't remove what a model memorised during fine-tuning. Fine-tune for skills, retrieve for patients, and every retrieval goes through TenWall.

Prove the walls held.

Start with a leak test of your own AI, using made-up data. Tell us about the assistant you're building and the decision in front of you.

Book a leak assessment Request the leak assessment kit Try the agent connector locally

The assessment uses made-up data only. TenWall runs inside your network and never sees your data. See the dashboard preview →