Whitepaper
A practical guide to avoiding sharing incidents in the AI era.
Review encryption, URL-sharing data flow, retention, audit design, the boundary between Standard and Strict, and how to govern sharing that includes both humans and AI.
Request the whitepaper
Where conventional sharing starts to fail
See why training and caution alone do not stop misdelivery, forgotten links, or AI-mediated sharing.
How to design for incidents
Rather than assuming zero incidents, this section shows how to make them easier to contain.
The external-sharing gap left by cloud storage tools
Compare in-house storage foundations with the revoke, access-limit, and AI-audit context needed at the moment something leaves the org.
Encryption protocol
Understand browser-side encryption for files and short secure text, the boundary between Standard and Strict, and how passcode separation works.
Data retention and lifecycle
See what is stored and not stored for encrypted file sharing, encrypted text handoffs, and audited URL sharing, and what gets deleted or revoked at each stage.
Audit logs and explainability
Review how creation, open, attempt, download, external-link transitions, revoke, archive, and AI-agent actions are recorded.
How to use Slack as the next delivery path
See how much policy and audit should remain on the Sealith side when Business-or-higher Slack workspace integrations send share links into channels or DMs.
Shared controls for humans and AI
Understand Agent Tokens, purpose, jobId, aiProvider, aiClient, tokenId, and MCP, including why file delivery behaves differently on local-execution clients like Claude Code or Cursor versus remote clients like ChatGPT or Claude App.
Trust roadmap
Review the priority order for strengthening trust under Japanese law and operating norms, before moving into third-party assessment or certification.
Sender-side AI
This is the main live use case today. When your own people or AI act as senders, you can bind purpose, expiry, and destination domains, then automate transfer creation, finalization, revoke, and audit context while requiring purpose, jobId, aiProvider, and aiClient as audit metadata.
Receiver-side AI
If the receiving company also has a Sealith account, Business and above can use receive_handoff to route incoming material into internal AI workflows with controls rather than ad hoc judgment.
What it can do now
The Chrome extension can convert the current page URL, a clipboard URL, or a manually entered URL into an audited Sealith URL share. It can also show lightweight detection banners in Gmail and Google Drive.
Where Slack fits
On Business and above, connected Slack workspace channels or DMs can receive Sealith share links. Slack is treated as the next B2B delivery path, while revoke, audit, and workspace posting policies remain on the Sealith side.
What is not implemented yet
Workspace-wide forced controls, complete detection of bypassed sharing, and admin-wide policy enforcement are still future work and are intentionally separated from the current release.
Availability
The Chrome extension is already published in the Chrome Web Store. Setup steps and usage conditions are documented on the extension page, and it can be installed directly from the store.
How Sealith fits together
This diagram shows how file transfer, secure-text handoffs, and URL sharing are handled on the same control plane, covering encrypted data, revoke, access audit, and AI tracking as one operating model.
- Files and short secure text are encrypted in the browser, without assuming plaintext storage on the service side.
- For URL sharing, destination permissions stay with the external service while delivery and audit remain on the Sealith side.
- Slack integration expands delivery into channels or DMs while allow / deny rules and strict-mode controls remain workspace-scoped in Sealith.
- Human-to-AI and AI-to-AI handoffs can be reviewed through the same audit context.
- File transfer completion through AI clients still depends on whether the MCP client runs locally or remotely.
Trust roadmap
Trust comes from operations first.
At the MVP stage, the priority is operational alignment with Japanese law, third-party assessment, and public explainability rather than rushing certification logos.
30 days
Operational alignment with Japanese law, including the Act on the Protection of Personal Information, the Act on Specified Commercial Transactions, anti-spam requirements, and e-book retention expectations.
90 days
Third-party web application security assessment, remediation, and reflected updates to sales materials and whitepapers.
180 days
Preparation for PrivacyMark and ISMS / ISO 27001 scope definition, plus specialist confirmation of telecom filing requirements if needed.