Separate customer runtimes.
Each customer workspace is designed to run in its own service. Permissions add another boundary inside that workspace. Confirm the hosting and storage arrangement for your deployment.
a7i.aiSecurity is a series of checks around your workspace, your identity, your content and the tools acting for you. Each layer has a job. Together, they help keep access deliberate and limit what a mistake can expose.
Updated 25 October 2026 · Product protections and their boundariesEach customer workspace is designed to run in its own service. Permissions add another boundary inside that workspace. Confirm the hosting and storage arrangement for your deployment.
Server-side file access rules check ownership and sharing scope. The same access boundary is used by tools, so asking an agent for a file is not intended to bypass the permissions on it.
Shared runs restrict access to personal files. Rooms use their shared transcript rather than personal session memory. Team access to supported account connectors is governed by explicit connection grants.
The connection system keeps account credentials out of ordinary tool results and sends them only to the service they belong to. It checks the information supplied to a tool before contacting that service.
In the connector framework, shared rooms and team agents have read-only account access. Actions marked as requiring approval are refused when their approval flow is unavailable. This is not a promise that every tool has the same confirmation workflow.
The web app tells browsers to block other sites from embedding it and limits access to device features. It also supplies secure-connection and content-handling protections. A broader check on loaded content currently reports problems rather than blocking them.
These protections are live for workspaces on a7i.ai today.
Signed-out visitors see the same sign-in page at every workspace address, whether or not a workspace is there. A failed sign-in gives the same answer for an unknown workspace, an unknown email address or a wrong password.
Failed sign-in attempts are limited for each network and for each account. After several failures in a row, further attempts on that account pause for a short time, and the pause grows if the failures continue.
A session works only in the workspace where you signed in. The token that keeps you signed in is replaced each time it is used. If a used token turns up again later, that sign-in is ended.
We do not store your password itself. It is hashed with PBKDF2 using 600,000 iterations. Passwords saved under our older, lighter setting are upgraded the next time their owner signs in.
a7i.ai recognises the browsers you sign in from. In Settings, you can see where you are signed in, sign out of another device or sign out everywhere at once. A sign-in from a new browser is recorded for a new-device alert. Alert emails are not switched on yet, so review your devices in the app.
If someone is locked out, an a7i.ai administrator or a workspace owner or admin can issue a reset after confirming who they are. It creates a one-time link that works once, for one hour. Issuing it ends every existing session for that account and is recorded in an audit log. Members cannot reset a workspace owner, and guest accounts cannot be reset this way.
Private chat prevents the application from saving conversation content in its history, memory log and run records. It also suppresses log messages and error details that could reveal the private conversation.
Usage records may remain. Files and other artifacts created by tools can still be saved. Cloud models and connected services can still process the information needed for the request. Read the private-chat explanation.
The supported cloud deployment keeps service credentials in a managed secret store. On developer Macs, the approved launcher uses the Mac Keychain instead of storing secrets in ordinary configuration files.
Additional file-storage and local database encryption exist in the codebase, but are off by default. Their presence in the product does not mean they are enabled for your workspace. Cloud-managed encryption is a separate layer and depends on the storage service used.
Before relying on an encryption requirement, confirm the deployment’s storage settings, key custody and recovery process. We do not describe the whole workspace as end-to-end encrypted or promise that only you can decrypt all workspace data.
This page describes product capabilities, not an audit of every live workspace. Controls that depend on configuration must be checked in the environment where your data is held.
Use our contact page to report a suspected vulnerability or unexpected access. Include the affected page or feature, the time and safe steps to reproduce it. Do not send passwords, access tokens or someone else’s private content.
These pages do not claim an independent security certification, a guaranteed response time or protection against every threat. We aim to make the protections—and the work still ahead—understandable.
Explore our approach to your data → · Privacy policy · Service providers