HookieHow Hookie keeps your data
What the product does to protect what you send it, stated plainly. Each item below describes how Hookie works today; nothing here is a plan.
Credentials and secrets
Keys are stored as hashes
Ingest keys, admin API keys, Data API keys and customer-portal access tokens are stored as SHA-256 hashes and looked up by that hash. The plaintext is shown once, when it is issued, and cannot be read back — by you, by support, or by anyone with the database.
Secrets are encrypted at rest
Destination signing secrets and credentials (including a Slack destination's incoming-webhook URL, which is only ever shown masked, an S3 or SQS destination's secret access key, and a Pub/Sub destination's service-account key and the access tokens minted from it), ingest signing secrets and database-source connection settings are encrypted with AES-256-GCM, under a 256-bit key held as a platform secret, before they are written, and the API never returns them in a listing. Each value records which key encrypted it, so the key can be rotated. Revealing or rotating a signing secret is limited to owners and admins, and is audited.
Isolation
Workspaces and projects are separated on every query
Every stored row carries its workspace, and project-scoped rows carry their project. Every read and write filters on both, taken from your signed-in session or the credential that was presented — never from the request body, so a request cannot name its way into another workspace.
Roles, including for keys and agents
Owners, admins, developers and viewers get what their role allows, checked on the server for every call. An API key carries its own role and never exceeds the person who created it.
Invite links that work once
Teammates join through an invite link an owner or admin creates for one role; Hookie sends no email, so you choose how it reaches them. A link works once and expires after 7 days, only its hash is stored, and a wrong, expired, revoked or used link gets the same answer, so it cannot be guessed at. Only a person can create or accept one — never an API key or a connected agent — and every invite, role change, removal and ownership transfer is in the audit log.
Google Workspace teams, proven by Google
An owner can link a workspace to their company's Google Workspace domain, so colleagues who sign in with Google join it. The domain comes from Google's own hosted-domain claim, checked when you sign in, and never from an email address: a personal Google account on a company address, an emailed-code or GitHub sign-in, and gmail.com never join. One workspace per domain, the role it gives is viewer or developer (never admin), plan member limits apply, people who were removed are not brought back, a disputed domain can be reassigned only by Hookie's operators, and linking, unlinking and every join are in the audit log.
Connected agents and scopes
An agent acts as you, never as more
A coding agent you connect over OAuth — Claude, Claude Code or any MCP client — acts as the person who approved it. What it may do is the narrower of your role and the scope you granted: read (hookie:read), write (hookie:write) or manage (hookie:manage). Manage stops at an admin's powers, so no agent ever reaches billing, and none can invite, remove or change the role of anyone in your workspace.
Read-only until you widen it, revocable on its own
A newly connected agent starts with read access only; you widen it in the console. Revoking one agent cuts it off on its very next request, without signing you or any other agent out. The grant is Hookie's own record, checked on every call, not something the agent's token can claim for itself.
Tokens are checked for who issued them and who they are for
Sign-in and agent authorization are run by WorkOS. Hookie verifies each agent token against WorkOS's published signing keys, and accepts it only from this environment's issuer and only when it was issued for Hookie's own MCP address, so a token minted for another service is refused.
The console
A separate origin with a strict CSP
The console runs at app.hookie.ai, apart from this marketing site, so nothing this site loads can run there. It is served with a Content-Security-Policy that allows only its own scripts, styles, fonts and connections, and forbids framing. Every state-changing API call must also carry a request header a cross-site page cannot send.
Sign-in through WorkOS
Sign-in — an emailed one-time code, or a social provider where one is enabled — runs on WorkOS's User Management API. The session is an encrypted, HttpOnly, Secure cookie, and the WorkOS token inside it is verified against WorkOS's published signing keys. Hookie stores no passwords.
Delivery
Every delivery is signed
Each outbound webhook is signed twice over one timestamp: a Hookie-Signature header and the Standard Webhooks webhook-id, webhook-timestamp and webhook-signature set, so your receiver can verify it with whichever library it already uses. Rotating a secret signs with both old and new for 24 hours.
Inbound checks before anything is stored
An ingest key can require a signed payload, and the signature is checked before a byte is written. IP allowlists apply per key and per workspace, and ingest is rate-limited at the edge.
Retention, erasure and audit
Data is kept for your plan's window, then pruned
Events, raw submissions, delivery history, AI call logs and workflow runs are kept for 7 days on Free, 30 days on Pro and 90 days on Team, then pruned automatically. A delivery still being attempted, or a workflow run still going, when its window ends is kept until it finishes.
Delete, export or close whenever you like
You do not have to wait for retention. Deleting a record removes every copy Hookie keeps of it — the raw submission, its delivery history and replays, the workflow runs it started and the AI output it produced — immediately. An owner or admin can purge a whole dataset, or export everything in the workspace as one file with every secret left out. Closing a workspace suspends it at once and permanently deletes its data 14 days later.
An append-only audit log
Who changed what in your workspace — a rule edited, a key revoked, a portal removed — is written to an audit log that cannot be altered, and none of it younger than a year can be deleted. You can read and export it from Settings.
Subprocessors
The companies that process personal data on Hookie's behalf — hosting, sign-in, billing — are listed, with what each one handles and where, in the Privacy Policy. Destinations and log vendors you configure yourself are transfers you direct, not Hookie's subprocessors.
The full detail of what is kept, for how long, and how to delete or export it is in the Privacy Policy's data retention section. To verify deliveries in your own receiver, see Verify signatures.
Responsible disclosure
If you think you have found a vulnerability in Hookie, write to [email protected] with what you found, how to reproduce it, and what an attacker could do with it. Use the same address if you suspect someone has reached your account.
Good-faith research is welcome on the terms of the Acceptable Use Policy: with our authorization first — ask at the same address — and without accessing another customer's data, degrading the service or taking data out of it. Please give us a chance to fix an issue before you publish it. Hookie does not run a paid bug bounty.