What it keeps, who can reach it, and how it goes.

Risky changes wait for a person

A claim that could do harm if it is wrong is held, and your agent keeps the value it had.

• Mark an attribute protected, such as a payee or a bank account, and a change from an untrusted channel or from an API key waits beside the current value until a person settles it.
• Each settlement records who made it and when, and the claim's line shows it. A key may mark an attribute protected; only a person may lift the mark.
• Claims that arrive through a channel an attacker could reach, such as an open-web search tool, are held and never reach your agent's recalled memory.

Erased with its source

Deleting something removes what rested on it, and tells you what went.

• When you delete a document, its encryption keys are destroyed first, so the stored file and its extracted text become unreadable at once.
• The claims and learnings that rested only on that document are deleted with it, and you get a receipt that counts what was removed.
• Erasing an entity removes its claims, aliases and dossier, takes back the reinforcement those claims gave to learnings, and returns a receipt that names what the erasure did not reach.
• Deleting an agent erases its claims and documents with it.

Access by role

Spaces, roles and keys decide who can read, write, curate and administer.

• Spaces carry steward, contributor and subscriber roles, and fine-grained authorization decides who can read, write, curate and administer.
• Each API key carries explicit scopes and is limited to the spaces chosen for it, unless it is created for the whole tenant.
• A key that runs agents cannot also curate or erase claims, and a run never inherits its key's right to correct claims.
• Every request, apart from health checks and sign-in, needs a valid key or a signed-in session, and the hosted MCP server refuses a request without a key.
• Portal sign-in runs on WorkOS, and enterprise customers can connect their own identity provider and verify their email domain, set up with our team.
• Portal sessions are held in an HTTP-only cookie, and the sign-in callback is checked against forgery with a signed state.
• New people who sign in can be provisioned automatically on first use, and that setting can be turned off.

Cost you can see

Usage is reported, and spend can be capped.

• Usage is reported through the usage API.
• Asking a question of your agent's claims is free.
• Hyperstruck can set a hard spend cap on your tenant, and past it new paid requests are refused.
• Requests for reporting runs, recall and claim questions are rate limited for each tenant and key.

Foundations

How the platform keeps one customer from seeing another.

• Every table has row-level security, the API connects as a role that cannot bypass it, and a deploy check fails the release if either stops being true.
• Document files and their extracted text are encrypted with AES-256-GCM. Each document version has its own data key, wrapped under a key for your tenant, which is wrapped under a master key, and key ids let keys rotate without re-encrypting anything.
• Hyperstruck operates the keys, so this protects the stored copies rather than keeping documents from us, and copies derived from documents (search excerpts, the claims drawn from them, and stored answers that quote them) are not encrypted: erasing a document deletes them rather than shredding them.
• The API is served over HTTPS with strict transport security, and plain HTTP is redirected.
• Our production database is in Sydney, Australia.
• On the hosted MCP server, credentials, card numbers, IBANs and email addresses are replaced before your text reaches Hyperstruck.
• A claim that contains a credential is refused.

Report a vulnerability

Tell us and we will answer.

Send security reports to security@hyperstruck.com.