Skip to content
decosa
decosa
Get an API keyTry a tool

Industries

LegalBriefs, depositions, discovery, records, client calls.HealthcareThe visit, then notes, audits and denials.Finance & insuranceAlerts, SARs, disputes, claims, recorded calls.HRInvestigations, leave and I-9 audits.Compliance & trustSecurity questionnaires, control evidence, AI audits.OperationsForms, shop pages, imports, listings: any industry.Life sciencesTrial numbers, safety cases, labels, papers.

More industries

Public sector 2 toolsSales and marketing 6 toolsScience and research 6 toolsMusic 5 toolsFilm, TV and games 6 toolsAll industries

Create and tools

CreateTools

Developers

Decosa APIQuickstartAPI referenceAPI pricingBuilding blocksDecosa agentAssembly promptsFor AI agentsSelf-hosting docsVerify a runAccuracyStatus

Trust

Where your data goesHosted APISelf-hostOn a MacConfidential optionDecosa for ChromeAccuracyVerify a runStatusSecurityRegulation watchCompare ways to run it

Company

PricingAboutApps by DecosaContact

Beta. The API and these docs may change.

Sealed tier

Status: paused at launch. The sealed tier encrypted a chat prompt on your machine and decrypted it only on a model server Decosa operates, next to the model. At launch, Decosa's hosted model calls run on outside inference providers (who serves them), not on Decosa's own GPUs, so there is no Decosa-operated server for a sealed request to be decrypted on. The sealed endpoints are off until it returns, and no request is sent in the clear in their place.

It comes back as a confidential tier: the model and the decryption run inside a hardware-attested enclave (a TEE) that you can check, so neither Decosa nor the provider can read the prompt. See Confidential tier for the pilot and how to ask for it.

What to use now

  • Patient, privileged or otherwise regulated data: self-host. Run the tool and the model on your own hardware (Self-hosting, on request). Nothing goes to Decosa or a provider.
  • Hosted calls: TLS to Decosa's API, then the named provider runs the model with zero data retention. Each call's receipt names who served it. How each tool handles data, hosted and self-hosted, is on Where your data goes.

How it worked (and will again)

  1. Your client fetched the model server's encryption key, signed by that server's identity and countersigned by Decosa, and refused a key whose signature didn't match the identity it pinned.
  2. It encrypted the request body (messages and sampling settings) with HPKE (RFC 9180), suite X25519 / HKDF-SHA256 / ChaCha20-Poly1305, binding the clear route (model, token limit, key id) into the encryption.
  3. Decosa's API forwarded the ciphertext to the server next to the model, which decrypted, ran the model and encrypted the answer under a key only your request could derive.
  4. The server signed the ciphertext hashes; Decosa checked that signature before charging, and your client checked it again before decrypting. Receipts hashed the ciphertext, so they stayed verifiable and held no text.

The keys to pin and the client are published again when the tier returns. Until then, don't pin any earlier key.