Security

Security and data handling.

What each part of Jalten can reach, what stays on your device, what our servers store, who can see what, and what we have not built yet.

How to read this page

Most of what follows describes how Jalten is built rather than what we intend. Where we have no evidence for something, this page says so instead of implying it. The last part covers Browser Protection, the separate Chrome extension we also operate, whose claims can be checked against its published package.

How Jalten is put together

  • Jalten in the browser at app.jalten.com is the workspace in a browser tab. Sensitive details are found and replaced in the browser, on your device, before anything is sent.
  • Jalten for Mac (coming soon) is the workspace as a Mac app. Sensitive details are found and replaced on the Mac, before anything is sent.
  • The admin console at app.jalten.com is where owners and admins manage people, models, protection rules and usage caps.
  • The AI gateway passes company chats to OpenAI or Anthropic with the company’s own key, after checking the request against the company’s policy.

Your workspace database, provider keys and AI gateway run in Sydney, Australia.

The database is Supabase, in Sydney. The gateway runs on Amazon Web Services in Sydney, behind Amazon CloudFront. Provider keys are held in AWS Secrets Manager in Sydney. The website and console are served by Vercel, whose functions may run outside Australia. Every connection is HTTPS. These platforms encrypt data at rest as part of their service; that is their control, documented by them, and we have not independently audited it.

What stays on your device

Jalten for Mac (coming soon)

  • Conversations: the protected text that was exchanged, plus the link between each real detail and its stand-in, encrypted per conversation.
  • Projects: names, instructions and text files, encrypted.
  • Personal API keys: encrypted with Electron’s safeStorage, which uses a key held in the macOS login Keychain. A key is decrypted only in the app’s main process, at the moment a request is sent, and is never returned to the app window or shown again.
  • The company sign-in: the Mac’s own key and its tokens, encrypted the same way.
  • Logs: event names, counts and error codes only.

Local encryption protects against disk theft, backups and other accounts on the computer. It does not protect against malware already running as you, which can read the screen, memory and possibly the key store.

Jalten in the browser

The browser keeps the same things, apart from provider keys, in its storage for app.jalten.com: conversations and the link between each detail and its stand-in, projects and their files, the browser’s own sign-in key and tokens, and logs of event names and codes. They are encrypted with AES-256-GCM under a key the browser creates for Jalten and cannot export, and the sign-in key cannot be exported either. A personal provider key is never stored in the browser (see Provider keys).

It stays in that one browser and is not shared with your other browsers or a Mac. Clearing the browser’s data for app.jalten.com deletes it. The encryption protects what is stored; it does not protect against a malicious browser extension or software already running as you.

How a message is sent

Messages, attachments, and project instructions and files are checked on your device before anything is sent. New findings open a review that shows each detail, the stand-in that will replace it, and every model that will receive the request. Just before sending, a final check blocks the request if any original value the app knows about is still in it. Replies are shown with your real details restored, on your device only.

  • Company chats go to the AI gateway. It checks that the request is signed by a device signed in to the workspace, that the person may use that model under the company’s policy and usage caps, then passes the protected request to the provider with the company’s key. It records one usage row: tokens, status and timing, with no text. It never logs or stores a prompt, a reply, a key or a provider’s error message, and it never receives the link between details and stand-ins.
  • Chats with your own key in the browser go through the AI gateway in the same way, using your key from the gateway’s key store.
  • Chats with your own key in Jalten for Mac go from the Mac straight to OpenAI or Anthropic. Our servers are not involved.

Some categories are noticed rather than replaced: dates and amounts are kept so the model can calculate with them, and health, legal, immigration and confidential business wording is flagged. These are sent as written unless you choose to replace them.

Provider keys

  • A company key is entered by an owner or admin, who must have used two-step sign-in. The console sends it straight to the gateway with a one-time, single-use ticket; it never passes through the database.
  • The gateway stores it in AWS Secrets Manager in Sydney, encrypted with an AWS KMS key. Only the gateway’s own role can read it. The console shows its fingerprint, never the key.
  • Disconnecting a key stops its use at once; AWS deletes the stored key after its 7-day recovery window.
  • A personal key, for Jalten in the browser on your own, is typed once in the app and sent straight to the gateway, which stores it the same way. It is never stored in the browser, shown again or logged, and disconnecting it deletes it from the key store at once.
  • Whoever can deploy the gateway’s code could, in principle, make it read the keys it relays. That is true of any gateway. Deployment is limited to the operator, and every deployment is recorded in AWS CloudTrail.

Sign-in and policy

  • People sign in with an email address and password. Owners and admins also use two-step sign-in with an authenticator app, and changes to people, keys and budgets need it.
  • Each device signs in to the workspace and holds its own key. Every request it makes to our servers is signed with that key, and an admin can end a device’s sign-in from the console.
  • The company policy each device applies (models, protection rules, limits) is signed with a key held in AWS KMS in Sydney, and the app checks the signature before applying it.
  • Requests are rate-limited per person, and the number of replies running at once is capped.

