What happens to your files

Your browser sends each file over HTTPS straight to Google Cloud Storage, with an address signed for that one file, its type and its size, which can create it only once and expires within an hour.

The browser checks each file's type, size and count, and the server checks them again. Before reading, TieProof compares the file's bytes with its stated type and checks the package inside it.

Your browser computes each file's SHA-256 as it uploads, and the check refuses a file whose bytes changed on the way.

Macros, scripts and embedded programs never run. XML is read with entity resolution and network access off, a part that declares a document type is refused, and limits on size and compression stop a file that would expand without end. Password-protected files are refused.

Deleted 7 days after the check ends, unless an admin of the organization chooses another number of days, from 1 to 30, for checks that end after the change.

The copies the worker reads are deleted at the end of every attempt, whether it succeeded or failed.

Each finding keeps the excerpts of its evidence: the values, their locations and the text around them. They stay with the results after the raw files are deleted, so a finding can still be read and defended, until you delete the check or its project.

Removes its results, its evidence and any file still stored, and the audit log records who deleted it. An admin can delete a project and every check in it.

Not yet in service: deleting an organization or an account, and exporting your data, are not yet offered on a screen. They are handled on request.

Every read and write made for you runs in a transaction that names your organization first, and PostgreSQL's row-level security, which the application's role cannot bypass, shows it only that organization's rows. With no organization named, no row is visible.

Each request is checked against the member's role and organization before it touches any data, and a request that names another organization's record finds nothing.

Email and password, with the address confirmed before a first check, or Google. The session is held in cookies that scripts cannot read, sent only over HTTPS.

The server verifies each access token's signature, issuer, audience and expiry. A password can be reset only from a recent recovery link, and a reset ends the account's other sessions.

Analyst, reviewer and admin, each allowed only what its role needs. Every endpoint declares what it needs, and tests hold each role to the permission table.

No external AI model is configured. Every verdict is decided by deterministic code: arithmetic, units, scale and tolerances.

To match labels, the engine uses an embedding model that runs inside its own worker and sends nothing out.

An admin can set the organization's AI policy to Local only, and each check records the policy it started under. Today both settings behave the same, since no check calls an external model.

Not yet in service: the models decided are Anthropic's Claude models on Google Cloud's Vertex AI, at endpoints in the production geography, under terms that bar training on your data, with zero data retention configured. They will receive only the excerpts one task needs, never a whole file, and nothing under Local only. This page will name them as in service only once they are.

The services log identifiers, codes, counts and durations, and never a file's content, an evidence excerpt, a token or an upload address. An error is logged by its type, never by its message.

Decisions on findings, changes to an organization's settings and members, and deletions are recorded, and reviewers and admins can read them.

Each page carries a content security policy of its own, may not be framed by another site, and every action that changes something checks that it came from TieProof's own pages. A signed-in user's requests are rate-limited.

Serves the web pages. It holds no product data.

Runs the API and the private worker that checks the files, and holds the uploaded files until they are deleted.

Holds the accounts and the database: organizations, checks, findings, their evidence and the audit log.

An email provider, a payment provider, a status page and an AI model provider. Each joins the subprocessor list before it receives any customer data.

If an incident exposes your organization's data or produces wrong results, your organization is told within 24 hours of its being confirmed: what happened, what was affected and what will change. Not yet in service: the procedure that carries this out, and a status page, are not in place yet.

Not yet in service: there is no address yet for reports from outside the team.