Security

Shared work. Controlled boundaries.

Rivet is designed around organization scope, relationship membership, bounded guest access, and private-by-default system links.

Contact security
Who can see what

Access follows membership — and tiers never bleed.

Every read is gated by scope: your organization, the relationships you are a member of, and the specific conversations you are invited to. Accumulating one grant never widens another.

Organization scope

Your team, settings, systems, and internal channels belong to your organization. Cross-organization reads return only an approved public profile.

Relationship membership

Shared documents, conversations, and workflow are visible only to members of that relationship — on both sides, at the scope each side controls.

Bounded guest access

An outside participant sees only the conversation they were invited to — never the workspace, relationship, or documents around it.

Designed-in behavior

Private by default, auditable by design.

Verified organizations and roles
Parties transact under verified organization identity, with role-based access inside each company.
Private-by-default system links
Each side links its own accounting records; internal identifiers are never shared across the connection.
Whitelisted data sharing
Cross-organization reads expose an explicit public profile — new fields are private until deliberately shared.
Approvals gate consequential actions
Payments and workflow steps execute only through explicit, recorded approvals.
History you can verify
Every document state change and payment is recorded in a hash-chained history anyone can re-verify. Administrative actions are written to an append-only security log.
Authenticated network identity
Each organization acts through its own Rivet network address, so counterparties know who they are working with.

Security documentation is available to evaluating teams under NDA. Questions about our posture, data handling, or financial-partner compliance: contact security.

Account security

A second factor on every door. Including the back one.

Members can protect a Rivet account with a passkey, an authenticator app, a text message, or an emailed code, and get ten single-use recovery codes when they set the first one up. The requirement applies everywhere an account can be opened — password sign-in, single sign-on, and password reset — so there is no side door around it.

Passkey
A face, a fingerprint, or a hardware security key. The only one of the four that resists phishing.
Authenticator app
A six-digit code from the app a member already uses. Standard TOTP.
Text message
Widely supported, and the weakest of the four — a phone number can be taken over.
Emailed code
The convenience tier. An administrator can require members to hold something more than this.
Required where an administrator decides
Across a whole organization, or for one member — and the exception works in both directions, so a finance admin can be held to a factor an organization does not otherwise require.
Codes work once
A one-time code is refused after it has been used, even inside the window where it would otherwise still be valid.
Cloned security keys are disabled
A passkey whose signature counter runs backwards — the signature of a copy — is switched off, not merely refused for that attempt.
Repeated failures lock out
Counted across every method together, so switching from app to text does not buy an attacker a fresh budget.
Secrets are encrypted; recovery codes are not stored
Authenticator secrets and phone numbers are encrypted per user. Recovery codes are kept only as a keyed hash, with the key held outside the database.
An administrator cannot quietly remove yours
Resetting a member's second factor requires the administrator's own, just used, never on themselves and only inside their organization — written to an append-only security log and emailed to the member.

Two things worth stating plainly. A second factor is a choice an administrator makes — it is off until an organization turns it on. And passkeys are the only one of the four that resists phishing: a convincing replica site can harvest and replay a code from an app or a text in real time, so an organization requiring any second factor has raised a floor rather than closed that gap.

Reporting a vulnerability

Found a security issue? Tell us first.

We welcome reports from anyone who finds a security problem in Rivet, in good faith.

How to report
Email security@rivet.technology. Please do not open a public issue or post details before we have responded. Include the host or endpoint, steps to reproduce, the impact you observed, and how we can reach you.
What to expect
We aim to acknowledge every report within two business days, tell you what we found, keep you informed while we investigate, and tell you when a fix has shipped. We credit reporters who want to be credited.
Scope
In scope: rivet.network and rivetx.app hosts, the public API, the public verification endpoints, and this site. Out of scope: services Rivet uses (report those to the vendor), denial-of-service or volumetric testing, social engineering, physical attacks, and findings that require a compromised device or account.
Rules of engagement
Test only against organizations you own or are authorized to use — sandbox organizations exist for API testing. Do not access, change, or destroy data that is not yours; do not degrade the service; stop and report as soon as you can demonstrate the issue.
Bounty
Rivet does not currently run a bug bounty program and does not offer monetary rewards for reports.
Safe harbor
Safe harbor terms: coming. We will publish them here once they are settled.

Machine-readable pointer: /.well-known/security.txt (RFC 9116). Rivet is a hosted service; there are no customer-installed versions.

The right people see the right state — with the evidence to act.

Contact securityRequest a demo
Security — Shared Work. Controlled Boundaries.