Security

Rivynt cannot change your Procore records

Rivynt never changes a record in Procore, and the code makes the opposite impossible rather than merely forbidden. Every integration receives a data plane whose interface exposes exactly one method: get. There is no create, update or delete to call. The live implementation hardcodes the request verb, and the recorded-fixture format used in tests admits only reads — so a test cannot describe a write even hypothetically.

There are three exceptions, and each travels through a separate transport whose requests are allow-listed to exact URLs and nothing else. The OAuth token grant is a POST by protocol. Autodesk Construction Cloud lists RFIs only through a search sent as a POST: it may carry only the documented filter and paging fields, and it changes nothing. And once an owner or administrator allows it in Rivynt, Rivynt creates its own notification webhook on each job. That webhook is the one thing Rivynt ever writes: it cannot touch a record, and it cannot change a webhook anybody else made.

Your connection is sealed, and the key is not in the database

The tokens that let Rivynt read your Procore data are encrypted with AES-256-GCM and stored as ciphertext. The sealing key lives only in the server environment, never in the database. A copy of the database on its own yields nothing usable; a leaked environment variable on its own yields no ciphertext to use it against.

Each stored credential records which key version sealed it, so keys can be rotated without downtime. The table holding them has row-level security enabled with a deny-all policy: it is reachable only by the server, never by a browser.

Tenancy is enforced on every query today, with a second layer in place beneath it

The browser never queries the database. Every read and write goes through a server-side data access layer that sets explicit company scope on every query. That scope is what keeps one company's data from another today.

Beneath it, every table carries row-level security with a policy scoped to company membership, and the database grants nothing to public API roles, so no browser or API client can reach a table at all. The server's own connection, however, uses a database role that row-level security does not apply to. On the path the product actually runs, those policies are defence in depth that is not yet in force: a query that left out its company scope would not be stopped by them.

They become independent enforcement when the server connects with a least-privilege role that row-level security does apply to. That work is in progress, and this page will say so when it is done.

Verified in production on 2026-09-16: 45 of 45 tables have row-level security enabled, with 45 policies, and zero table or function privileges granted to public API roles.

Nothing is exposed unless it is exposed on purpose

Table and function privileges for public API roles were revoked, and the defaults were flipped so that anything added in future is callable and readable by nobody until a migration explicitly grants it. Exposing a table would be a deliberate line in a migration, reviewed like any other change. Helper and trigger functions live in a separate schema the API never exposes, so nothing supporting the database can become an accidental endpoint.

An event trigger enables row-level security automatically on every new table, so the first rule of the project cannot be forgotten.

What is kept, and what it is kept for

Rivynt stores the records it reads, the evidence derived from them, and the score runs those produce. It keeps them because a score that cannot be traced back to the record that produced it is not worth having: every figure on a scorecard walks a chain from the score to the category, the evaluation, the evidence, and the source record it came from.

Historical rule versions are preserved. A change to your scorecard never rewrites a past result — last month's score stays explainable under the rules that produced it.

What Rivynt does not do

• It does not change your records in Procore, or in any source system, ever.
• It does not sell your data.
• It shares your data only with the subprocessors named below, and only for what each is named for.
• It does not use your data to train models.
• It does not show one company's figures to another.
• It does not let a browser reach the database directly.

Subprocessors

Three companies process your data on Rivynt's behalf, each for one part of the service.

• Supabase — the database and sign-in. Everything Rivynt stores is stored with Supabase, in the United States.
• Vercel — hosts the application. Every request to Rivynt passes through Vercel.
• Anthropic — writes the answers in Ask Rivynt and the summary in the monthly digest, from the figures those need, and drafts a scorecard from a document you upload to the scorecard builder. Anthropic never receives your Procore connection.

Procore is not a subprocessor: it is your own system. Rivynt reads from it, and writes nothing to it but its own notification webhook, when you allow it.

Autodesk Construction Cloud is not a subprocessor either: it is your own system. Rivynt reads from it, and writes nothing to it but its own notification webhook, when you allow it.

Where Rivynt is today

Rivynt is a young product and says so. It does not yet carry a SOC 2 report. What it has instead is a small, deliberate surface: read-only access to your records by construction, sealed credentials, company scope on every query with row-level security in place beneath it, and a database that grants nothing by default. Those are checkable claims rather than a certificate, and the checks are named above.

If your security review needs something specific — a questionnaire, an architecture conversation, evidence of a control — ask, and you will get a straight answer including "not yet" where that is the answer.