Skip to main content
Hebno is built so that it can only read what the person using it can already open, and so that it never changes a client system without a person confirming. This page explains the access model so you can answer a client’s security questionnaire from one place.

​
Access follows the member

When a member connects Microsoft 365, Google Workspace, Slack, a CRM or a project tool, Hebno reads and writes with that member’s own permissions in the other system. A member never sees anything through Hebno that they could not open directly.
  • A SharePoint file the member cannot open does not appear in a search.
  • A mailbox other than the member’s own is not reachable.
  • A Google Drive folder is read with the member’s Drive credentials.
Organisation connections, used for finance, ERP and project systems, work differently: an admin connects them once with an integration user, then restricts them by team and data area. Financial figures default to owners and admins only. See Permissions and access.
Enabling Microsoft 365 or Google Workspace for the organisation removes a consent screen. It does not widen what any member can open.

​
How Hebno reads your data

Documents from the sites, drives, libraries and spaces your admins select are kept in an index in your organisation’s region, with source permissions recorded and checked at search and again at read. CRM, ERP and finance records are queried live and never copied. Email, calendar, meetings and chat messages are searched live in the member’s own account and never enter the shared index. Excerpts a reply actually uses are stored with the conversation so its sources remain available. See Data handling.

​
Writes need a person

Hebno never writes to a connected system on its own. A proposed change appears as a confirmation card with every field editable. Nothing is written until a member selects Confirm, or Send for email and calendar invitations. Agent runs use the same rule: their proposed writes appear in agent approvals until confirmed. Finance and ERP writes create drafts only. Hebno never approves, posts, sends or pays. Admins can set any integration to Read only under Connectors, which removes write cards for that system.

​
Roles inside Hebno

Projects add their own admin and member roles. Within a conversation, owners, collaborators and viewers control who can send. See Roles and permissions. Admins can suspend a member immediately and revoke any member’s connection. Both are recorded in Logs.

​
Sign-in

Members sign in with Google, Microsoft, or email and password. Invitations expire after 7 days and only work for the invited email address. Domain access can admit people who sign in with a verified company domain; shared mailbox providers cannot be used.

​
Encryption and isolation

  • Connection tokens and credentials are encrypted at rest with AES-256-GCM.
  • Data is encrypted at rest and in transit using TLS 1.2 or higher.
  • Every request is scoped to your organisation. Members of one organisation cannot read another’s conversations, files, projects or connections.
  • Uploaded files are stored privately.

​
Keep a person in the loop

Hebno attaches sources to the work it produces so a reviewer can check claims against the original. Each finding is marked Supported, Inferred or Uncertain, and members can run Verify against sources on a deliverable. See Sources and evidence.

​
Where to read more

Data residency

EU or US hosting, chosen when the organisation is created.

Data handling

What is stored, for how long, and how it is deleted.

Audit trail

What Hebno records and how to review and export it.

Support

Security questions, a data processing agreement or a vulnerability report.