Security

01Hosting and data location

Tinu is a cloud service. The application is hosted on Vercel. Customer data is stored in a PostgreSQL database run by Neon in the AWS us-east-2 region (Ohio, United States). Background jobs run through Inngest, and Upstash Redis handles rate limiting and session revocation.

Tinu is multi-tenant: customers share the same application and database, kept apart as described in section 02. We do not offer a dedicated or on-premises deployment today.

02Tenant isolation

The tables that hold an organization’s workspace content, such as entries, decisions, memories and member records, have PostgreSQL row-level security policies, keyed on the organization and the person making the request. Requests from signed-in members run as a separate database role that does not own the tables and cannot bypass those policies. The application sets the organization and person for each request inside the same transaction as the query, and a query with no organization set matches no rows.

Some paths run as the database owner, which bypasses these policies, and limit their queries in application code instead: sign-in, read-only share links, Tinu’s internal admin tools, and some background processing jobs. A few tables have no row-level security: share links, which the member-facing role cannot access at all; the audit log, which it can only add to; and internal tables such as product analytics events and sign-up requests.

Two automated checks guard this on every code change:

• a test that fails the build if a new table with an organization column is added without row-level security, unless it is on a short exception list with a written reason; and
• a test against a real PostgreSQL database proving that one organization cannot read or write another’s rows, and that the application’s role cannot bypass the policies.

Inside an organization, members can mark an entry private. Managers and admins have no override that lets them read another member’s private entries.

03Encryption

In transit

Every response tells browsers to use HTTPS only, with a Strict-Transport-Security header (two years, including subdomains). The production application refuses to start if any of its database connection strings allows an unencrypted connection.

Stored data

• Access tokens, API keys and passwords for systems you connect to Tinu are encrypted by the application with AES-256-GCM before they are stored. They sit in database columns that the role serving customer requests cannot read. The encryption key is held outside the database and can be rotated.
• Tinu account passwords are stored as bcrypt hashes, never in readable form.
• Tinu API keys and share-link tokens are stored only as SHA-256 hashes, so a copy of the database does not contain them.

04Sign-in and access control

• People sign in with a Google account, or with an email address and password. Password sign-in attempts are rate-limited by IP address and email address.
• Tinu has no built-in second sign-in factor today.
• A session ends after 24 hours without activity. This is an idle timeout, not a fixed lifetime: each visit renews it for another 24 hours, and there is no maximum session length today. Changing or resetting a password, signing out, or disabling an account ends every session for that account at once.
• A disabled account cannot sign in, and its API keys stop working.
• Each member of an organization has a role: admin, manager or member. Admins manage members and organization settings.

Tinu staff access

A short list of Tinu staff accounts can open a support session in one organization at a time. A support session lasts at most one hour. It lets the staff member administer that organization without becoming a member of it. Its start, its end and every change made during it are written to the audit log under the staff member’s own name. These staff accounts must sign in with Google: password sign-in is refused for them in production.

05AI processing and model providers

Tinu sends workspace content to two AI providers through their APIs: OpenAI and Google (Gemini). They write summaries, pull out decisions, people and topics, build the embeddings that power search, and answer questions in chat. No other AI provider receives customer content.

• Chat and background processing run on OpenAI first, and fall back to Google if the OpenAI call fails. Search embeddings and some quick in-app responses run on Google.
• Every organization has a monthly AI spending cap. Each model call is checked against it first. Once the cap is reached, AI features stop for that organization until the next calendar month or until the cap is raised.
• For each model call we record the provider, model, purpose, token counts and timing, linked to the organization. That record does not contain the prompt text.
• Tinu does not train AI models on customer content.

Section 05 of the Privacy Policy covers AI providers and model training in full.

06Data retention and deletion

Removing a departed member’s data. Once someone has left an organization, an admin or their most recent manager can file a request to delete their data there, and a different admin approves it. In an organization with a single admin, that admin may approve their own request, and the approval is recorded. Once approved, the data is hidden right away and can be restored for 30 days. After those 30 days it can be permanently deleted, or de-identified: the member’s identity and authorship are removed and the organization keeps the anonymized knowledge.

A deletion request only ever touches that member’s data in that one organization. If they belong to other organizations, those are untouched.

Export. Any member can export their own entries, as JSON or CSV, at any time.

End of contract. Return and deletion of your data when an agreement ends are covered by section 13 of the Data Processing Agreement. Retention periods for each kind of data are in section 07 of the Privacy Policy.

07Audit logging

• Changes to workspace data are written to an audit log automatically, in the data-access layer rather than by hand in each feature. Each record holds the acting person, the organization, a request ID, the IP address, the user agent, and the record before and after the change.
• Opening another person’s records is logged too: a decision, one person’s records on the team page, the full text of their entries, or an answer in chat or Slack that drew on their entries. Each record names who read, whose records, where and when, by ID only, never the content. Reading your own records is not logged. Your organization’s admins can review this log, and each author can see who opened their entry.
• Password hashes, key and token hashes, and the source text of entries are left out of audit records.
• The database role that serves customer requests can add audit records but cannot read, change or delete them.
• Audit records are kept for at least one year.

08Backup and recovery

The database uses Neon’s point-in-time restore. A scheduled job tests it every month: it restores a copy of the production database as it was about five minutes earlier, checks that the expected tables are present and can be queried, then deletes the copy.

09Software changes

Automated checks run on every pull request: linting and type checks, the full test suite, a production build, a database migration order check, and secret scanning with TruffleHog. Two more run on every pull request that changes code, and are skipped only when a pull request changes nothing but tests or documentation: the row-level security test against a real PostgreSQL database, and end-to-end browser tests. In our merge queue, every one of these checks runs, with nothing skipped. Dependabot opens weekly pull requests to keep dependencies current.

10Control systems (OT and SCADA)

Tinu never connects to operational technology. It has no connector for SCADA, EMS, DCS, PLCs or historians, and it installs no agent, sensor or software on operational or control networks.

Two optional tools run on employees’ own computers: a command-line tool that indexes files on that computer and sends them to Tinu, which is off unless turned on for your organization, and an Excel add-in. Neither connects to control systems.

Information from operational systems reaches Tinu in only two ways:

• a person exports a file and uploads it, for example a SCADA alarm journal saved as CSV; or
• a Tinu operator connects a business system such as Maximo or SAP, together with your system admin, using a credential your admin issues. Tinu reads that system over its API. These connectors only read. They never write back.

Tinu is not designed to hold BES Cyber System Information or other information your CIP program protects, and your users should not submit it.

11Subprocessors

Every third party that processes customer data for us, what each one is for and what data reaches it, is listed with a dated change log on our subprocessors page. We email organization admins at least 30 days before a new subprocessor begins processing your data.

12Compliance status

SOC 2 readiness underway. We do not have a SOC 2 report to share yet.

Our Data Processing Agreement sets out our security measures, how we notify you of a personal data breach, and how your data is returned or deleted when an agreement ends.

13Reporting a security issue

Email security@tinuai.com with what you found and how to reproduce it. We will not pursue legal action for good-faith research that respects user privacy and does not degrade the service.

If we become aware of a personal data breach affecting your data, we notify your organization’s admins by email without undue delay, as set out in section 09 of the Data Processing Agreement.

See also our Privacy Policy, Data Processing Agreement, Subprocessors and Terms of Service, or return to the Tinu AI home page.