Data & security
Understand organization isolation, visibility, passwords and keys, and Telegram’s effects when evaluating Soulhall.
This page describes data boundaries enforced by the product code to help you evaluate team use. Confirm deployment backups, storage regions, and external service terms with the operator.
Data boundaries
| Scope | How the product handles it |
|---|---|
| Different organizations | Office, Subject, and knowledge queries are scoped to the current organization. Identical names do not share knowledge. |
| Managers in one organization | See only Offices open to them or the whole organization, and Subjects they created or that work in visible Offices. |
| Admins and Owners | See the organization’s Offices and Subjects. Restricted Office visibility does not hide them from these roles. |
| Different Embodiments of one Subject | Share the Subject’s existing knowledge, not Office conversations or local experience not yet distilled into the Subject. |
| Public handbook | Sharing a handbook URL grants no access to Offices, results, files, or account settings. |
The server determines an Embodiment’s knowledge scope from its identity. It cannot choose another organization’s knowledge. Work experience goes into its own knowledge first. Processing then decides what belongs in the Subject; not all conversation becomes shared knowledge directly.
Inaccessible content is absent
Offices and Subjects without access do not appear in lists, even greyed out. Opening their URL returns only That Office could not be found or That Subject could not be found.
New Offices restrict visibility by default, listing only the creator. Admins and Owners still see them. Set Visible to in the Office’s Settings › Visibility, or uncheck Restrict this office.
Where passwords and keys are stored
| Data | Storage and display |
|---|---|
| Model API keys | Protected secret storage. The database holds only a reference; keys are not shown after saving. |
| External integration API keys and sign-in authorization | Secret storage. The integration service does not return them to the interface. |
| Vault passwords and API tokens | Stored separately from ordinary data. The interface shows names, sites, purposes, and similar information, not secret values. |
| Research keys | Shown once on issuance. The database stores a hash; the original key cannot be retrieved from the list. |
| Soulhall sign-in passwords | Salted hashes, not readable originals. Admins can replace passwords, not read old ones. |
Let Embodiments use credentials without reading passwords
Store external accounts in Organization › Connections & credentials › Credentials, then grant them to Embodiments that need them. Embodiments can sign in through grants, but tools do not reveal passwords. Soulhall adds API tokens to service requests, restricted to the credential’s site.
The vault does not show passwords again. Use Rotate password to update them and Revoke when a grant is no longer needed. See Browsers, credentials & integrations.
Restrict research keys to one workspace
A research key is bound to one Office’s research workspace. Every use rechecks expiry, revocation, organization membership, Office visibility, required password changes, and whether research settings and workspace still match.
Revocation disables every use of that key. Do not share a colleague’s key. If yours is lost, revoke it and issue a new one. See Research keys.
Reports display separately from your sign-in
Reports are Embodiment-generated documents displayed in isolation from Soulhall’s signed-in pages. They can run chart code but cannot read your Soulhall sign-in cookies, Soulhall browser storage, or call Soulhall as you. The same isolation applies when opening a report document URL directly.
This restricts the document’s execution environment; it does not guarantee accurate content. Check the evidence in results yourself.
Manage sign-in passwords
Soulhall passwords need at least 12 characters. After signing in with an Admin-set initial or reset password, you must change it before using work pages.
Changing your own password requires your current password and ends other sign-ins. When an Admin sets a new password, all sign-ins end. See Members & roles.
Decide how far Telegram groups can reach
After a bot joins a group, someone signed in to Soulhall who can manage the Office must select Confirm this group to establish the connection. One Office connects to one group. Office messages then go to the group, and group content enters the Office’s conversation context.
Two independent controls appear in the Office’s Settings › Telegram:
- Let conversations in this group teach the Subject: on by default. When off, group experience stays with local Embodiments and is not distilled into the Subject through this source. Embodiments still learn in this Office.
- Let this group set outward actions in motion: on by default. When off, all Embodiments in the Office lose outward-action tools such as browser operation, external sign-in, and connected services—not just for Telegram requests. Reading web pages, files, tasks, reports, and memory remains available.
Review both switches when group membership changes. Select Disconnect to stop exchanges. See Telegram.