Tenant isolation
Every customer’s data lives in its own logical tenant, identified by an organization. Isolation is enforced in the database itself through row-level security policies that scope each query to the organization of the signed-in user, rather than being left to application code to remember. Records across the system carry an organization reference and cascade with it, so removing an organization removes its data.
Queries run under the signed-in user’s own database session, so a request that tries to reach another organization’s rows returns nothing regardless of what the application asks for.
Encryption
- In transit. All traffic to the application and between the application and its data stores is encrypted with TLS.
- At rest. Database and object storage are encrypted at rest by our infrastructure providers.
- Credentials, encrypted again at the application layer. Integration access tokens and third-party application secrets are encrypted with AES-256-GCM, using a key held only in the server environment and never written to the database. An attacker holding a copy of the database still does not hold usable credentials to your connected systems.
Documents you upload
Invoices, purchase orders, ledger exports, and budget workbooks are stored in private object storage. There are no public URLs and no permanent links.
- Access is checked first: the server confirms the requesting user belongs to the organization that owns the document before any link is created.
- Only then is a signed, time-limited URL issued, and those links expire within minutes.
- The underlying storage path is never returned to the browser, so a link cannot be reconstructed or shared as a durable reference.
Authentication and access control
- Sessions. Authentication is cookie-based and handled server-side. Database keys and service credentials stay on the server and are never exposed to the browser.
- Roles. Membership in an organization carries a role — owner, administrator, or member — and access to a workspace requires an explicit membership record. New members join only by invitation from someone already in the organization.
- Separation of operator tooling. Internal administrative functions live on a separate surface from the customer product, and are never reachable from the customer dashboard.
- Immediate revocation. Operator access is verified against the current state of our staff records on every request, rather than trusted from a token issued earlier. Removing someone takes effect on their next request, with no waiting for a session or token to expire.
Connecting your systems
Connections to commerce and accounting platforms are established through each platform’s standard authorization flow. We request the narrowest set of permissions the product needs. Callbacks from those platforms are verified cryptographically before any token is accepted, and the request that initiated the connection is itself signed, so a third party cannot induce a connection into your account. Resulting tokens are encrypted as described above.
How your data is used with AI models
Reading a document or answering a question about your data requires sending the relevant contents to our model provider. Two commitments apply:
- We do not use customer data to train, fine-tune, or improve any model.
- Data submitted to our model provider through its API is not used to train that provider’s models.
Model output is treated as a suggestion, not an instruction. Where the product proposes a match between an invoice and a purchase order, or a categorization, or an approval route, it presents the suggestion and a person confirms it. The system does not post, pay, or approve on its own.
Infrastructure
Tahini runs on managed cloud infrastructure. We do not operate our own servers or data centers, and we rely on our providers for physical security, network security, and platform patching.
Data retention and deletion
Customers can delete records from within the product. On request we will delete or return an organization’s data, and we delete it within a reasonable period after an account closes unless we are required to retain it. Deleted data may persist in provider backups for a limited time before aging out. See our Privacy Policy for detail on retention and on your rights.
Incident response
If we become aware of a security incident affecting customer data, we will investigate, take steps to contain and remediate it, and notify affected customers without undue delay, with the information we have about what happened and what we are doing about it.
Reporting a vulnerability
We welcome reports from security researchers. Email hello@usetahini.com with enough detail to reproduce the issue, and we will acknowledge your report and keep you updated on the fix.
We ask that you:
- Give us a reasonable opportunity to fix the issue before disclosing it publicly.
- Avoid accessing, modifying, or deleting data that is not your own, and use test accounts wherever possible.
- Avoid privacy violations, service degradation, denial-of-service testing, social engineering, and physical attacks.
We will not pursue legal action against researchers who follow these guidelines and act in good faith. We do not currently run a paid bug bounty program.
Questions
Security questionnaires, architecture questions, and requests for our current sub-processor list can be sent to hello@usetahini.com. Customers who need a data processing agreement in place can review our standard Data Processing Addendum and request a countersigned copy at the same address.