Henry works with your team's conversations, files, and connected tools, so protecting that data is the core of the product rather than a feature bolted on later. This page describes, in plain terms and without inflation, how Henry AI Technologies LLC ("Henry", "we") builds and runs the Service. Where something is still in progress, we say so.
Overview
- All customer data is stored in the United States.
- Every Workspace is isolated at the database layer with row level security, not only in application code.
- Data is encrypted in transit and at rest; secrets and integration tokens get a second layer of encryption under per-Workspace keys.
- Our admin tooling cannot display your messages, memories, or knowledge; direct database access is limited to Henry's two founders, protected by multi-factor authentication, and logged.
- Your data is not used to train AI models, ours or our providers'.
- Consequential actions in your connected tools require a human to confirm them.
- The Agent Browser runs in a cloud browser isolated to one user, and Henry never handles your passwords.
Infrastructure and hosting
The Henry application and its serverless functions run on Vercel in the US West (Oregon) region. Our database and file storage run on Supabase, hosted on Amazon Web Services in us-west-2 (Oregon). Both are managed platforms that handle physical security, network hardening, and patching of the underlying infrastructure. Customer data does not leave the United States for storage. The Agent Browser runs on Browserbase, a US cloud browser provider. The AI providers we use are also US-based; see /subprocessors for the full list.
Tenant isolation
Each Workspace is a tenant. Access to every tenant-scoped table is governed by Postgres row level security policies keyed to a Workspace claim that is set for each request, so a query can only ever return rows belonging to the Workspace making it. Application code adds Workspace filters as a second, independent layer. An automated test suite exercises the isolation rules on every code change so a regression cannot merge unnoticed.
When Henry runs code on your behalf, it does so inside a dedicated sandbox microVM for your Workspace. The sandbox's outbound network access is locked to Henry's own gateway, so code cannot reach arbitrary hosts on the internet, and its run credentials expire after 24 hours.
Encryption
- In transit: all connections to Henry, and from Henry to its providers, use TLS 1.2 or higher.
- At rest: database and file storage volumes are encrypted with AES-256.
- Secrets: integration credentials, custom connector tokens, customer-supplied model API keys, and other secrets are encrypted a second time with AES-256-GCM before they are written, using envelope encryption with a separate data key for each Workspace.
- Key rotation: the encryption scheme supports rotating both the root key and any single Workspace's data key; previously encrypted values remain readable during rotation and are re-wrapped under the new key. Each ciphertext is also bound to its Workspace and purpose, so a value copied from one column to another fails to decrypt instead of leaking.
Authentication and access
You can sign in to Henry with a one-time code sent to your email, with Google, or with an optional password. Any account can add two-factor authentication using an authenticator app (TOTP). Enterprise Workspaces can require SAML single sign-on with their identity provider; we verify domain ownership before enabling it, provision users just in time on first sign-in, and can enforce SSO so that other sign-in methods are turned off for the Workspace.
Inside a Workspace, access is role based (owner, admin, member). Admins control who can use which integrations and tools on a per-member basis, and removing a member cuts their access on their next request. Sign-in routes are rate limited with shared, durable counters keyed by a hash, never by a raw IP address or email.
Human confirmation for consequential actions
Henry can act in your connected tools, but it does not do so silently. Actions with consequences (sending a message, creating or changing a record, and similar) are presented to the requesting user for confirmation before they run. Workspaces can grant standing approvals for specific low-risk actions they trust, and every tool call, whether confirmed by hand or auto-approved, is recorded in a tool call log. Enterprise Workspaces can review and export an audit log of every tool call and every administrative settings change (SSO, model keys, members, exports) from Settings.
Agent Browser
The Agent Browser lets Henry operate a real web browser on your behalf. The browser runs on Browserbase, a cloud browser provider, never on your device or on our servers, and every session is isolated to a single user. Each site you sign the browser in to gets its own browser profile for you alone. The reference to that profile is encrypted under your Workspace's data key, never enters the model's context, and is deleted at the provider, with the deletion verified, when you sign out of the site, disconnect the browser, or your Workspace is deleted.
- No credentials. Henry never sees, stores, or types passwords or verification codes. When a site needs a sign-in, you receive a secure link to a live view of the browser and type them yourself. The browser turn has no access to email, texts, files, or memory, so there is no one-time code for it to read, and an instruction to type a credential is refused in code, approval or not.
- One approval, one action. Anything that cannot be undone (placing an order, submitting a form, sending a message, changing account settings) stops and asks you in the thread. An approval is consumed by the single action it authorizes and cannot be replayed, and the same action with different specifics asks again. Page content cannot approve anything.
- Containment. Navigation is confined to the task's site, and the first off-site landing ends the turn. Text on a web page is treated as data, never as an instruction. Major banking, brokerage, and payment sites, and a small set of other categories, are blocked for everyone in code before a task is ever created. Sites covered by a connected integration are routed to the integration instead. Workspace admins can disable the Agent Browser or limit it to approved sites.
- Review. Sessions are recorded at the provider, and screenshots are stored for 30 days so work can be reviewed, then deleted automatically. Every task appears in the user's activity log. Deciding whether an action is irreversible is a heuristic backed by a code-level guard, not a structural guarantee, which is why the structural protections above exist.
Integration credentials
Most integrations connect through Pipedream Connect or Composio. In that model, the OAuth tokens for your third-party tools are held by those providers and never by Henry; Henry asks them to perform an action and receives the result. For first-party custom connectors and MCP servers, where Henry does hold a credential, the token is encrypted at rest under your Workspace's data key as described above. API keys or tokens that appear in captured channel content are detected and redacted before storage.
Staff access
Our internal admin panel is restricted to a small set of designated staff and requires a TOTP second factor for every session. It is built so that staff cannot read customer content: messages, memories, knowledge, task instructions, email bodies, and tool payloads are not retrievable through it by construction, not merely by policy. Every staff action that changes anything writes an append-only audit record capturing who acted, on what, the before and after state, and the IP address and user agent; staff read logs are retained for 180 days. Outside the admin panel, direct access to the production database is limited to Henry's two founders, requires multi-factor authentication at the database provider, and is logged there; it is used to operate the Service, never to read customer conversations. Henry staff do not review your conversations. If you rate a reply with a thumbs up or down, that feedback is stored within your Workspace.
Data handling with AI providers
To answer a request, Henry sends the model the content it needs: the conversation, relevant memories and knowledge, results from connected tools, and any attachments. Requests are routed through the Vercel AI Gateway to models from Anthropic, OpenAI, xAI, and Moonshot AI. Under our commercial terms with these providers, your data is not used to train their models, and Henry does not train models on your data. Moonshot AI's Kimi models are served only by US inference hosts (Baseten and Fireworks AI) and requests are pinned there. Web searches the model chooses to run go through the gateway's search provider; voice messages are transcribed by ElevenLabs; and knowledge is embedded for retrieval using Voyage AI. All of these are listed with their roles at /subprocessors. Enterprise Customers can supply their own Anthropic or OpenAI API key, which we store encrypted under the Workspace's data key.
Data retention and deletion
You control your data's lifecycle. At any time an owner or admin can export a complete, machine-readable archive of a Workspace (available for 7 days, through admin-only download links generated per click and valid for minutes), turn channel capture off per channel, purge captured content for a channel, and delete conversations. Agent Browser screenshots are deleted after 30 days, and disconnecting the browser deletes your saved sign-ins at the provider. Deleting a Workspace runs a verified hard-delete process: our staff run a dry run that reports exactly what will be removed, the deletion is then executed and verified, and only a redacted deletion record is kept as proof. Conversation history is otherwise retained for the life of the Workspace; captured channel content is retained while capture is enabled. Details are in the Privacy Policy and DPA.
Secure development
Changes to Henry are reviewed and must pass automated checks before they deploy: tests, lint, type checking, a production build, the tenant isolation test suite, and a migration check that proves the full database schema applies cleanly. Database migrations are append-only and must stay backward compatible with running code. Dependencies are reviewed and updated regularly. Deployments are immutable and can be rolled back to a previous version instantly.
Availability and continuity
Henry runs on managed infrastructure with daily automated database backups. Model requests fail over automatically across multiple AI providers, so an outage at one provider does not take Henry down. We do not offer a formal uptime SLA on self-serve plans; enterprise Customers can agree an SLA in their Order Form. We do not yet publish a public status page.
Compliance
Our controls are designed to align with SOC 2. We are preparing for a SOC 2 Type I examination, with a Type II examination to follow. We do not yet hold a SOC 2 report and will not describe ourselves as certified until we do. We offer a GDPR, UK GDPR, and CCPA-ready Data Processing Addendum that incorporates the EU Standard Contractual Clauses and the UK Addendum. Henry is not HIPAA compliant, does not sign business associate agreements, and should not be used to process protected health information. Henry is not currently certified under the EU-US Data Privacy Framework.
Responsible disclosure
If you believe you have found a security vulnerability in Henry, please email security@usehenry.ai. Include the affected URL or component, steps to reproduce, the impact you observed, and any proof-of-concept material. We will acknowledge your report, keep you informed as we investigate, and credit you if you wish once the issue is fixed.
We support good-faith security research. If you follow this policy, make a good-faith effort to avoid privacy violations, data destruction, and service disruption, access only the minimum data needed to demonstrate the issue, and give us reasonable time to fix it before disclosing publicly, we will not pursue legal action against you or refer you to law enforcement for your research. Do not test against other customers' Workspaces; create your own. We do not run a paid bug bounty program at this time.
Contact and security documentation
Prospective and current Customers can request our security documentation, including completed security questionnaires and an architecture overview, by emailing security@usehenry.ai. Our SOC 2 report will be available under NDA once the examination is complete. For privacy questions see privacy@usehenry.ai, and for the full list of the third parties that process data on our behalf see /subprocessors.