Trust Center

Sonata was built with security in the architecture from the first line of code, not added afterward. Every record is isolated at the database level, so one organization can never reach another’s data, and this is enforced by the database itself rather than by application logic. Credentials and connection secrets are encrypted with AES-256-GCM, and the keys to read them live only on the server. The database table that holds them is locked to server-side access alone. Access tokens are never exposed to the browser. Connections to outside systems are limited to official first-party servers, or servers your own organization hosts, never an arbitrary third party. Access is invite-only, with no public signup. Sensitive changes are enforced in three places at once: the interface, the server, and the database.

Your data is yours, and Sonata treats it that way. Sonata does not sell your data, and Sonata does not train any models on it. There is no model training of any kind in the product. When you send work to an AI model, that inference is performed through Anthropic’s API under Anthropic’s commercial terms, which you can review. If you bring your own model key, that request runs under your own provider account and your own agreement, so the data boundary is yours to set. Sonata collects only what the product needs to work, and your administrators govern what your agents and connections can reach.

Two things we state plainly rather than bury. Your organization’s administrators can access the conversations and work within your organization, because the work product belongs to the organization, not to any one user. And Sonata relies on a small set of infrastructure providers: Vercel for hosting, Supabase for data storage and authentication, and Anthropic for AI inference. When your organization connects Google Workspace, Google joins that list by your choice.

This is the pillar most tools do not have, and it is the heart of what trust means for legal work. AI in Sonata does not act on its own. An agent can read and reason freely, but it cannot take an action that changes anything, such as sending a message, creating a document, or modifying a connected system, without a person approving that specific action first. This holds even when a workflow is set to run on its own. Reading and reasoning can proceed, but any action that changes a connected system still pauses for a human. Every step a workflow takes is recorded in order: what ran, what it produced, and whether a person approved it or it proceeded automatically. It is designed as an immutable record you can review. Your administrators decide which models, connections, and capabilities are available to your organization. You are never asked to take the software’s judgment on faith, because the software cannot act without you.

Most software treats security and privacy as a compliance checkbox and trust as a tagline. For a product entrusted with privileged legal work, that is not enough. Security without control means an AI that protects your data while acting without your say. Control without careful data handling means a system you command but cannot trust with confidential matters. The commitment has to be all three at once.

We also believe being trustworthy means being honest about what is built and what is still ahead. The security architecture described here is live in the product today. Formal data retention and deletion controls, account data export, and external compliance certifications are on our roadmap, not yet in place, and we will say so plainly until they are. A product asking a legal team for its trust should never overstate what it can actually do.