Security

Each customer’s Hyve is an isolated workspace with its own storage. Customers do not share a data store, and nothing in the platform returns one customer’s data in another customer’s request.

• A workspace is bound to its identity when it is created, and that binding cannot be changed afterwards.
• Every request has to prove which workspace it belongs to before any data is read or written. A request that cannot is refused; nothing is served by default.
• Shared rooms inside a Hyve are members-only: reading or posting requires membership, checked on every call.

• Identity is decided by the platform, not claimed by the caller. Who you are is derived on our side from your credential. Anything a request asserts about its own identity is ignored.
• Credentials are checked in a way that does not leak how close a wrong guess was.
• A valid credential that is not mapped to a workspace is refused, never routed into a default or shared workspace.
• Least privilege by default. Roles are granted explicitly, and the operations that can move, export or rewind a workspace are restricted to its owner.
• Restores leave a record the restore cannot erase. An operation that rewinds a workspace writes its audit record outside that workspace first.

All traffic to the platform is encrypted in transit and served over HTTPS only, with the standard browser-hardening headers applied to every response. Transport encryption is terminated at our infrastructure provider’s edge; the exact protocol negotiated for any given connection depends on your client and on the provider’s current configuration, which we do not control or certify.

Workspace storage and backups are encrypted at rest by our infrastructure provider at the storage layer. On top of that, the platform applies its own encryption to the most sensitive fields before they are written, using authenticated encryption, so tampered data fails to decrypt rather than returning altered content. A per-customer key option exists for deployments that require separate key material.

Provider credentials you give us

AI-provider keys you store with us are encrypted before they are written. Only a short prefix is kept readable, so that you can tell your keys apart without us ever displaying the secret back to you.

On the phrase “end-to-end”

We do not describe the platform as end-to-end encrypted, and we ask that nobody else does on our behalf. On the default path, keys are managed by us; this is encryption at rest and in transit, not a claim that we are technically unable to read your data.

• Daily backups. Each workspace is backed up every 24 hours to durable storage separate from the live workspace.
• Key material is never in a backup.
• Point-in-time recovery is available within a rolling 30-day window. Restores are owner-only and audited.

Backups exist to recover from incidents. They also mean deletion is not instantaneous everywhere — see the retention section of our Privacy Policy.

• Platform secrets are held as managed secrets by our hosting provider and injected at runtime. They are not committed to source control and are never printed, logged or written to disk by our tooling.
• If you believe a credential of yours has been exposed, email [email protected] and we will rotate it.

Connecting a third-party assistant or application to your Hyve gives that application the same authority over your workspace that you have, including the ability to change and delete data. Access to connect is protected by an identity check with a second factor; that controls who may connect, not what a connected application may then do. Any per-action confirmation you see is rendered by the connected application and is theirs to change, not ours to enforce.

Treat connecting an application as handing it your keys. Model providers are covered in the Privacy Policy: you choose them, your content goes to them, and their security posture is theirs, not ours.

Being specific about gaps is more useful than a list of adjectives. As of the date on this page, we do not have:

• a SOC 2 Type I or Type II report;
• ISO 27001 certification;
• HIPAA, PCI DSS, or FedRAMP compliance;
• a completed third-party penetration test;
• a public bug bounty programme;
• a 24/7 staffed security operations centre;
• a contractual incident-response time commitment;
• a published uptime commitment or service level agreement — see section 7 of our Terms of Service.

Independent audit and a formal penetration test are the next items we intend to fund. We will update this page when that changes, and not before.

If we become aware of a security incident affecting your data, we will investigate, contain it, and notify affected customers without undue delay with what we know, what we do not yet know, and what we are doing about it. Where a notification obligation applies to us or to you under applicable law, we will support meeting it.

We do not currently offer a contractual notification deadline. When we can commit to one and meet it reliably, we will put it in writing.

If you have found a security issue, we want to hear about it. Email [email protected] with:

• a description of the issue and its impact;
• the steps to reproduce it, or a minimal proof of concept;
• the affected page or feature;
• how you would like to be credited, if at all.

What we ask of you

• Test only against your own workspace and data. Do not access, alter, or retain another customer’s data.
• Stop at proof of concept. Do not exfiltrate data beyond the minimum needed to demonstrate the issue.
• No denial-of-service testing, no spam, no social engineering of our people or our providers, and no physical attacks.
• Give us a reasonable opportunity to fix the issue before disclosing it publicly.

What you can expect from us

• We aim to acknowledge a report within five business days and to keep you updated as we work on it.
• If you follow the guidelines above, we will treat your research as authorised conduct, will not pursue legal action over it, and will say so if a third party asks us.
• We do not currently pay bounties. We will credit you if you would like us to.

This page is deliberately written at the level of what we do, not how. If your review needs implementation specifics — algorithms, key handling, the exact controls behind each statement above — email [email protected] and we will walk you through them under a mutual non-disclosure agreement.

Security: [email protected]. Legal and privacy: [email protected].

CogNoodle LLC, a Wyoming limited liability company.