Trust
Security
Arthat Vault protects stored evidence, context and the routes used to reach them. This page describes current controls and current limits without presenting unfinished work as a guarantee.
1. Moving data around
Network traffic used by the Arthat Vault web app travels over encrypted HTTPS/TLS connections: from your browser to Arthat Vault, and from Arthat Vault to its database, storage and any configured processing provider. A local connector may communicate with its host on the same machine instead of crossing the public internet.
2. Stored data
File bytes are stored in Cloudflare R2 and records are stored in Supabase Postgres. Those services provide encryption at rest as part of their platforms. Arthat Vault also keeps file keys under an owner-specific path and checks that ownership before issuing a link.
Arthat Vault is not end-to-end encrypted. The service holds the storage credentials needed to retrieve files for you, so an authorized Arthat Vault server process can read stored content. Do not use Arthat Vault as a password manager or as the only copy of material that must remain unreadable even to the service operator.
3. Owner-checked, time-limited file links
The storage bucket is not public. Before Arthat Vault signs a file link, it checks that the object key belongs to the signed-in owner. Links shown in the current timeline, item view, search and export expire after 24 hours. Upload links expire after ten minutes.
A signed link is still usable by anyone who has it until it expires, so treat it as temporary access rather than as a harmless public URL. The 24-hour read window is the current implementation and may be shortened as download and export flows improve.
4. Account and workspace isolation
Database row-level security protects direct account access. Server routes also authenticate the user, filter records by owner and validate stored object keys before signing them. Private and grant checks add another boundary for connected-AI access.
Some server routes use elevated database access, which bypasses row-level security. On those routes the explicit owner filter is part of the security boundary. That is why route-level and cross-account tests matter; the presence of row-level security alone is not proof that every path is safe.
Arthat Vault supports emailed links and email-password access, and can show configured external identity providers. Supabase handles credentials and sessions; the Arthat Vault application cannot read a stored password. Your email account remains a recovery key to the vault and should use its own strong password and two-factor authentication.
5. The AI boundary
Arthat Vault preserves evidence and context. A connected AI you choose may perform cognitive work only on the source and task supplied under a versioned processing contract. Private content is not eligible for dispatch. Policy is checked before source fetch, before dispatch and before a result is applied.
This does not make an outside AI part of Arthat Vault’s security perimeter. Once permitted content reaches a provider, that provider’s account security, retention and deletion rules matter too. Removing an Arthat Vault grant stops later reads; it cannot erase a copy already held in an outside chat or provider system.
6. Connected tools and credentials
The intended connector credential is a scoped bearer token shown once at creation. Arthat Vault stores a prefix and one-way fingerprint rather than the reusable secret token. Connector profiles can be paused, credentials can be rotated or revoked, and a token cannot ask for scopes outside its profile’s allowance.
Existing local connector setup can still involve a powerful project credential. Treat that as an early setup for one trusted user: keep it on a device you control and never paste it into an untrusted tool. The scoped-token route is replacing this arrangement for ordinary connections.
7. Defaults that should fail safely
- A normal new connector receives no vault-wide access merely because it exists; access must come from its configured scope and grants.
- Private content is excluded before connected-AI retrieval and is refused by the new processing runtime before dispatch.
- Connected-assistant reads that require an audit entry should fail if the entry cannot be recorded.
- Web infrastructure keys remain on the server rather than being sent to the browser.
8. Found a vulnerability? Tell us
Email security@arthat.org with what you found, how to reproduce it, and what it may allow. Put “urgent” in the subject for a serious issue.
Use your own account and test data, do not keep or change another person’s content, do not degrade the service, and give us a reasonable chance to investigate before publishing. We will not take legal action for good-faith research that follows those limits.
We aim to acknowledge a report within three working days. Arthat Vault does not currently operate a paid bug bounty.
This page separates current behavior from work that is landing or planned. None of it is an audited guarantee. Arthat Vault has not completed independent assurance of these claims. We hold no SOC 2, ISO 27001, or other security certification. A status box calls out an incomplete or transitional capability instead of asking you to assume it is already live.