Confidentiality
We cannot read your cases.
Jesmond holds some of the most sensitive material an employer ever handles. It is built so that Jesmond has no way to read it.
Data security & GDPR
What goes into Jesmond stays in Jesmond.
Processed in the United Kingdom
Hosted on UK or EU infrastructure as agreed with each client, each tenant logically separated, everything encrypted in transit and at rest.
Seen only by your people
Jesmond and its parent company cannot access your data. Only the admin within your own organisation determines who can. Guardrails and architectural design, reviewed by external security auditors, prevent unauthorised viewing.
Never used for training
We do not train Jesmond on your data.
Deleted on your schedule
Retention is configurable: records are kept for the period your policies require, then deleted. Subprocessors are listed in the DPA.
For the information security pack, or to begin a vendor assessment: hello@jesmond.ai
The one rule
Zero access and what that actually means.
Most products that promise confidentiality mean their staff are told not to look. That is a policy, and policies depend on people keeping them.
Jesmond works the other way round. Case content is scrambled on your own device before it goes anywhere, and it can only be unscrambled by the people you have authorised — using the fingerprint, face or PIN sign-in already built into their phone or laptop. We never hold anything that could unlock it. What reaches our servers is a sealed box we cannot open.
Where content goes
Follow a single case.
- You sign in through your own organisationThrough your corporate login, with no public sign-up. Every request re-checks that the person is still active, so removing someone takes effect on their next click.
- The case is encrypted on your deviceThe letter, the evidence, the notes and the drafts are handled in your browser and sealed there. Nothing readable leaves the machine.
- Your browser talks to the AI, we do notYour browser sends the request straight to the AI itself, in the UK, under an agreement that it keeps nothing. The request never touches our application, our database or our logs.
- What we store is sealed before it reaches usSo you can pick a case up on another device, your working state is saved to storage set aside for your organisation — sealed by your browser first. We hold the box and no key to it.
- You export ordinary documentsWorking papers come out as files you keep wherever you keep your files. Nothing is trapped inside the product.
What reaches our servers is ciphertext we cannot open.
The one rule
One thing to be straight about
One place the guarantee is a promise, not physics.
A browser is not allowed to call the AI’s address directly, so the request passes through a relay on our own domain on its way there. Our application never handles readable content, but for the current Beta that relay does hold the request in memory for a few thousandths of a second in order to pass it on.
It is never written down and never logged, and the rule enforcing that is set above our own administrators, who cannot quietly switch it off. What that does not cover is our cloud provider’s own privileged staff. We have accepted that risk for this phase rather than pretend it away, and the engineering that removes it entirely is costed and scheduled.
This applies only to the seconds a request is in flight. Everything stored — drafts, working state and the audit trail — is sealed under keys we do not hold, and that is architecture rather than promise.
What we hold
The honest inventory.
Being exact about the boundary is worth more than claiming everything is invisible. Our servers run the service, and to do that they hold a deliberately dull set of things.
What our servers hold
- Which organisation you are, who is signed in, and what their role is
- Which case is at which step, so you can resume where you left off
- A content-free record of who did what and when
- Your drafts and working state, sealed and unreadable to us
- Usage counts for billing, with no content attached
What they never hold
- The text of a grievance, allegation, statement or outcome
- Uploaded documents, in any form we can read
- What was sent to the AI, or what it sent back
- Anything that would unlock the above
One organisation cannot reach another’s data. That is enforced beneath the application by the database and the storage themselves, not by code that has to remember to check.
Keys
Who can open what.
Each authorised person holds their own sealed copy of the key, locked to their own sign-in. We store those copies and cannot open any of them.
We cannot add ourselves
A new person is let in by a colleague who already has access, from their own browser. There is no route for us to enrol ourselves or recover a key.
You cannot be locked out by one lost laptop
An organisation cannot run with a single key holder — a second must be enrolled before normal use — and a recovery key stays in your custody.
Deletion means deletion
Because everything stored is sealed under your keys, destroying the key makes the stored data permanently unreadable, including where storage cannot otherwise be erased.
Who can see a case
Inside your organisation, access is narrow by default.
The default answer to "can this person see this case?" is no. Someone assigned to a case can work it end to end. Someone who is not cannot see it, or even see that it exists.
- Account owner
- Sets the organisation up, holds the recovery key, and must enrol a second key holder before the team starts work.
- HR admin
- Works every case, invites people, assigns them, and can export the audit trail for legal use. Admin actions are themselves audited.
- Organisation member
- Sees only the cases they are assigned to. Nothing else in the organisation exists as far as they are concerned.
- The employee and interviewees
- No access at all, by design. They are people the case is about, not users of the system.
Article 9 data
Built for special-category data in a live dispute.
A grievance about bullying, a disciplinary involving a health condition, an allegation of harassment: all of these carry special-category data under UK GDPR, about people who are still working together and already in conflict. These are just the sorts of cases Jesmond was designed for. Data stays in the UK, including the AI processing, and because content reaches us sealed, the usual question of what a supplier does with it has a short answer: nothing it could.
Whether you have a lawful basis and an Article 9 condition, and what your DPIA concludes, are decisions for your DPO and your counsel. We can describe the architecture precisely, and will; we cannot make those calls for you.
Common questions
Questions we are asked in procurement.
If you cannot read case content, how does support work?
From metadata: which tool, which step, what error. If a problem genuinely needs the content to diagnose, you decide what to share and how. There is no view that lets us look for ourselves, and no escalation that creates one.
What would an attacker get if DefendThis were breached?
Who your users are, which cases exist and how far through they are, usage counts, and sealed copies of the drafts and the audit trail that cannot be opened. Not the contents of anyone’s case: those are not there in readable form, and the keys are not ours to lose. That is the point of the design — it limits what any breach can expose.
Does the AI provider train on our data?
No. Requests go to Claude on Amazon Bedrock under a Zero Data Retention agreement: retention is switched off and request logging is disabled, enforced by an organisation-level policy rather than by our own good behaviour. Only models that support Zero Data Retention can be selected.
Does the team who build Jesmond see our data?
No. They build and support it using synthesised or anonymised test data only, and hold no key to anything real.
Can we see the full security documentation?
Yes. There is an architecture and security document written for a CTO, covering the request flow, key custody, tenant isolation and the threat model, including what is mitigated and what is accepted. Ask when we speak and bring your security team.
Put the architecture under scrutiny.
Bring your security team. We will go through the request flow, key custody and the threat model, including what we have accepted.