Security

Accounts and sign-in

Passwords are never stored. Each one is put through scrypt with its own random salt and compared in constant time, so two identical passwords do not produce identical records and a comparison cannot be timed. Sign-in sessions are server-side records referenced by a wd_sess cookie that is HttpOnly, Secure and SameSite=Lax, and that expires. Signing out and revoking sessions both invalidate the record on the server, not only the cookie.

Single sign-on uses OpenID Connect with your company's identity provider. It signs in people who are already members of the workspace — it never creates accounts — and an owner can require it for members whose address is in the workspace's pinned domains (owners themselves keep password sign-in, so a broken identity provider cannot lock everyone out). Like any enterprise single sign-on, it means that an owner who controls the workspace's identity provider can sign in as any member in its pinned domains.

Two-factor authentication uses TOTP (RFC 6238) with an authenticator app. We do not use SMS for second factors.

Sign-in, sign-up, password re-checks, the demo door, card verification and the realtime credential endpoint each have their own rate limit, so pressure on one cannot exhaust the budget of another.

Separation between customers

Every company-owned table is read and written through a single gateway that forces the workspace identifier onto every query and refuses any attempt to supply a different one. The isolation is implemented in one place rather than repeated in each feature, and it is covered by tests that put two real workspaces on the wire and assert that neither can reach the other. Every application endpoint requires a session: the default is to deny, and a new endpoint is covered the day it is written.

Encryption

Connector credentials, AI provider keys and multi-factor seeds are sealed with AES-256-GCM, each bound to the workspace and record it belongs to, so a value moved between rows fails to decrypt rather than silently opening. Passwords, sessions and invite links are stored only as one-way hashes.

What this does not cover. Your company content — documents, messages, meeting records, recordings and scan results — is not separately encrypted at rest. It is protected by workspace isolation and access control. We would rather say so here than let the word "encrypted" do work it has not earned.

All traffic to the service is over HTTPS.

Recordings and share links

A screen recording is private until you share it. A share link carries a 96-bit handle that cannot be guessed or enumerated, and you can add a passcode, set an expiry, or rotate the link — which invalidates every copy already sent. Passcodes are hashed and compared in constant time, and repeated wrong attempts are rate-limited. A link that has expired, been rotated, or is not yours answers as though it does not exist.

Calls and screen sharing

Voice, video and screen share connect peer to peer. Our server relays only the connection-setup messages; no audio or video passes through it or is stored by it. A call is scoped to your workspace: the room is derived from your session, never from anything the browser asks for. Relay credentials, where used, are issued per person and expire in minutes.

Auditing

Privileged and destructive actions write an append-only audit record with the actor, the time and what changed. Records are hash-chained so a later edit is detectable, and the audit write happens in the same transaction as the change — if the record cannot be written, the action does not happen.

Backups and recovery

Backups run on a schedule, include uploaded files as well as the database, are verified at the time they are written, and are kept to a retention policy. A restore has been performed and recorded — a backup nobody has restored from is an assumption, not a backup.

What this does not cover. Backups are held by the same infrastructure that runs the service. Off-site copies held by an independent provider are not yet configured.

AI and your content

Answers are generated from your workspace's own material and cite the sources they used. Your content is not used to train models. Where a question cannot be answered from what your workspace has provided, the assistant says so rather than inventing an answer.

Anthropic is the only model sub-processor. When you use the assistant, a report narrative or a meeting brief, the text of that request is sent to Anthropic's API and nowhere else — there is no second model vendor in this product.

What is masked before it leaves. Before company text and what you type are sent to Anthropic, Workdesk replaces the personal identifiers it recognises with placeholders: email addresses, phone numbers (including full-width, spaced and bracketed forms), My Number, payment card numbers that pass a checksum, bank account numbers, passport numbers, postal codes and the address that follows a prefecture name, and IP addresses — and the names, emails and phone numbers of your workspace's members. The original values are put back only in the reply shown to the person who asked; the substitution is never stored. Audit and security-event details are stored with the same patterns masked, though a bare personal name is not matched there. Three things are sent as they are: the name and instructions your workspace wrote for an App; a report narrative, which receives computed figures and their labels and no document text; and the Doc Scanner's photo, because reading what is pictured is its purpose. Everything else in a request does travel: if a document in your workspace contains something you would not send to a third party, treat the assistant as a place it can go.

What we do not have

Stated so that nobody has to ask:

• No SOC 2, ISO 27001 or equivalent third-party certification.
• No customer-managed encryption keys.
• No SAML single sign-on and no SCIM provisioning (single sign-on is OpenID Connect only).
• No formal bug-bounty programme.
• No published penetration-test report.
• Company content is not separately encrypted at rest (see Encryption, above).
• No off-site backup copy with an independent provider (see Backups, above).

Reporting a vulnerability

Email contact@ai-sns.io with enough detail to reproduce the issue. Please give us a reasonable opportunity to fix it before disclosing it publicly. We will confirm receipt, tell you what we find, and credit you if you would like us to.

Operator

This service is operated by Freeborn Inc. (株式会社フリーボーン). Company details, contract terms and the notice required under the Specified Commercial Transactions Act are on the Legal Notice page. How we handle personal data is described in the Privacy Policy.