Security and data isolation
How Hyperstruck protects customer data through tenant isolation, encryption, and access controls.
In one line
Every tenant's data is isolated at the database level. Credentials are encrypted. Access is scoped by API key, organization role, and fine-grained authorization on agents and spaces.
Hyperstruck is built for teams that need to trust the platform with sensitive operational data: agent configurations, learnings drawn from real workflows, claims about real customers, and provider credentials. This page explains how the platform protects that data.
What an agent remembers, and how each part is protected
The three things an agent keeps from a finished run carry different risk, so they are protected differently. One policy could not have covered all three.
| What it holds | How it is protected | |
|---|---|---|
| Learnings | Short, conditional rules, meant to travel between agents | Scrubbing. Credentials and personal data are stripped before storage, and the original wording of a request is never kept, only a scrubbed description of the task |
| Claims | Specific facts about named entities | Boundaries. A claim cannot be scrubbed without destroying it, so every claim is private by default, fenced in the database, and erasable per entity |
| Episodes | The raw record of a run | Classification. Sensitivity is derived from the trace itself, and an unreadable stored value fails toward private |
A learning is shared beyond a single agent only when it is general, well proven, and free of anything specific or sensitive, and even then only the generalized rule crosses. Sharing and visibility sets out the full gate, what is stripped on the way, and why claims have no equivalent path.
On erasure, be precise about what is available today. The claim-layer erasure is a real, callable operation: it removes an entity's claims, aliases, dossier and split proposals, unwinds the support those claims lent to your agent's learnings, and returns a receipt naming what it did not reach rather than implying a completeness it does not have. Run-record erasure exists in the runtime but has no public endpoint, so it is not something you can exercise through the API yet, and the claim-layer receipt says so. That receipt also names the learnings store itself among what it does not reach: the support is unwound, but the learnings are generalized and survive. Anyone answering a formal erasure request should read Episodes before promising coverage.
Tenant isolation
Every customer operates in a fully isolated tenant. Data isolation is enforced at the database level through row-level security (RLS) policies. Every table that stores customer data has an RLS policy that restricts access to the owning tenant. This is not application-level filtering. It is enforced by the database engine itself, which means a bug in application code cannot leak data across tenants.
Each API request is scoped to a tenant through the authenticated API key or portal session. The tenant context is set at the database connection level before any query executes.
Claims carry a further layer, because they are the records most likely to name a real person. An agent sees only its own claims. A human curating sees one organization's claims across its agents, and cannot name an agent they do not own. Underneath both sits a tenant floor that can only narrow access, never widen it, plus a further restriction by space. Two properties fall out of that design: a caller that forgets to identify itself sees zero rows rather than too many, and a claim that cannot be attributed to an organization cannot be written at all, because a claim nobody can find is a claim nobody can erase.
Scoping is applied per transaction rather than per connection. A pooled connection handed to the next tenant carries no leftover scope from the last one, which is the failure mode that would otherwise be load-dependent and survive testing.
Access control
Hyperstruck uses a two-layer authorization model:
- API key scopes — coarse capability checks (
agents:read,agents:execute,claims:curate, …) enforced on every route. - Fine-grained access — object-level permission checks on specific agents and spaces, backed by a Zanzibar-style authorization model.
Both layers must pass. Organization membership roles (owner, admin, developer, viewer) derive portal session scopes. Programmatic API keys carry explicit scopes with org-wide or per-space reach.
For the full permissions matrix, space kinds, API key scope reference, and separation-of-duty rules, see Access control (FGA and RBAC).
Credential encryption
Provider credentials (LLM API keys for OpenAI, Anthropic, Groq, and others) are encrypted at rest using AES-256-GCM with per-tenant encryption keys. The platform never logs, exposes, or returns credential secrets through the API. When you retrieve credentials through the API, you see metadata (provider, scope, status) but never the key itself.
Enterprise SSO
Enterprise customers can connect Hyperstruck to their identity provider so users authenticate through company-managed SSO. Organization roles sync from your directory into the tenant. This lets security teams centralize access, enforce existing identity policies, and offboard users from a single source of truth.
PII masking
Hyperstruck offers guardrails that detect and mask personally identifiable information before it reaches the LLM. This is available as an add-on for Pro customers and included for Enterprise customers. PII masking is configurable per agent and can be combined with prompt-injection prevention. See Agent configuration for the settings.
Guardrails screen what goes in. Grounded success governs what comes out, refusing to let a run report success it cannot ground in something it actually observed. They are separate controls and both matter.
Rate limiting
API endpoints are rate-limited per tenant to prevent abuse and ensure fair access. Rate limits are enforced transactionally at the database level, not through an in-memory cache, so they remain accurate under concurrent load.
Infrastructure
Hyperstruck runs on managed cloud infrastructure with encryption in transit (TLS) and at rest across all storage layers. The platform does not store raw LLM conversation logs beyond what is needed for session history and learning extraction.
Related pages
- Security and governance for the leadership-facing view of these controls
- Agent configuration for per-agent PII and prompt-injection settings
- Access control (FGA and RBAC) for scopes, roles, spaces, and the permissions matrix
- Credentials API for managing provider credentials
- Agents API for API key authentication
- Pricing for details on which tiers include compliance features