Who can see what

  • Owners and admins see their own workspace and nothing else: its people, Macs, models, usage, calculated cost and protection totals. Per-person cost is shown to owners, admins and the billing role only. This is enforced by the database, not by the page.
  • Members see their own usage, and nothing about anyone else’s.
  • No one in the console can see a prompt, a reply, a file or a protected detail, because none of it reaches our servers to be stored.
  • We can read the database. We operate it, so we have administrative access. What that covers is described above: accounts, workspace settings and usage figures. It does not include conversations, because no column holds one.

What protection detects

Detection is pattern matching and a list of names, not a language model, and it is tuned for Australian identifiers. It runs on your device. The same rules power Browser Protection.

Replaced with realistic stand-ins

  • People and organisations: names and company names.
  • Contact details: phone numbers, email and street addresses, GPS coordinates.
  • Identity documents: passport, driver licence, Medicare and tax file numbers.
  • Financial identifiers: card numbers, BSB and account numbers, ABN and ACN, reference codes.
  • Credentials: passwords, secrets, usernames and connection strings.

Noticed, and sent as written unless you choose otherwise

  • Dates and amounts: kept so the model can calculate with them. You can choose to replace them.
  • Sensitive topics: health, legal, immigration and confidential business wording, flagged so you can decide.

Detection can miss things and can occasionally flag ordinary words. A name on its own is detected only alongside another identifier, or once it has already been protected in the conversation. That is why every new finding opens a review the person can correct, and why this is a safeguard for everyday AI use rather than a data loss prevention platform.

Browser Protection

What the extension can access

Browser Protection is a Chrome extension, sold under the Guard4AI name, that checks messages on supported AI websites. A Chrome extension can only do what its manifest asks for, and the manifest ships inside the package. Guard4AI asks for one permission.

Every claim in this part is checkable from the Chrome Web Store listing. The permissions a Chrome extension requests are shown on its store page before you install it, and the manifest itself is inside the downloaded package.

One permission: storage

It lets the extension keep your settings and your masking table on your own machine. That is the entire list. Guard4AI does not request tabs, history, cookies, bookmarks, downloads, webRequest, scripting or nativeMessaging, and it declares no optional permissions it could ask for later.

Twenty-eight AI tools, named one at a time

The part that reads your message is a content script, and it can only run where the manifest lists it. Guard4AI lists twenty-eight AI tools explicitly: ChatGPT, Claude, Gemini, Copilot, Perplexity, Poe, Mistral, DeepSeek, Grok, Meta AI and the rest, plus our own Supabase project for the licence check. It does not ask for <all_urls>, and it does not ask for a wildcard.

No remote code

The extension’s content security policy is script-src 'self'. Nothing it runs is fetched from a server at runtime. The PDF reader, the Word reader and the text recognition engine are all shipped inside the package. The one exception in the policy is wasm-unsafe-eval, which the text recognition engine needs in order to run its WebAssembly at all.

What a web page can and cannot reach

The manifest sets no externally_connectable, so no page on the web, including ours, can use Chrome’s extension messaging to reach Guard4AI or read anything out of it. One qualification, because the stronger claim would be inaccurate: on the supported sites the content script runs inside the page, and it does listen for browser message events. It listens for exactly one thing, the handshake from the file-reading frame the extension creates itself, checks that the sender is that frame, and ignores every other message.

What the extension transmits

Its settings, masking table and counters are kept in the browser’s own extension storage. A workplace seat can make six requests, and no others: redeeming the invite code once (the code and the name typed at activation); recording a catch (seat id, category and AI tool); recording a tool as used, at most once a day; recording an attachment’s broad type and outcome; confirming the seat is still valid, which brings back the scanning policy; and handing the seat back. A personal licence makes two, each carrying a random token and nothing else.

Detection is pattern matching and it is not perfect. Browser Protection is a safeguard against accidental over-sharing, not a guarantee that nothing sensitive can ever reach an AI tool.

Retention, stated accurately

There is no scheduled deletion of the extension’s records. Nothing on our side purges old rows on a timer, and no retention period is currently defined for them.

A row persists until something deletes it: an admin removing a seat (the seat and every catch filed against it go immediately), the company being deleted, or you asking us. The rows are tallies rather than content. Guard4AI staff can read the database, which holds tallies, names on seats and billing records, never messages.

The full description of what the extension handles is in Browser Protection’s privacy policy.

What we have not built yet

Things a security review commonly asks for, and where each one stands.

  • Independent testing: no third-party penetration test has been completed.
  • Certification: no SOC 2 or ISO 27001 certification is held.
  • Desktop app review: Jalten for Mac has not had an external security review.
  • Browser app review: Jalten in the browser has not had an external security review.
  • Single sign-on: not supported. Accounts use email and password, with two-step sign-in for owners and admins.
  • Managed deployment: no managed enterprise deployment is provided for the Mac app. For Browser Protection, no MSI, configuration profile or device management integration is provided.
  • Files: Jalten reads text files. PDF, Word documents and images are not read yet.
  • Platforms: Jalten in the browser runs in current versions of Chrome, Edge, Firefox and Safari. Jalten for Mac (coming soon) requires a Mac with Apple silicon and macOS 13 or later.

If any of these is a requirement, Jalten does not meet it today.

Reporting a security problem

Email hello@jalten.com with what you found and how to reproduce it. We will acknowledge it within two business days and tell you what we intend to do. No bug bounty programme is offered.

Last updated 13 October 2026 · Jalten is operated by Oliver Scholefield.