Hane Platform

Security and data handling

Organization isolation, credentials and token exchange, short-lived internal tokens, secrets, boundaries around AI runs, where data is stored, and what Hane never sends out.

This page explains how Hane protects your data and permissions. It covers organization isolation, the boundaries around AI runs, and where data is stored, together with what is available today.

Organization isolation

The organization is the unit that separates data and permissions.

Each organization’s data lives in storage of its own. Organization settings, business data per environment, and the audit log each live in a Durable Object per organization (per organization and environment for business data), never shared with other organizations.
Projects are separated inside the organization by keys and authorization.
The organization of a request is determined from its credentials. Hane never trusts an organization ID written in a URL or body. Pointing at another organization’s resource gets the same response as a resource that does not exist.
Definitions changed in your apps cannot turn these rules off.

Network restriction

Hane’s screens and API are not reachable from just anywhere on the internet. The gateway checks where a request comes from before it looks at any credential.

Only requests from the networks your organization registered are accepted. Each organization registers the public IP addresses (CIDR ranges) its offices and VPN use to reach the internet. Requests from anywhere else are refused, including the login screen.
A valid credential does not work from another organization’s network. Once the credential identifies the organization, the gateway checks again that the request comes from a network that organization registered. A leaked token or API key cannot be used outside your registered networks.
Owners and admins change the list in the console under “Network restriction” or with PUT /v1/platform/network-policy. Changes take effect within 30 seconds and are recorded in the audit log. A change that removes the network you are connecting from is refused, so you cannot lock yourself out.
Hane’s own staff enter through a separate path (the provider path, which requires an additional identity check). On that path, the gateway checks that the person who passed the identity check is the same user as the credential’s.

Hane holds no passwords. There are two ways to log in.

Method	For	Details
Company IdP (SSO)	Organizations with an IdP	Log in with an IdP that supports OIDC (Microsoft Entra ID, Google Workspace, Okta and others). Once an organization registers an IdP, it accepts only logins through that IdP. A user disabled at the IdP loses access within 12 hours
Emailed login code	Organizations without an IdP	Log in with a 6-digit code sent to the address you were invited with. A code expires after 10 minutes and stops working after 3 wrong attempts. No code is sent to an address that was not invited

An IdP can log in only users of the email domains registered for it. A domain can be registered by one organization only.
A user is identified by email address. The same person stays the same user before and after the organization registers an IdP.
A login session lasts 12 hours. The session itself cannot call the API; it is exchanged for the access token below.

Credentials

Credential	Used by	Properties
API key	Service accounts (your apps, CI)	Bound to a project and environment. Shown once when issued; Hane stores only its hash. Revoked keys are rejected from the next request
Access token	Users	A 15-minute token obtained by exchanging the login session (or, from your app, the IdP’s id_token) at `POST /v1/auth/token`. Bound to an organization, project, and environment

Every change to roles, groups, or API keys raises the policy epoch, and tokens issued under an older epoch are rejected. Removing a permission takes effect without waiting for tokens to expire.

When your app calls the public API, it does not pass the user’s IdP token through. It exchanges it for a short-lived token that carries the user. Approval deciders and reveals of contact values are recorded and checked against this user. See Authentication.

Short-lived internal tokens

Inside Hane, long-lived credentials are not passed around either.

Token	Lifetime	Purpose
Internal token	60 seconds	Carries the organization and user verified at the entry point to the core API
RunToken	Matches the run’s time limit (at least 5 minutes)	Lets an agent run call the Tool Gateway. Rejected as soon as the run is stopped
Model RunToken	Same as above	Lets an agent run call the Model Gateway. Separate from the Tool Gateway token; mixing them up is rejected
Backend credential	60 seconds	Passed on each call to your API
Cowork model credential	5 minutes	Lets Hane Cowork call the Model Gateway

Secrets and encryption

Connection secrets are encrypted with a data key (DEK), which is itself wrapped with a key-encryption key (KEK). Once saved, values are never returned by the API or the console.
Secrets are used only by import jobs and authorized calls to your APIs. They are never given to agents or models.
Phone numbers and addresses of contact endpoints are also encrypted with a key per endpoint. Screens and approvals show only masked values. Seeing the full value needs a separate permission, and each reveal is recorded in the audit log.

Boundaries around AI runs

Agents can read and write business data only through the Tool Gateway, and only with tools listed in their definition.
CLI drivers run in sandbox containers with no internet access. They can reach only the Tool Gateway and the Model Gateway; other destinations are refused and recorded. The CLI’s built-in tools (shell, file editing, web fetch, and so on) are turned off.
Outbound actions such as email, calls, and updates through your APIs are fixed by recipient and content with a digest, and run exactly once after approval. The person who asked for an operation cannot approve it.
Document text, incoming email, what a callee says, and tool results are treated as untrusted input. Instructions in them never widen permissions.

What Hane never sends out

Never sent	Details
Model provider API keys	Kept inside Hane; never given to sandboxes or employees’ PCs
Connection secrets	Never exposed to agents, models, API responses, or logs
Callers’ credentials	When forwarding to your API, the caller’s token and cookies are not passed on
Model input and output text	Model Gateway call records keep token counts and outcomes only, not prompts or responses
Credentials in saved conversations	Saved conversation context contains no RunTokens, API keys, or credentials

Where data is stored

Hane runs on Cloudflare as SaaS operated by the provider.

For features that use models, prompts pass from the Model Gateway to the upstream model provider. How the provider handles that input depends on the provider’s terms. When you try Preview features, we recommend using fictional data rather than real business data.

Stopping and deleting

Emergency stop: Anyone with platform:suspend can immediately stop every API and run in the organization (POST /v1/platform/suspension). Only the owner can lift it.
Operator engagements: When the provider’s operators work in your project, they need an engagement whose scope and period your administrator sets. Operators never become members of your organization, and their operations are recorded in the audit log with the engagement ID.
Deletion and holds: When documents and contact endpoints are deleted, Hane records the outcome for each derivative. Nothing is deleted while a hold is in place. Automatic deletion of documents by retention period is not yet available.